Minden azzal kezdődött, hogy a szerző egy érdekes eszközt vásárolt a másodlagos piacon — Smart Response XE (). Az iskolák számára készült: minden tanulónak jut egy készülék, amely hasonlít egy elektronikus jegyzetfüzetre vagy a kilencvenes évek fordítójára, a tanár kérdést tesz fel, és a tanulók beírják a válaszaikat az eszközök billentyűzetén, amelyek rádiófrekvencián (802.15.4) érkeznek a tanári számítógéphez csatlakozó vevőegységhez.
Ezeknek az eszközöknek a támogatása már néhány éve megszűnt, és amiért az iskolák 100-200 dollárt költöttek darabonként, az most az eBay-en 10 dollárért vagy annál kevesebbért kapható. Az „alkatrészek” valóban a geekek kísérletezésére alkalmasak:
- 60 billentyűs billentyűzet
- 384×136 felbontású kijelző, 2 bit pixelként — hasonlóan a BK-hoz, CGA-hoz, de nem 4 szín, hanem fényerő fokozatok
- ATmega128RFA1 mikrokontroller (128 kB flash memória, 4 kB EEPROM, 16 kB RAM, 802.15.4 szabványú adó-vevő)
- külső (a mikrokontrollerhez képest, nem az egész eszközhöz) 1 megabites (128 kilobájt) flash memória SPI interfésszel
- rekesz 4 AAA elemmel.
A mikrokontroller nevéből nyilvánvaló, hogy az AVR családhoz tartozik, így az eszköz Arduino-kompatibilissé tétele több mint trivialis feladat…
A cikkből a szerző megtudta, hogy ezt (ugyanott található a csatlakoztatási útmutató), így lehetőség nyílt Arduboy játékok indítására:
De a szerzőt jobban érdekli az a lehetőség, hogy ne csak játsszon az eszközzel, hanem tanulmányozza:
- soros SPI interfészes flash memória
- AVR bootloaderek
- 802.15.4 szabvány
A szerző azzal kezdte, hogy megírta (GPL v3), amely lehetővé teszi a kijelző inicializálását, szöveg és téglalapok megjelenítését, valamint a flash memória elérését SPI interfészen keresztül. Ezután elkezdte kigondolni az eszköz gyakorlati felhasználásának ötleteit: zsebre rakható VT-100 kompatibilis terminál, többjátékos játékok. Három eszköz átalakítása után úgy döntött, hogy „megtanítja” őket, hogy „légúton” kapják meg a sketch-eket. Ez nemcsak izgalmas lenne, hanem rendkívül kényelmes is: az eszköz házát minden alkalommal nehéz kinyitni, és az akkumulátorrekesz fedele alatt csak nyílások vannak, amelyek lehetővé teszik a JTAG programozó csatlakoztatását a nyomtatott áramkörhöz.
Ez elegendő az Arduino bootloader feltöltéséhez, de nem a sketch-hez – a soros port nem került kivezetésre, ház bontása nélkül nem lehet megoldani. A TX0 és RX0 vonalak az első soros portnál a billentyűzet mátrix kérésével összevonva vannak, mégpedig azokkal, amelyeken a funkciógombok kérdezése történik a kijelző két oldalán. De mit lehet tenni – a szerző ezt alkotta:
Ezeket JTAG vonalakat kivezetett oda, így most már nem szükséges a elem tárolóját kinyitni. Annak érdekében, hogy a sketch-eket is feltölthessük, a soros portokat is a csatlakozóra vezette ki, hozzáadva egy kapcsolót, mivel az akkumulátorok telepítésekor a készüléket fizikailag másként nem lehet kikapcsolni.
Elég sokáig kellett dolgozni a forrasztópákkal, papírvágó késsel és ragasztópisztollyal. Összességében a sketch-ek "a levegőn" való feltöltése sokkal kényelmesebb, sürgősen valami újítást kell kitalálni.
Az Arduino IDE a sketch-ek feltöltésére a következő programot használja: . Ez a mikrokontrollerrel STK500 protokollon keresztül kommunikál, amely lehetővé teszi a fájlok két irányban történő átadását. Rosszul kompatibilis azokkal a csatornákkal, ahol változó késleltetések, torzítás és adatok elvesztése lehetséges. Ha a soros csatornában valami nem jól működik vagy serceg, megőrülhetünk a hiba keresése közben. Egyszer a szerző fél napig szenvedett, míg rájött, hogy a probléma egy rossz kábellel és a CP2102 interfész-konverter szeszélyeivel függ össze. Még a beépített interfész-konverterrel rendelkező mikrokontrollerek, például az ATmega32u4 is néha így viselkedhetnek. Minden Arduino-felhasználó észrevette, hogy a sketch-ek feltöltésénél a hibák nem olyan ritkák. Néha a felvétel simán zajlik, de a teszteléskor hibát találunk. Ez nem azt jelenti, hogy a hiba a felvételkor volt – a probléma az olvasásnál jelentkezett. Most pedig képzeljék el, hogy "a levegőn" történő működés során ugyanez gyakrabban fog bekövetkezni. , amely lehetővé teszi a fájlok kétirányú továbbítását. Rosszul kompatibilis az olyan csatornákkal, ahol változó késések, torzítás és adatvesztés fordulhat elő. Ha egy soros csatornán valami remeg vagy úgy zötyög, az őrületbe kergetheti az embert a hiba okának keresésében. Egyszer a szerző fél napig szenvedett, amíg rájött, hogy a probléma a rossz kábelben és a kényes CP2102 interfészkonvertálóban rejlik. Még egy beépített interfészkonvertálóval rendelkező mikrokontroller, például az ATmega32u4 is néha hasonlóan viselkedhet. Minden Arduino-felhasználó észrevette, hogy a szkennek feltöltésekor a hibák nem annyira ritkák. Néha a felvétel rendben zajlik, de a visszaellenőrzéskor hiba lép fel. Ez nem jelenti azt, hogy a hiba a felvétel során történt – a hiba az olvasáskor történt. Most képzeljétek el, hogy a 'légies' működéskor ugyanez fog megtörténni, de sokkal gyakoribb gyakorisággal.
Különféle módszerek kipróbálása után a szerző a következőt találta ki. Az eszköznek van egy 128 kilobájtos SPI interfészű flashmemóriája – adatokat fogadunk a vezetékeken (ne felejtsük el, hogy már van egy eszközöm oldalsó csatlakozóval), ezt a memóriát pufferként használjuk, és rádiócsatornán keresztül küldjük az adatokat egy másik eszközbe. Itt egy üdvözlet a Cybiko-tól.
A kód megírása után, amely a rádiócsatornával dolgozik, valamint a betűtípus, a betöltő hossza meghaladta a 4 kilobájtot. Ezért a HFUSE értékét 0xDA-ról 0xD8-ra kellett változtatni. Most a betöltő hossza akár 8 kilobájt is lehet, és a kezdeti cím 0x1E000-ra változott. Ez a Makefile-ben is tükröződik, de figyelembe kell venni a feltöltés során is. avrdude segítségével.
Az ATmega128RFA1 802.15.4 szabványnak megfelelő adó-vevője eredetileg a -protokoll működtetésére lett tervezve, ami meglehetősen összetett, ezért a szerző úgy döntött, hogy egyszerűen csak csomagokat továbbít. Ez az ATmega128RFA1-en hardveresen van megvalósítva, így a kódra csak kis mennyiségben van szükség. A szerző a egyszerűség kedvéért úgy döntött, hogy rögzített csatornát használ, nem engedve meg annak manuális kiválasztását. Az 802.15.4 szabvány 11-től 26-ig terjedő 16 csatornát támogat. Ezek viszonylag zsúfoltak, némelyek a WiFi csatornáival is átfedik egymást (a ZigBee csatornák pirossal, a WiFi csatornák kék, zöld és sárga színnel jelölve).
Kiderült, hogy a WiFi zavaraira a legkevésbé érzékeny csatornák a 15 és 26. A szerző a második csatornát választotta. Kérjük, vegye figyelembe: a fordító nem tudja, hogy lehet-e így egyszerűsíteni a ZigBee-t. Talán érdemes lenne még egy kicsit programozni, és teljes mértékben megvalósítani?
Az első eszközön egy állapotautomatát kell megvalósítani, amely adatokat küld az STK500 protokoll szerint. Nagy részt az átküldött és átvett üzenetek önállóak, de egyesek korábban a csatornán áthaladókhoz vannak kötve. A párbeszéd leírása alább található. .
A párbeszéd fontos része a célkészülék flash memóriájába való írásra szánt csomagok átadása. Az AVR mikrovezérlők egyszerűbb típusaiban az oldalméret 128 bájt, de az ATmega128RFA1 esetében 256. A SPI protokollal csatlakozó flash memóriának is ugyanakkora. Az első eszközben a program, amikor a kódot tölti, nem küldi azonnal a másodiknak, hanem az először a memóriába írja. Amikor az Arduino IDE ellenőrzi a helyes írást, azt küldi el, ami oda került. Most a kapott adatokat át kell adni a rádiócsatornán a második készüléknek. Ekkor a vétel és a küldés közti váltás viszonylag gyakran megtörténik. Az STK500 protokoll nem érzékeny a késésekre, de nem tolerálja az adatvesztést (furcsa, pedig fentebb azt írták, hogy a késések is hatással vannak az adatok átvitelére). Azonban a vezeték nélküli átvitel esetén az adatvesztés elkerülhetetlen. Az ATmega128RFA1-ben van egy hardveres implemNetációja a megkérdőjelezett átvitel újrakérésének, de a szerző úgy döntött, hogy ugyanazt programozott módon valósítja meg. Kidolgozott egy protokollt, amelynél az egyik irányban sokkal több adat halad át, mint a másik.
Nem tökéletes, de minden működik. A 256 bájtos oldal négy szegmensre van osztva, amelyeket mindegyikét csomagként küldenek át a rádiócsatornán. A csomag legfeljebb 125 bájt adatot, plusz egy bájt – hosszúság és két bájt – CRC. Így a 64 bájt hosszúságú darabok a lapok és szegmensek számaival (0-tól 3-ig) együtt kerülnek küldésre. A vevőegységben van egy változó, amely nyomon követi, hány szegmens érkezett, és amikor mind a négy megérkezik, a küldő egység egy megerősítést kap arról, hogy az egész oldal megérkezett. Ha nem érkezik megerősítés (ha a CRC nem egyezik), akkor az egész oldalt újra elküldjük. Ilyenkor a sebesség még nagyobb, mint vezetékes átvitel esetén. Nézd:
De egyébként érdemes lenne kényelmes csatlakozási módot biztosítani a készülékekhez, hogy kábelen tudjunk kódokat feltölteni. Például beépíteni egy olyan CP2102 interfész-átalakítót, mint a képen, és rögzíteni a panelhez úgy, hogy bírja a Micro USB kábel csatlakoztatásakor és eltávolítanakor fellépő erőt.
A 3.3-volt stabilizer is also included (and how to use it in a 6-volt powered device — only if there is a similar stabilizer present, and two diodes can be added to automatically select which one the device will draw power from). All three LEDs on the interface converter board must be desoldered; otherwise, they will additionally load the batteries when powered from them, and also interfere with the keyboard polling and operation with flash memory using the SPI interface.
The pursuit of the goal turned out to be even more interesting than achieving it (and let’s not mention that anecdote about the bus). The author learned a lot about bootloaders for AVR, flash memory with SPI interface, STK500 protocol, and the 802.15.4 standard.
The rest of the code in addition to the library described above — , and it is also licensed under GPL v3. The author's Twitter — .
Forrás: habr.com
