OTA bootloadert írunk az ATmega128RFA1-hez (a Smart Response XE eszköz részeként)

OTA bootloadert írunk az ATmega128RFA1-hez (a Smart Response XE eszköz részeként)

Az egész azzal kezdődött, hogy a szerző egy érdekes eszközt vásárolt a másodlagos piacon - a Smart Response XE (Rövid leírás). Iskoláknak szánjuk: az osztály minden tanulója kap egy elektronikus jegyzetfüzethez hasonló készüléket vagy a kilencvenes évek fordítóját, a tanár feltesz egy kérdést, a diákok pedig a készülékek billentyűzetén gépelik be a válaszokat, amelyeket egy rádiócsatornát (802.15.4) a tanár PC-jéhez csatlakoztatott vevőhöz.

Ezeket az eszközöket néhány évvel ezelőtt leállították, és amit az iskolák egyenként 100-200 dollárért vásároltak, az most 10 dollárért vagy még kevesebbért jelenik meg az eBay-en. Az ott található hardver nagyon alkalmas geeky kísérletekre:

  • 60 billentyűs billentyűzet
  • 384×136 felbontású kijelző, 2 bit/pixel - hasonló a BC-hez, CGA-hoz, de 4 nem szín, hanem fényerő fokozatok
  • ATmega128RFA1 mikrokontroller (128 kB flash memória, 4 kB ROM, 16 kB RAM, 802.15.4 adó-vevő)
  • külső (a mikrokontrollerhez viszonyítva, nem a teljes eszközhöz) 1 megabites (128 kilobyte) flash memória SPI interfésszel
  • rekesz 4 db AAA elemnek.

A mikrokontroller nevéből egyértelműen kiderül, hogy az AVR családba tartozik, ami azt jelenti, hogy a készüléket Arduino-kompatibilissé tenni több mint triviális feladat...

A hírektől kezdve Hackaday a szerző rájött, mi az már megtették (ugyanaz a link megmondja, hogy mit hova kell csatlakoztatni), lehetőség van arra, hogy játékokat futtasson az Arduboy számára:


De a szerzőt jobban érdekli a lehetőség, hogy ne játsszon az eszközön, hanem tanuljon:

  • flash memória soros SPI interfésszel
  • rendszerbetöltők az AVR-hez
  • szabvány 802.15.4

A szerző írással kezdte könyvtár (GPL v3), amely lehetővé teszi a kijelző inicializálását, a szöveg és a téglalapok kimenetét, valamint az SPI flash memória elérését. Aztán elkezdett ötletelni az eszköz gyakorlati felhasználására: VT-100-kompatibilis zsebterminál, többjátékos játékok. Három készülék újjáépítése után úgy döntött, hogy „megtanítja” őket „éteren keresztül” vázlatok fogadására. Ami nem csak érdekes, de nagyon kényelmes is lenne: a készülékházat minden alkalommal nehéz kinyitni, az elemtartó fedele alatt pedig csak olyan lyukak vannak, amelyeken JTAG programozót csatlakoztathatunk az alaplaphoz.

OTA bootloadert írunk az ATmega128RFA1-hez (a Smart Response XE eszköz részeként)

Ez elég az Arduino rendszerbetöltő feltöltéséhez, de a vázlatot nem - a soros port nincs oda csatlakoztatva, így továbbra sem teheti meg a ház kinyitása nélkül. Ezenkívül az első soros port TX0 és RX0 sorai kombinálva vannak a billentyűzet mátrix lekérdezési soraival, vagyis azokkal, amelyek lekérdezik a kijelző oldalán található funkcióbillentyűket. De mit tehetsz - a szerző ezt építette:

OTA bootloadert írunk az ATmega128RFA1-hez (a Smart Response XE eszköz részeként)

Oda hozta a JTAG vezetékeket, és most már nem kell kinyitni az elemtartót. És hogy a vázlatokat fel lehessen tölteni, mindkét soros portot ugyanarra a csatlakozóra kötöttem, egy kapcsolóval is kiegészítve, mert a behelyezett akkumulátorokkal fizikailag lehetetlen más módon kikapcsolni a készüléket.

