Bootloader kérdés

pkedvessy

Sziasztok!

A következő dolgot szeretném megvalósítani, és a kérdésem az lenne, hogy tudtok-e valami hasonló dologról, amin keresztül el lehetne indulni!?

Egy olyan bootloaderre lenne szükségem, ami külső i2c-s eepromból tudná a firmware-t beégetni az AVR-be! Azt is jó lenne valahogy megvalósítani, hogy ne csak az eeprom-ból tudja a frissítést, hanem soros portról is (USB-s soros port), ha rá van kötve...

Köszönöm előre is a tippeket, ötleteket!

dummy

A Bascom minták között található a BootLoader.bas fájl. Kimásoltam belőle egy részletet:

Kód: Egész kijelölése

#if Loaderchip = 88                                         'Mega88
    $loader = $c00                                          'this address you can find in the datasheet
    'the loader address is the same as the boot vector address
    Const Maxwordbit = 5
    Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
#endif

Itt a Loaderchip változótól függ, melyik programrész fut le, ez eddig tiszta.
Kérdés, hogy a $loader változó értékét honnan vesszük, mert ez minden uC esetében eltérő, ill. a Maxwordbit értéke szintén minden uC-nél más és más.
Míg a $loader-nél ott a megjegyzés (az adatlapra vonatkozóan), a Maxwordbit-ről semmi infó. Mellesleg a $loader értékét sem tudom, hol lelem az adatlapban.

Ezekről tud valaki bővebben írni?

$loader: mekkor a bootloadered. Azaz a bootsize mekkora legyen? (Fusebiteknál TE állítod be) Itt nagyobb bootloadert lefoglalhatsz méretre, csak kisebbet nem!

dummy

Aha!

Maxwordbit...?

SanyiSay

Üvd.

FT232RL az áldozat.

Az megvan hogy SW megoldható a Reset ha figyelem a #123 illetve a #124 kódot vagy bármi jel amit én megadok, de beállítható DTR/RTS jel is. DTR-ről olvastam hogy terminál programok is generálnak ilyen jelet így ez nem ajánlott, ám az RTS-ről nem találtam semmit.

Esetleg valami tapasztalat?

Mi a kérdés?:)

A DTR és társai-> MINDEN esetben reseteli így a chipet (DTR és RESET láb közé 100nF kondi).

A #123, #124 egyszerűbb. Itt reseteld le....

SanyiSay

Hát gondoltam hogy kiad egy reset jelet a kérdéses lábakon és akkor nem kell figyelgetnem az adatforgalmat.

SanyiSay

Ám ha nekem állandóan resetelget az nem jó.

SanyiSay

Ránéznék én hogy milyen jelek jönnek rajta ki, csak pont az a láb nincs kivezetve aztán gondoltam előbb kérdezek megéri e hekkelni rá valami átkötést.

E nem szeretem hasznalni eles rendszer eseten. Minden soros adatkapcsolat kialakulaskor ne induljon ujra... Inkabb a foprogramba berakom a bejovo karakterfigyelest, es ha #123/124 jon -> chip ujraindul....

SanyiSay

Én sem úgy gondoltam egészen.
Viszont byte-okat küldök ide oda saját PC progival AVR felé és egyszerűbbnek tünt a az RST láb használata mint az adatforgalom figyelés. Persze azt még nem tudom mivel generálok RST jelet, nehogy véletlen megtegyem. Viszont a bascom meg felajánlja mint Reset lehetőség. Gondoltam akkor csak van értelme.

SanyiSay

+ még az is kérdés hogy ha nem bascommal töltöm fel a programot hanem a sima feltöltővel, (nevére most nem emlékezem) akkor ott is meg van e ez a lehetőség. Hát lehet tényleg kézenfekvőbb az adatfigyelés. Mondjuk akkor is saját reset adatsor küldés lenne a jó. Na majd este rátekintek minderre.

SanyiSay

Már előre látom, hogy végigolvasok mindent a témához aztán marad az általad ajánlott módszer.

Többnyire ez szokott lenni.

Reset:
A, Főprogram indítása:
- goto $0000 '0. memóriacím
- jmp $0000 '0. címre ugrás, ASM

B, Bootloader indítása:
- goto _reset (ha a $loader sor definiálva van)
- start Watchdog:do:loop 'watchdog indítja ujra a chipet es abootloader indul

A B/2 megoldás preferrált...
Az újraindítás ok az MCURST (vagy hasonló nevű resetregiszter) kiolvasása adjha meg: WatchDog, BOD tápingadozás, Ext reset, Power ON, JTAG reset....

SanyiSay

Látom a tapasztalat elárulta hogy mi lehet a következő kérdésem.

Jó a meglátás, köszönöm a választ.
Bár még itt nem tartok.
Így holnap nem lesz mit kérdeznem.

Reset jel kereső expedíció jön előbb.