Vi skriver en OTA-laddare för ATmega128RFA1 (i enheten Smart Response XE)

Allt började med att författaren köpte en intressant enhet på andrahandsmarknaden — Smart Response XE (kort beskrivning). Den är avsedd för skolor: varje elev i klassen får en enhet som liknar en elektronisk anteckningsbok eller en översättare från nittiotalet, läraren ställer en fråga, och eleverna skriver sina svar på enhetens tangentbord, som sänds via radiokanal (802.15.4) till en mottagare kopplad till lärarens dator.

Stödet för dessa enheter upphörde för flera år sedan, och det som skolor köpte för 100-200 dollar styck dyker nu upp på eBay för 10 eller mindre. 'Hårdvaran' där passar verkligen för nördiga experiment:

• ett tangentbord med 60 tangenter
• en skärm med en upplösning på 384×136, 2 bitar per pixel — liknande BK, CGA, men 4 färger, utan gradationer av ljusstyrka
• mikrokontroller ATmega128RFA1 (128 kB flashminne, 4 kB EEPROM, 16 kB RAM, sändare/mottagare av standard 802.15.4)
• extern (i förhållande till mikrokontrollern, inte hela enheten) flashminne på 1 megabit (128 kilobyte) med SPI-gränssnitt
• fack för 4 AAA-batterier.

Av namnet på mikrokontrollern framgår att den tillhör AVR-familjen, och att göra enheten Arduino-kompatibel är en mer än trivialisak uppgift...

Från nyheten på Hackaday fick författaren veta att detta redan har gjorts (i samma länk förklaras vad som ska kopplas till var), vilket ger möjlighet att köra spel för Arduboy:

Men författaren är mer intresserad av möjligheten att inte bara spela på enheten, utan att studera:

• flashminnet med seriellt SPI-gränssnitt
• bootloaders för AVR
• standard 802.15.4

Författaren började med att skriva bibliotek (GPL v3), vilket möjliggör att initiera skärmen, visa text och rektanglar, samt få tillgång till flashminnet med SPI-gränssnitt. Sedan började han tänka på idéer för praktisk användning av enheten: en fick VT-100-kompatibel terminal, multiplayer-spel. Efter att ha modifierat tre enheter bestämde han sig för att 'lära' dem att ta emot sketches 'över luften'. Det skulle vara både intressant och mycket bekvämt: det är svårt att öppna enhetens hölje varje gång, och under batterifacket finns bara hål för att koppla JTAG-programmeraren till kortet.

Detta är tillräckligt för att ladda upp bootloadern för Arduino, men inte sketcher – seriellporten är inte utkopplad, så utan att öppna höljet kommer man inte undan. Dessutom är TX0- och RX0-linjerna för den första seriella porten ihopkopplade med linjerna som används för att fråga tangentbordsmatrisen, det vill säga de som också används för att fråga funktionsknapparna på sidorna av skärmen. Men vad ska man göra – författaren har konstruerat det här:

Till dessa har han kopplat JTAG-linjerna, och nu är det inte längre nödvändigt att öppna batterifacket. För att man också ska kunna ladda upp sketcher har han kopplat båda de seriella portarna till samma kontakt, och lagt till en strömbrytare, eftersom det på annat sätt är omöjligt att stänga av enheten med installerade batterier.

Det tog ganska lång tid att arbeta med lödkolven, en skrivkniv och en limpistol. Generellt sett är det betydligt enklare att ladda upp sketcher "trådlöst"; man måste snabbt hitta något för detta.

Arduino IDE använder programmet för att ladda upp sketcher avrdude. Det interagerar med mikrokontrollern enligt protokollet STK500, vilket möjliggör överföring av filer i båda riktningarna. Det är dåligt kompatibelt med kanaler där variabla fördröjningar, distorsion och dataförlust kan inträffa. Om det är något som knastrar eller bråkar i den seriella kanalen kan man bli galen av att söka efter orsaken. En gång kämpade författaren en halv dag innan han insåg att det berodde på en dålig kabel, samt en nyckfull interfacekonverter CP2102. Till och med en mikrokontroller med inbyggd interfacekonverterare, som ATmega32u4, kan ibland göra likadant. Varje Arduino-användare har märkt att fel vid uppladdning av sketcher inte är så ovanliga. Ibland går skrivningen bra, men vid kontrollerande läsning upptäcks ett fel. Det betyder inte att felet var vid skrivningen – problemet uppstod vid läsningen. Och tänk nu att om man arbetar "trådlöst" kan samma sak hända, men mycket oftare.

Efter att ha prövat olika sätt att övervinna detta problem, kom författaren på följande. Enheten har 128 kilobyte flashminne med SPI-interface – vi tar emot data via kablar (vi kommer ihåg att författaren redan har en enhet med en kontakt på sidan), använder detta minne som en buffert och skickar data till en annan enhet via radiokanalen. En hälsning från Cybiko.