A forrasztópákával, a segédkéssel és a ragasztópisztollyal való munka elég sok időt vett igénybe. Általában a vázlatok „éteren keresztül” feltöltése sokkal kényelmesebb, ehhez sürgősen ki kell találnunk valamit.

Az Arduino IDE a programot használja a vázlatok feltöltésére avrdude. A protokoll segítségével kommunikál a mikrokontrollerrel STK500, amely lehetővé teszi a fájlok mindkét irányba történő átvitelét. Rosszul kompatibilis azokkal a csatornákkal, ahol változó késleltetés, torzítás és adatvesztés lehetséges. Ha valami kilazul vagy zúg a soros csatornában, megőrülhet az ok keresése. Egyszer a szerző fél napig szenvedett, míg rájött, hogy a probléma egy rossz kábel, valamint egy szeszélyes CP2102 interfész konverter. Még egy beépített interfész konverterrel rendelkező mikrokontroller is, például ATmega32u4, néha így viselkedhet. Minden Arduino-felhasználó észrevette, hogy a vázlatok feltöltésekor a hibák nem olyan ritkák. Néha a felvétel jól megy, de a tesztolvasás során hibát észlel. Ez nem azt jelenti, hogy hiba történt az írás során - hiba történt az olvasás során. Most képzelje el, hogy amikor „levegőn keresztül” dolgozik, ugyanez fog megtörténni, de sokkal gyakrabban.

Miután a szerző különféle módokon próbálta megoldani ezt a problémát, a következőre jutott. A készülék 128 KB-os SPI interfésszel ellátott flash memóriával rendelkezik - vezetékeken keresztül fogadjuk az adatokat (ne feledjük, hogy a szerzőnek már van egy olyan készüléke, aminek oldalán van egy csatlakozó), ezt a memóriát használjuk pufferként, és rádión küldjük el az adatokat. csatornát egy másik eszközre. Üdvözlet Cybikoból.

Miután megírta a kódot, hogy működjön együtt a rádiócsatornával, valamint a betűtípussal, a betöltő 4 kilobájtnál hosszabb lett. Ezért a HFUSE értéket 0xDA-ról 0xD8-ra kellett módosítani. Mostantól a rendszerbetöltő akár 8 kilobájt hosszú is lehet, a kiindulási cím pedig 0x1E000. Ezt tükrözi a Makefile, de a kitöltésnél is figyelembe kell venni rendszerbetöltő via avrdude.

Az ATmega802.15.4RFA128 1 adó-vevőjét eredetileg úgy tervezték, hogy a protokoll használatával működjön ZigBee, ami meglehetősen bonyolult, ezért a szerző úgy döntött, hogy inkább csak csomagokat továbbít. Ez az ATmega128RFA1 hardverben van megvalósítva, így kevés kódra van szükség. Ezenkívül az egyszerűség kedvéért a szerző úgy döntött, hogy rögzített csatornát használ, és nem teszi lehetővé annak manuális kiválasztását. A 802.15.4 szabvány 16 csatornát támogat, 11-től 26-ig terjedő számokkal. Ezek meglehetősen zsúfoltak, némelyik átfedi a WiFi csatornákat is (a piros a ZigBee csatornák, a kék, a zöld és a sárga a WiFi).

OTA bootloadert írunk az ATmega128RFA1-hez (a Smart Response XE eszköz részeként)

Kiderült, hogy a 15-ös és a 26-os csatorna a legkevésbé érzékeny a WiFi interferenciájára, ezek közül a szerző a másodikat választotta. Jogi nyilatkozat: a fordító nem tudja, hogy szabad-e így egyszerűsíteni a ZigBee-t. Talán egy kicsit több programozást kellene végeznünk és teljesen megvalósítanunk?

