[elektro] uC: 1xUSB 2xUART 1xSPI

[Fuzesi Arnold]

Thx!!!!

On 2012.07.11. 10:51, Beregnyei Balazs wrote:
> Ha a fat nem kell a bootloaderbe, akkor nyert ügyed van, az usb nem olyan
> bonyolult dolog, mint amilyennek elsőre tűnik. Ha még ez nem olvastad,
> akkor tedd meg:
> http://www.beyondlogic.org/usbnutshell/usb1.shtml
> Ez alapján, plusz egy példakód átnézésével (pl. LUFA) képbe kerülsz, és
> megírod a saját usb bootloaderedet.
> Ha megvan az enumerálás, akkor onnan a pendrive szektor szintű olvasása már
> nem nehéz, a LUFA-ban ez kb. két képernyőnyi C kód.
>
> Üdv,
> BB
>
>
> 2012/7/11 Arnold Fuzesi<arnold.fuzesi.lista at gmail.com>
>
>> Csinaltam mar ilyet sd kartyaval, es kellett is frissiteni az applikacio
>> sd/fat reszt. Bootloader csak 2G-s kartyaval megy max (nem fert be az sdhc
>> a boot szegmensbe), fat-ben is volt hiba, sd driverben is amit kesobb
>> frissiteni kellett. Bootloader viszont eldocogott ures kartyaval mindig.
>> Szoval semmiben nem bizok h hibatlan, frissiteni szeretnek mindent az
>> applikacioban.
>> Fat-et valoban nem kell implementalni boot-ba, atadtam az applikaciobol a
>> file kezdocimet a bootloadernek es annyi. Recovery mode-ban pedig az 1-es
>> szektorbol frissitett, ha talalt ott ervenyes fw-t. (ez akkor kellett ha
>> megkettyent az app)
>>
>> Szoval kitaposott az ut, csak boot teszbe befero usb kezeles kell szektor
>> szinten. Dataflash tuti kizart.
>>
>> Arnold
>> Sent from my iPhone
>>
>> On 2012.07.11., at 8:26, Beregnyei Balazs<balazs.beregnyei at gmail.com>
>> wrote:
>>
>>> 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]
>>> -----------------------------------------
>>>           elektro[-flame|-etc]
>>
>> -----------------------------------------
>>            elektro[-flame|-etc]
> -----------------------------------------
>            elektro[-flame|-etc]
>