Avr bootloader kérdéseket és válaszokat
Tervezi, hogy létrehozza a saját boot-betöltőt? Ez a dokumentum számos kérdésre ad választ, amelyek ebben a vonatkozásban. Az itt leírt fogalmak többsége nem elég részletes a mikrokontrollerek adatlapjain, de ezek a tippek ugyanakkor fontosak a megbízható rendszerbetöltők tervezéséhez. Az itt bemutatott információk nagy része megtalálható az avrfreaks.net-en, amelyek különböző ágakon szétszóródnak. Az alábbi kérdések egyszerűtől összetettekig és életképes rakodó létrehozásáért rendezhetők, valószínűleg meg akarjuk érteni a válaszokat, legalábbis az első 11 kérdésre.
Az anyag sikeres elsajátításához azt feltételezzük, hogy már tudja, mi a bootloader, tudod, hogyan kell programozni a C nyelven, és ismeri a közös 8-bites AVR alkalmazások. Ez a dokumentum az AVR-GCC eszközön alapul, amely az AVR-Libc könyvtárakat és a Makefile mintát használja. Ha egy másik eszközt használ, akkor a dokumentumban leírtak maradnak hatályban, de a Makefile kód példáinak kell lenniük
megfelelően illesztették a készülékhez.
Ezenkívül vegye figyelembe, hogy a példák az AT90USB162 szabványon alapulnak, és újra kell használni az AVR-hez.
Hol kezdjem?
Valójában a bootloader csak egy hagyományos AVR alkalmazás, amely egy speciális flash memória területén található. A legegyszerűbb formában az alkalmazás AVR betöltővel is létrehozható, ha egy kiegészítő zászlót ad meg a linkfájlhoz, amelyet hozzá kell adni a Makefile-hez:
Mi az NRWW és az RWW?
Íme, mit kell tudni az RWW és az NRWW területek jellemzőiről:
- A betöltő újraprogramozhatja az RWW területen található alkalmazásokat, miközben a betöltő végrehajtása nem szakad meg;
- A betöltő nem tudja frissíteni a kódját sem egyszerűen alkalmazáskódként;
- Az alkalmazások ritkán frissítik a bootloadert;
- Az alkalmazások frissíthetik magukat, de jobb, ha a rendszerindító ezt teszi.
Hogyan frissíti a letöltő az alkalmazást?
A bootloader milyen módon kapja meg a programot a vezérlő újraprogramozásához. A közös kommunikációs csatornák UART és USB. A csatorna adatcserére szolgáló protokoll lehet akár saját, akár szabványos, például AVR109 vagy DFU. Szabványos protokollok végrehajtásakor már meglévő eszközöket használhat, például az AVR Studio, az AVR109 protokollon vagy az Atmel Flip protokollon dolgozó DFU protokollon dolgozva. Azonban ezek a szabványos protokollok általában kissé felborulnak, és egy egyszerű egyéni protokoll végrehajtásakor a betöltő általában kisebb és tisztább. Ebben az esetben azonban meg kell fejlesztened a saját megoldását az adattovábbításhoz a betöltőhöz.
Általában a betöltő egy időben kerül elküldésre a memória egy oldalára. A betöltőnek ezeket kell írni
az alkalmazáshoz szánt flash területeken, vagyis az RWW-ben. Az AVR-Libc fejlécfájlt biztosít
Lehet a betöltő frissítési fúzió értéke?
Az AVR-vel lehetetlen. Ehhez külső programozóra van szüksége.
Miért kell használni a BOOTLOADER_SECTION szolgáltatást? ?
Nevének ellenére a BOOTLOADER_SECTION makró nem hasznos a bootloader írásakor. Ez a makró egyszerűen segít a funkció helyének átrendezésével a flash memória NRWW részéhez. Valószínűleg ennek a makróknak egy megfelelőbb neve olyan, mint az NRWW_SECTION.
BOOTLOADER_SECTION makró lehet szükség, ha egy alkalmazás megköveteli átprogramozásával funkcióját saját alkalmazásokat, mint ez a funkció csak akkor működik, ha készül razdelaNRWW. BOOT_LOADER_SECTION tényleg csak létrehoz egy külön fejezet foglalkozik a kód neve «.bootloader» (másik neve jobb, ha nem kell használni), majd egy további kapcsoló zászló pozíciók ebben a részben valahol a kihasználatlan területe memória NRWW listájában. Ezt a megközelítést nem nagyon gyakran használják a gyakorlatban.
Néhány ember a BOOTLOADER_SECTION használatával egyszerre írja be az alkalmazást és a betöltőt egy programba, de ez nem jó ötlet. A rakodó jó önálló programok formájában, amelyek nem függenek az alkalmazástól. Ez megbízhatóbb megoldás lesz, míg ha a betöltő egy különálló alkalmazás, akkor könnyebb lesz létrehozni is.
Hogyan kell villogni a rendszertöltő mikrokontrollerekhez?
Hogyan kell az alkalmazást és a rendszerindítót azonnal felderíteni?
Mivel remélhetőleg külön hozta létre az alkalmazást és a betöltőt külön-külön, a végén két különálló hexadecimális fájl lesz a firmware-sel (például app.hex és boot.hex). Felmerül a kérdés: hogyan töltsük mindkettőt az AVR-ben. Számos lehetőség van:
Két lépésben: töltse be a betöltőt egy külső programozóval a 6. kérdésben leírtak szerint. Be kell állítania a szükséges fúziós értékeket, beleértve a BOOTSZ és BOOTRST értékeket is. Ezután egyszerűen használhatja a szokásos bootloader kommunikációs mechanizmust az átvitelhez és a firmware-hez az alkalmazás mikrokontrolleréhez.
Egy lépésben: egyesíti az app.hex és a boot.hex fájlokat egybe, és használjon külső programozót az összevont fájl mikrokontrollerbe írásához. Lehet, hogy be kell állítania a szükséges fúziós értékeket, beleértve a BOOTSZ-ot és a BOOTRST-t.
Úgy gondolom, hogy a hexadecimális fájlok kombinálásának legegyszerűbb módja a srec_cat parancssori használata. Ez az eszköz szerepel a srecord eszköztárban. Jön a WinAVR-hez, és nagyon könnyű telepíteni Unix-szerű operációs rendszerekhez. Itt van a következő parancs:
Szintén manuálisan egyesítheti az app.hex és a boot.hex fájlokat kis módosításokkal:
Minden hex fájlnak van egy utolsó bejegyzése, amely kimondja, hogy "a fájl véget ér." Ezért, miután a kézi egyesület szerkeszteni kívánt egyesített hex file -, hogy megtalálja benne a végén a rekord fájl végén található a app.hex (miután egyesült valahol középen a fájl), és törölje azt. Felvétel írja 01. A byte rekord típusának hexadecimális Intel érdekében formátum 4 byte, így a rekord valóban így fog kinézni: «: 00000001FF». Az egész sort (a középen, nem pedig a fájl végén) törölni kell.
Használhatok megszakításokat a rendszerbetöltőben?
Igen, ehhez elegendő megmondani a processzort, hogy használja a megszakítási vektort, amely a bootloader területen található, és nem az alkalmazási területen. Ehhez valahol a betöltõkód elején (a megszakítások használata elõtt) hozzá kell adnia az alábbi sorokat:
Ezután a megszakítások alatt a programszámláló a betöltő tábla szerinti megfelelő helyzetbe kerül. Normál működés esetén a fenti kódsorozatot optimalizálásra kell fordítani, és kézzel ellenőrizni kell, hogy az eredményül kapott összeállítás tartalmazza-e a 4 gépi ciklusra végrehajtott parancsokat.
Mi kell letöltenie először - a betöltőt vagy alkalmazást?
Szinte mindig a legjobb a BOOTRST fotók telepítése annak érdekében, hogy a rendszerindító először a mikrokontroller újraindítása után induljon el. Amikor a rendszerindító betöltő újraindulása után elindul, először újraindíthatja a programot, függetlenül attól, hogy az alkalmazás kódja sérült vagy egyáltalán nem.
A rakodók legjobb munkájához szükséges, hogy kis, megbízható és ritkán módosított programokat képviseljenek. A készülék üzembe helyezésének napjától kezdve tényleg nem akarja megváltoztatni a rendszerindítót. A kérelem ezzel szemben nagyobb szabadságot igényel a frissítés szempontjából. Ha egy alkalmazás hiba lép fel, ami a hiba, vagy baleset, vagy vakuval töltse áramszünet erőteljes boot loader, hogy indul az első, hogy képes legyen a helyzet javítására gond nélkül.
Ha az alkalmazás az eszköz visszaállítása után indul el, a külső problémák megoldásához használhat külső programozót. De ha a készüléknek nincs interfésze a programozó csatlakoztatásához, akkor a készüléket leginkább eldobni vagy forrasztani kell.
Honnan tudhatom, mikor kell elindítania az alkalmazást?
Sok lehetőség van. Ha a készüléknek van egy gombja vagy más bemeneti mechanizmusa, a megfelelő jelet a gomb megnyomásával küldheti el. Ezután a betöltő rendszeresen elindítja az alkalmazást. Abban az esetben, ha a gombot nem nyomja meg a resetelés során, a betöltő folytatja a végrehajtást. Ez egy példa arra, hogyan működik az STK500 chipletöltő.
A bootloader másik gyakori megoldása az, hogy az indítás során ellenőrizze a külső hivatkozást egy speciális karakterre. Ismét a betöltő rendszerint elindítja az alkalmazást, de a külső kommunikációs csatorna ellenőrzése után továbbra is végrehajtásra kerül, és konkrét választ kap vagy a várt adatok keresését. Ennek a megközelítésnek az egyik példája az Atmel Butterfly.
Esetünkben egyik ilyen megoldás sem alkalmas. A készülékünknek nincsenek gombjai, és szeretnénk, ha az alkalmazás normális körülmények között gyorsan fut. Az egyetlen külső kommunikációs csatorna az USB, sajnos az USB eszköz némi időt vesz igénybe (a processzor kifejezésben), mielőtt az adatcsere a gazdával lehetséges.
Tehát ezt tettük: feltételezve, hogy az AVR-nek EEPROM-e van, tárolhat bájtértéket, ami azt jelzi, hogy a betöltőnek mikor kell működnie, és mikor kell elindítania az alkalmazást. Ez a megközelítés két lépést tartalmaz. Először is, valahol a rendszerindító kód elején, ehhez hozzá kell rendelnie:
Ha valahol messze van az alkalmazásban, a kód azon részében, amikor feldolgozza, amelyről már biztos benne, hogy az alkalmazás megfelelően működik, adja hozzá a következőket:
Azt is javaslom, hogy kényszerítsd a bootloadert az alkalmazásból. Csak törölni kell az APP_RUN byte-jét, és meg kell előznie a népszámlálást később. Ezt végrehajtottuk alkalmazásunkban, és ezt a számítógépen futó program USB-n keresztül küldött parancs végzi.
Ennek a megközelítésnek az egyik hátránya, hogy az Atmel EEPROM a legtöbb vezérlőnek 100 000 írási / törlési ciklusra van szüksége. Mivel ez a megközelítés két törlési / írási ciklust eredményez minden egyes indítás során, az eszközforrás csak 50 000 újraindítási ciklusra korlátozódik. Alkalmazásunk szerint becsültem, hogy a készülék élettartama átlagosan 13,7 év, napi 10 újraindítással. Ez a határérték könnyen meghosszabbítható, ha az EEPROM-cellák kopása eloszlik.
Hogyan kezdheti meg a betöltő az alkalmazást?
De ez nem minden. Ha közvetlenül futtatja az alkalmazást, a mikrokontroller nem lesz alaphelyzetbe állítva, mint az újraindítás után. A regiszterek értékei nem törlődnek, és a periféria nincs kikapcsolva. Kétféle módon lehet megoldani ezt. Az első megközelítés az, hogy szándékosan indítson újraindítást egy watchdog időzítő segítségével. Ez visszaállítja a mikrokontrollert az eredeti állapotába és újraindítja a bootloadert (ha van BOOTRST bitkészlete). Ha a betöltõt okozó feltételek már nem állnak (pl. Már nem tartja a gombot), akkor a betöltõnek azonnal el kell indítania az alkalmazást. A kérelem végrehajtását a lehető leghamarabb el kell indítani, amíg a változások a lehető legkevesebb mértékben érintik a mikrokontroller erőforrásait. Íme egy példa:
Az alkalmazásnak ezután kifejezetten meg kell határoznia az összes használni kívánt erőforrást.