Det hele startet med at forfatteren kjøpte en interessant enhet på annenhåndsmarkedet - Smart Response XE (). Den er beregnet på skoler: hver elev i klassen mottar en enhet som ligner på en elektronisk notatbok eller en oversetter fra nittitallet, læreren stiller et spørsmål, og elevene skriver inn svarene på tastaturene til enhetene, som mottas via en radiokanal (802.15.4) til en mottaker koblet til lærerens PC.
Disse enhetene ble avviklet for flere år siden, og det skoler kjøpte for $100-$200 hver dukker nå opp på eBay for $10 eller mindre. Maskinvaren der er veldig egnet for nerdete eksperimenter:
- 60-tasters tastatur
- skjerm med en oppløsning på 384×136, 2 biter per piksel - lik BC, CGA, men 4 ikke farger, men graderinger av lysstyrke
- mikrokontroller ATmega128RFA1 (128 kB flashminne, 4 kB ROM, 16 kB RAM, 802.15.4 transceiver)
- eksternt (i forhold til mikrokontrolleren, ikke hele enheten) 1 megabit (128 kilobyte) flashminne med SPI-grensesnitt
- rom for 4 AAA-elementer.
Fra navnet på mikrokontrolleren er det klart at den tilhører AVR-familien, noe som betyr å gjøre enheten Arduino-kompatibel er en mer enn triviell oppgave...
Fra nyhetene forfatteren fant ut hva det er (den samme lenken forteller deg hva du skal koble til hvor), har muligheten til å kjøre spill for Arduboy:
Men forfatteren er mer interessert i muligheten til ikke å spille på enheten, men å studere:
- flashminne med seriell SPI-grensesnitt
- bootloadere for AVR
- standard 802.15.4
Forfatteren begynte med å skrive (GPL v3), som lar deg initialisere skjermen, skrive ut tekst og rektangler og få tilgang til SPI-flashminne. Så begynte han å komme med ideer for praktisk bruk av enheten: en VT-100-kompatibel lommeterminal, flerspillerspill. Etter å ha gjenoppbygd tre enheter, bestemte han seg for å "lære" dem å motta skisser "over luften." Hva ville ikke bare være interessant, men også veldig praktisk: enhetsdekselet er vanskelig å åpne hver gang, og under batteriromdekselet er det bare hull som lar deg koble en JTAG-programmerer til brettet.
Dette er nok til å laste opp Arduino bootloader, men ikke skissen - serieporten er ikke koblet til der, så du kan fortsatt ikke gjøre uten å åpne dekselet. Dessuten er TX0- og RX0-linjene til den første serielle porten kombinert med pollinglinjene til tastaturmatrisen, nemlig de som poller funksjonstastene på sidene av skjermen. Men hva kan du gjøre - forfatteren bygde dette:
Han tok med JTAG-linjene dit, og nå er det ikke nødvendig å åpne batterirommet. Og for at skisser kunne lastes opp, koblet jeg begge serieportene til samme kontakt, og la også til en bryter, for med batteriene installert er det fysisk umulig å slå av enheten på noen annen måte.
Det tok ganske lang tid å jobbe med en loddebolt, en verktøykniv og en limpistol. Generelt er det mye mer praktisk å laste opp skisser "over luften", vi må snarest finne opp noe for dette.
Arduino IDE bruker programmet til å laste opp skisser . Den samhandler med mikrokontrolleren ved hjelp av protokollen , som lar deg overføre filer i begge retninger. Den er dårlig kompatibel med kanaler der variable forsinkelser, forvrengning og tap av data er mulig. Hvis noe løsner eller rasler i seriekanalen, kan du bli gal på jakt etter årsaken. En gang led forfatteren i en halv dag før han innså at problemet var en dårlig kabel, samt en lunefull CP2102-grensesnittomformer. Selv en mikrokontroller med en innebygd grensesnittomformer, for eksempel ATmega32u4, kan noen ganger fungere slik. Hver Arduino-bruker har lagt merke til at feil ved opplasting av skisser ikke er så sjeldne. Noen ganger går opptaket bra, men under en testavlesning oppdages en feil. Dette betyr ikke at det var en feil under skrivingen – det var en feil under lesingen. Tenk deg nå at når du jobber "over luften" vil det samme skje, men mye oftere.
Etter å ha prøvd forskjellige måter å overvinne dette problemet på, kom forfatteren opp med følgende. Enheten har et 128 KB flashminne med et SPI-grensesnitt - vi mottar data over ledningene (husk at forfatteren allerede har en enhet med en kontakt på siden), bruker dette minnet som buffer, og sender dataene over radioen kanal til en annen enhet. Hei fra Cybiko.
Etter å ha skrevet koden for å fungere med radiokanalen, så vel som fonten, ble lasteren lengre enn 4 kilobyte. Derfor måtte HFUSE-verdien endres fra 0xDA til 0xD8. Nå kan bootloaderen være opptil 8 kilobyte lang, og startadressen er nå 0x1E000. Dette gjenspeiles i Makefilen, men bør også tas i betraktning ved fylling via avrdude.
802.15.4-transceiveren i ATmega128RFA1 er opprinnelig designet for å operere ved hjelp av protokollen , som er ganske komplisert, så forfatteren bestemte seg for å bare overføre pakker i stedet. Dette er implementert i maskinvare i ATmega128RFA1, så lite kode kreves. For enkelhets skyld bestemte forfatteren seg for å bruke en fast kanal, som ikke tillater deg å velge den selv manuelt. 802.15.4-standarden støtter 16 kanaler med tall fra 11 til 26. De er ganske overfylte, noen overlapper også WiFi-kanaler (rødt er ZigBee-kanaler, blått, grønt og gult er WiFi).
Det viste seg at kanalene 15 og 26 er minst utsatt for forstyrrelser fra WiFi. Forfatteren valgte den andre av dem. Ansvarsfraskrivelse: oversetteren vet ikke om det er lov å forenkle ZigBee på denne måten. Kanskje vi skal programmere litt mer og implementere det helt?
På den første enheten er det nødvendig å implementere en endelig tilstandsmaskin som overfører data via STK500-protokollen. For det meste er meldingene som sendes og mottas selvforsynt, men noen er knyttet til de som har gått gjennom kanalen tidligere. Beskrivelse av dialogen er gitt .
En viktig komponent i denne dialogen er overføringen av pakker som skal skrives til flashminnet til destinasjonsenheten. For enkle mikrokontrollere av AVR-familien er sidestørrelsen 128 byte, men for ATmega128RFA1 er den 256. Og for flashminnet som er koblet til via SPI-protokollen er det det samme. Programmet i den første enheten, når du laster opp en skisse, overfører den ikke umiddelbart til den andre, men skriver den til dette minnet. Når Arduino IDE sjekker riktigheten av oppføringen, sendes det det som er skrevet der. Nå må vi overføre de mottatte dataene via radiokanal til den andre enheten. Samtidig skjer bytte fra mottak til sending og tilbake ganske ofte. STK500-protokollen er likegyldig til forsinkelser, men tolererer ikke tap av data (rart, men det ble sagt ovenfor at forsinkelser også påvirker dataoverføringen). Og tap under trådløs overføring er uunngåelig. ATmega128RFA1 har en innebygd maskinvareimplementering av gjentatte forespørsler når det er tvil om riktigheten av overføringen, men forfatteren bestemte seg for å implementere det samme i programvaren selv. Han utviklet en protokoll der mye mer data flyter den ene veien enn den andre.
Det er ikke perfekt, men det fungerer. Siden på 256 byte er delt inn i fire segmenter, som hver sendes over luften som en pakke. En pakke kan inneholde opptil 125 byte med data pluss en byte for lengde og to byte for CRC. Så fragmenter 64 byte lange sammen med side- og segmentnummer (fra 0 til 3) plasseres der. Mottaksenheten har en variabel som lar den spore hvor mange segmenter som er mottatt, og når alle fire ankommer, mottar avsenderenheten bekreftelse på at hele siden er mottatt. Ingen bekreftelse (CRC stemte ikke) - send hele siden på nytt. Hastigheten er enda høyere enn ved overføring via kabel. Se:
Men generelt vil det være nødvendig å gi en praktisk måte å koble kabelen til enhetene for å laste opp skisser og gjennom den. Plasser for eksempel inne i en slik grensesnittkonverter på CP2102, som på bildet, og lim den til brettet slik at den tåler kraften når du kobler til og fra Micro USB-kabelen.
Den har også en 3,3-volts stabilisator (og hvordan du bruker den i en enhet med en 6-volts strømforsyning - hvis bare den har samme stabilisator, og du kan legge til to dioder for å automatisk velge hvilken av dem som skal drive enheten) . Alle tre lysdiodene må være uloddet fra grensesnittomformerkortet, ellers vil de i tillegg belaste batteriene når de opererer på dem, og også forstyrre tastaturpolling og arbeide med flashminne med et SPI-grensesnitt.
Å forfølge et mål viste seg å være enda mer interessant enn å oppnå det (og trenger ikke den vitsen om bussen). Forfatteren lærte mye om AVR-bootloadere, SPI-flashminne, STK500-protokollen og 802.15.4-standarden.
All annen kode i tillegg til biblioteket beskrevet ovenfor er − , og det er også under GPL v3. Forfatterens Twitter - .
Kilde: www.habr.com