[elektro] uC: 1xUSB 2xUART 1xSPI

Beregnyei Balazs balazs.beregnyei at gmail.com
Wed Jul 11 08:26:27 CEST 2012


Ha nem bízol abban, hogy a fat és usb rutinok hibátlanok, akkor miért
akarod őket bootloaderbe rakni? :) A dataflash-es dolog, amit írtam, főleg
akkor jó, ha egyéb okokból egyébként is szükség van dataflash-re, valamint
járulékos előny, hogy a fat kód cserélhető, amit én ki is használtam. Elég
sokáig kellett faragnom ugyanis egy netről szedett fat32 kódot, hogy minden
(lin és win) alatt formázott SD-kártyával jól működjön.

Az fura lenne, ha az AVR nem tudna a boot kódból user kódot futtatni! Az
AVR-es bootlaoderem például így hívja meg a főprogramot:
asm("jmp 0000");
Ugyanígy meghívhatna egy usb-fat rutint is...

Amúgy szerintem egy minimál usb stack tud nagyon kicsi lenni, múltkor
eltöltöttem pár napot azzal, hogy a LUFA nevű stackből kigyomláljam a
sallangot. Addig jutottam, hogy már enumerál a "saját" kód, és meglepően
kicsi, talán 10k a forrás.
A fat-ot elvileg ki is hagyhatnád: az csak egy user friendly dolog, hogy
file-okat raksz a pendrive-ra, de egy éles cuccnál az is tökéletes
szerintem, ha szektor szinten fix helyen van a frissítés, tehát nem copy
pranccsal, hanem dd-vel készül a frissítő pendrive.
Szóval ezzel a kompromisszummal nem lehetetlen, hogy tényleg beleférj a
bootloader szekcióba!

Üdv,
BB


2012/7/11 Arnold Fuzesi <arnold.fuzesi.lista at gmail.com>

> Dataflash-t nem birja el a szeria ar.
> User flash teteje lehet megoldas, de nem bizok benne h a fat es usb
> rutinok hibatlanok. Szoval az applikacioban a frisebb peldany benne kell
> legyen.
>
> Ha eleg nagy a flash akkor mukodhet amit irsz. Talan azzal a kivetellel h
> atmega pl nem tud bootloaderbol futo kod eseten utasitasokat az applikacios
> reszbol vegrehajtani ha jol remlik. Tobbi proc nemtom hogy van ezzel.
>
> Arnold
> Sent from my iPhone
>
> On 2012.07.10., at 21:32, Beregnyei Balazs <balazs.beregnyei at gmail.com>
> wrote:
>
> > Mert ha nem fér bele, az milyen problémát okoz? Bootloader szekcióban
> > figyel a flash-író rutin, user flash tetején meg a FAT és pendrive
> rutinok,
> > és upgrade-nél csak a user flash alját frissíted. Köztes megoldás, amit
> egy
> > régebbi melómban csináltam (nem pendrive, hanem SD-kártya, de a lényeg
> > ugyanaz): van a proci mellett egy dataflash, és a user firmware abba bele
> > tudja írni a frissítést, a bootloader pedig vagy soros portról fogad el
> új
> > kódot, vagy a dataflash-ből. Így a bootloader valóban elfér a hivatalos
> > helyén, miközben a frissítés jöhet egy FAT filerendszerből is.
> >
> > BB
> >
> >
> > 2012/7/10 Fuzesi Arnold <arnold.fuzesi.lista at gmail.com>
> >
> >> Thx!
> >>
> >> +1 bónusz kérdés: :)
> >>
> >> Bootloader helyre vajon befér a pendrive kezelés?
> >>
> >>
> >> A.
> >>
> >> On 2012.07.10. 17:47, Balogh Antal wrote:
> >>> pic24fj64gb002
> >>>
> >>>
> >>> és társai .
> >>> nekünk a "gyári" forrásokkal sikerült pendrive-re irni  .
> >>> Egy loggeres okosításban.
> >>> Az olvasást nem próbáltuk.
> >>>
> >>> Balogh Antal
> >>>
> >>>
> >>> -- Eredeti üzenet --
> >>> Feladó: Fuzesi Arnold&lt;arnold .fuzesi.lista at gmail.com&gt;Címzett:
> >> elektro at tesla.hu&lt;elektro at tesla.hu&gt;Elküldve: 2012. július 10.
> >> 16:43Tárgy : [elektro] uC: 1xUSB 2xUART 1xSPI
> >>>
> >>> Sziasztok!
> >>>
> >>>  Olyan uC kellene ami egyszeruen keves munkaval tud:
> >>>  USB pendrive-ot kezelni, illetve rendelkezik 2 soros porttal + SPI-vel
> >>>
> >>>  Mit ajanlotok?
> >>>  vmi ARM / PIC ATMEL cuccai stb . mindegy első körben. Beszerezhető
> >> olcsó legyen,
> >>>  és legyen hozzá működő liszensz mentes támogatás  USB-hez, lehetőleg
> >> emberi árú
> >>>  JTAG.
> >>>
> >>>  (Filerendszer nem gond, USB reszt nincs hangulatom / időm lekódolni
> >> addig hogy
> >>>  szektorokat tudjon olvasni a pendrive-rol)
> >>>
> >>>
> >>>  Köszi,
> >>>  Arnold
> >>>
> >>>  -----------------------------------------
> >>>            elektro[-flame|-etc]
> >>> -----------------------------------------
> >>>           elektro[-flame|-etc]
> >>
> >> -----------------------------------------
> >>          elektro[-flame|-etc]
> > -----------------------------------------
> >          elektro[-flame|-etc]
>
> -----------------------------------------
>           elektro[-flame|-etc]


More information about the Elektro mailing list