Efter att ha skrivit koden för att arbeta med radiokanalen samt teckensnittet blev bootloader längre än 4 kilobyte. Därför var det nödvändigt att ändra värdet på HFUSE från 0xDA till 0xD8. Nu kan bootloadern vara upp till 8 kilobyte lång, och startadressen har blivit 0x1E000. Detta återspeglas i Makefile, men det måste också beaktas vid uppladdning. bootloader med hjälp av avrdude.

Sändarmottagaren i standarden 802.15.4 i ATmega128RFA1 var ursprungligen avsedd för att arbeta enligt protokollet ZigBee, vilket är ganska komplext, så författaren beslutade att istället bara överföra paket. Detta är implementerat hårdvarumässigt i ATmega128RFA1, så det krävs lite kod. För enkelhetens skull beslutade författaren också att använda en fast kanal och inte ge möjlighet att välja den ens manuellt. Standard 802.15.4 stöder 16 kanaler med nummer från 11 till 26. De är ganska överbelastade, och vissa överlappar även med WiFi-kanaler (röd markerar ZigBee-kanaler, blå, grön och gul markerar WiFi).

Det visade sig att de kanaler som är minst känsliga för störningar från WiFi är 15 och 26. Den andra av dessa valde författaren. Ansvarsfriskrivning: översättaren vet inte om det är tillåtet att förenkla ZigBee på detta sätt. Kanske borde man programmera lite mer och implementera det helt?

På den första enheten måste en slutautomat implementeras som överför data enligt protokollet STK500. I allmänhet är de sända och mottagna meddelandena självförsörjande, men vissa är bundna till de som tidigare passerat genom kanalen. Beskrivningen av dialogen är angiven. här.

En viktig del av denna dialog är överföringen av paket som är avsedda för att skrivas till flashminnet på destinationsenheten. För enkla mikrokontroller av AVR-familjen är sidstorleken 128 byte, men för ATmega128RFA1 är den 256. Och för det flashminnet som ansluts via SPI-protokollet är den densamma. Programmet i den första enheten överför inte sketch direkt till den andra, utan skriver det till detta minne. När Arduino IDE kontrollerar skrivningens korrekthet, skickas det som har skrivits dit tillbaka. Nu måste de mottagna uppgifterna överföras via radiokanalen till den andra enheten. Under detta sker växlingen mellan mottagning och sändning ganska ofta. STK500-protokollet är oavsett för fördröjningar, men tål inte dataförlust (konstigt, men ovan nämnts att fördröjningar vid dataöverföring också påverkar). Men förluster vid trådlös överföring är oundvikliga. ATmega128RFA1 har en hårdvaruimplementering av återbegäran vid tvivel om korrektheten i överföringen, men författaren beslutade att genomföra detta programmässigt själv. Han utvecklade ett protokoll där det går betydligt mer data i en riktning än i den andra.

Det är inte perfekt, men allt fungerar. Den 256-byte sidor delas upp i fyra segment, där varje segment överförs via radiokanalen i form av ett paket. Paketet rymmer upp till 125 byte data plus en byte – längden och två – CRC. Så fragment på 64 byte ryms tillsammans med sid- och segmentnummer (från 0 till 3) där. På mottagarenheten finns en variabel som gör det möjligt att spåra hur många segment som har tagits emot, och när alla fyra kommer, går en bekräftelse tillbaka till sändarenhet att hela sidan har tagits emot. Ingen bekräftelse (CRC stämmer inte) – vi skickar hela sidan igen. Hastigheten får till och med vara större än vid överföring via kabel. Se:

Men egentligen borde vi förutse ett bekvämt sätt att ansluta en kabel till enheterna för att ladda upp sketcher via den. Till exempel, placera en sådan gränssnittskonverterare som CP2102 inuti, som på bilden, och klistra fast den på kortet så att den klarar ansträngningen vid anslutning och frånkoppling av Micro USB-kabeln.

Det finns också en 3,3-volts stabilisator (och hur man använder den i en enhet med 6-volts strömförsörjning — om det finns en liknande stabilisator där, går det att lägga till två dioder för att automatiskt välja vilken av dem enheten ska drivas av). Alla tre lysdioderna måste avlägsnas från gränssnittets omvandlingskort, annars kommer de att belasta batterierna ytterligare när de drivs av dem och också störa läsningen av tangentbordet och användningen av flashminnet med SPI-gränssnitt.

Att sträva efter målet visade sig vara ännu mer intressant än att uppnå det (och jag behöver inte berätta den där skämtet om bussen). Författaren lärde sig mycket nytt om bootloaders för AVR, flashminnen med SPI-gränssnitt, STK500-protokollet och 802.15.4-standarden.

All annan kod utöver det som beskrivits ovan är här, och den är också under GPL v3. Författarens Twitter — här.

Källa: habr.com