Az első eszközön egy véges állapotú gépet kell megvalósítani, amely az STK500 protokollon keresztül továbbítja az adatokat. A továbbított és fogadott üzenetek többnyire önellátóak, de vannak olyanok is, amelyek a csatornán korábban áthaladókhoz kötődnek. A párbeszéd leírása megtalálható itt.

Ennek a párbeszédnek fontos eleme a céleszköz flash memóriájába írandó csomagok továbbítása. Az AVR családba tartozó egyszerű mikrokontrollereknél az oldalméret 128 bájt, az ATmega128RFA1 esetében viszont 256. Az SPI protokollon keresztül csatlakoztatott flash memóriánál pedig ugyanez. Az első eszközben lévő program egy vázlat feltöltésekor nem viszi át azonnal a másodikra, hanem ebbe a memóriába írja. Amikor az Arduino IDE ellenőrzi a bejegyzés helyességét, elküldi az ott leírtakat. Most a kapott adatokat rádiócsatornán keresztül kell továbbítanunk a második eszközre. Ugyanakkor a vételről az adásra és a visszaváltásra meglehetősen gyakran kerül sor. Az STK500 protokoll közömbös a késleltetésekkel szemben, de nem tolerálja az adatvesztést (furcsa, de fentebb elhangzott, hogy a késések az adatátvitelt is befolyásolják). A vezeték nélküli átvitel során bekövetkező veszteségek pedig elkerülhetetlenek. Az ATmega128RFA1 beépített hardveres implementációval rendelkezik az ismételt kérésekre, amikor kétségek merülnek fel az átvitel helyességével kapcsolatban, de a szerző úgy döntött, hogy ugyanezt saját maga implementálja szoftverben. Kifejlesztett egy protokollt, amelyben sokkal több adat áramlik egyik irányba, mint a másik irányba.

Nem tökéletes, de működik. A 256 bájtos oldal négy szegmensre van osztva, amelyek mindegyike csomagként kerül továbbításra az éteren keresztül. Egy csomag legfeljebb 125 bájt adatot tartalmazhat, plusz egy bájt hosszúságot és két bájt CRC-t. Tehát a 64 bájt hosszú töredékek az oldal- és szegmensszámokkal együtt (0-tól 3-ig) kerülnek oda. A fogadó eszköznek van egy változója, amivel nyomon tudja követni, hogy hány szegmens érkezett, és amikor mind a négy megérkezik, a küldő készülék visszaigazolást kap arról, hogy a teljes oldal vétele megtörtént. Nincs megerősítés (a CRC nem egyezik) - küldje el újra a teljes oldalt. A sebesség még nagyobb, mint a kábeles átvitelnél. Lát:


De általánosságban szükséges lenne egy kényelmes módot biztosítani a kábel csatlakoztatására a vázlatok feltöltésére szolgáló eszközökhöz és azon keresztül. Például helyezzen be egy ilyen interfész konvertert a CP2102-re, mint a képen, és ragassza a táblára, hogy ellenálljon a Micro USB kábel csatlakoztatásakor és leválasztásakor jelentkező erőnek.

OTA bootloadert írunk az ATmega128RFA1-hez (a Smart Response XE eszköz részeként)

3,3 voltos stabilizátor is van benne (és hogyan kell használni egy 6 voltos tápegységgel rendelkező készülékben - ha csak ugyanaz a stabilizátor van, és két diódával lehet automatikusan kiválasztani, hogy melyik táplálja a készüléket) . Mindhárom LED-et le kell forrasztani az interfész átalakító kártyáról, különben az akkumulátorokat is terhelik, ha működnek rajtuk, és zavarják a billentyűzet lekérdezését és az SPI interfésszel rendelkező flash memóriával való munkát.

A cél elérése még érdekesebbnek bizonyult, mint annak elérése (és nem kell ez a vicc a busszal). A szerző sokat tanult az AVR rendszerbetöltőkről, az SPI flash memóriáról, az STK500 protokollról és a 802.15.4 szabványról.

A fent leírt könyvtáron kívül minden más kód − itt, és a GPL v3 alatt is működik. A szerző Twittere - itt.

Forrás: will.com

Hozzászólás