Det hele begyndte med, at forfatteren købte en interessant enhed på det sekundære marked — Smart Response XE (). Den er beregnet til skoler: hver elev i klassen får en enhed, der ligner en elektronisk notesblok eller en oversætter fra 90'erne, læreren stiller et spørgsmål, og eleverne indtaster svarene på enhedernes tastaturer, som sendes via radiokanal (802.15.4) til en modtager tilsluttet lærerens computer.
Understøttelsen af disse enheder blev stoppet for flere år siden, og det, som skolerne købte for 100-200 dollars hver, dukker nu op på eBay for 10 eller mindre. "Hardwaren" er meget velegnet til nørdede eksperimenter:
- et tastatur med 60 taster
- en skærm med en opløsning på 384×136, 2 bits per pixel — svarende til BK, CGA, men 4 ikke farver, men lysstyrkeskalaer
- mikrocontroller ATmega128RFA1 (128 kB flash-hukommelse, 4 kB SRAM, 16 kB RAM, transceiver af standard 802.15.4)
- ekstern (i forhold til mikrocontrolleren, ikke hele enheden) flash-hukommelse på 1 megabit (128 kilobyte) med SPI-interface
- et rum til 4 AAA-batterier.
Af navnet på mikrocontrolleren kan man forstå, at den tilhører AVR-familien, og derfor er det mere end trivielt at gøre enheden Arduino-kompatibel...
Fra nyheden på fandt forfatteren ud af, at dette (denne link beskriver også, hvor man skal tilslutte det), hvilket giver mulighed for at køre spil til Arduboy:
Men forfatteren er mere interesseret i muligheden for ikke at spille på enheden, men at undersøge:
- flash-hukommelse med seriøst SPI-interface
- bootloadere til AVR
- standard 802.15.4
Forfatteren begyndte med at skrive (GPL v3), der gør det muligt at initialisere skærmen, udskrive tekst og rektangler samt få adgang til flash-hukommelsen med SPI-interface. Derefter begyndte han at finde på idéer til praktisk brug af enheden: en lomme VT-100-kompatibel terminal, multiplayer-spil. Efter at have modificeret tre enheder besluttede han at "undervise" dem i at modtage sketches "over luften". Det ville ikke kun være interessant, men også meget bekvemt: det er besværligt at åbne enhedens kabinet hver gang, og under dækslet til batterirummet er der kun huller, der tillader tilslutning af et JTAG-programmør til printkortet.
Dette er nok til at uploade Arduino bootloaderen, men ikke sketch’en — den serielle port er ikke udskrevet, så uden at åbne kassen kan man ikke komme uden om det. Desuden er TX0- og RX0-linjerne fra den første serielle port sammenkoblet med linjerne til matrixen af tastaturet, nemlig dem, der bruges til at spørge funktionstasterne på siderne af skærmen. Men hvad skal man gøre — forfatteren har lavet følgende:
Derudaf har han ført JTAG-linjerne, og nu er det ikke nødvendigt at åbne batterirummet. For at kunne uploade sketches, førte han også begge serielle porte til denne stikforbindelse og tilføjede også en kontakt, fordi det er fysisk umuligt at slukke enheden på anden måde, når batterierne er installeret.
Det tog ret lang tid at arbejde med loddekolben, hobbykniven og limpistolen. Generelt er det meget lettere at uploade sketches trådløst, så man bør hurtigt finde på noget.
Arduino IDE bruger programmet til at uploade sketches . Det interagerer med mikrokontrolleren via protokollen , som muliggør filoverførsel i begge retninger. Den er dårligt kompatibel med kanaler, hvor der kan opstå variable forsinkelser, forvrængninger og datatab. Hvis der er noget, der knirker eller skurrer i den serielle kanal, kan man blive sindssyg over at forsøge at finde årsagen. En gang brugte forfatteren et halvdags arbejde, inden han indså, at det var et dårligt kabel samt den følsomme interfaceconverter CP2102. Selv mikrokontrollere med indbygget interfaceconverter, såsom ATmega32u4, kan sommetider også opføre sig underligt. Hver Arduino-bruger har bemærket, at fejl under upload af sketches ikke er så sjældne. Nogle gange går optagelsen fint, og ved den efterfølgende læsning opdages der en fejl. Det betyder ikke, at der var en fejl under optagelsen — fejlen opstod under læsningen. Og nu forestil dig, at det samme vil ske under trådløs drift, men meget oftere.
Efter at have prøvet forskellige måder at overvinde dette problem på, kom forfatteren på følgende idé. Enheden har 128 kilobyte flash-hukommelse med SPI-interface — vi modtager data via kabler (vi husker, at forfatteren allerede har en enhed med en stikforbindelse på siden), bruger denne hukommelse som buffer, og sender data via radiokanalen til en anden enhed. En hilsen fra Cybiko.
Efter at have skrevet koden til at arbejde med radiokanalen samt skrifttypen er bootloaderen blevet længere end 4 kilobyte. Derfor måtte værdien for HFUSE ændres fra 0xDA til 0xD8. Nu kan bootloaderen være op til 8 kilobyte lang, og startadressen er blevet 0x1E000. Dette er reflekteret i Makefile, men skal også tages i betragtning, når den uploades. ved hjælp af avrdude.
Modtageren og senderen af standarden 802.15.4 i ATmega128RFA1 var oprindeligt designet til at arbejde med protokollen , som er ret kompleks, derfor besluttede forfatteren at sende pakkerne i stedet. Dette er implementeret hardwaremæssigt i ATmega128RFA1, så der kræves kun lidt kode. Desuden besluttede forfatteren for enkelhedens skyld at bruge en fast kanal, uden mulighed for manuel valg. Standarden 802.15.4 understøtter 16 kanaler med numre fra 11 til 26. De er ret overfyldte, nogle overlapper også med WiFi-kanaler (kanaler ZigBee er markeret med rødt, WiFi med blåt, grønt og gult).
Det viste sig, at kanalerne 15 og 26 er de mindst udsatte for WiFi-forstyrrelser. Den anden valgte forfatteren. Fraskrivelse: oversætteren ved ikke, om det er tilladt at forenkle ZigBee sådan. Måske burde man programmere lidt mere og implementere det fuldt ud?
På den første enhed skal der implementeres en automat, der sender data via STK500-protokollen. De fleste af de sendte og modtagne beskeder er selvforsynende, men nogle er knyttet til tidligere beskeder sendt over kanalen. Beskrivelsen af dialogen er givet. .
En vigtig del af denne dialog er overførslen af pakker, der er beregnet til at blive skrevet til flashhukommelsen i destinationsenheden. For simple mikrocontrollere i AVR-familien er sidestørrelsen 128 byte, men for ATmega128RFA1 er den 256. Og for den flashhukommelse, der tilsluttes via SPI-protokollen, er den den samme. Programmet i den første enhed sender ikke straks sketchen til den anden, men skriver det til denne hukommelse. Når Arduino IDE verificerer korrektheden af skrivningen, sendes det, der er blevet skrevet, tilbage. Nu skal de modtagne data overføres til den anden enhed via radiokanal. Her sker skiftet fra modtagelse til overførsel og tilbage ret ofte. STK500-protokollen er ligeglad med forsinkelser, men tolererer ikke datatab (mærkeligt, men der er nævnt, at forsinkelser i datatransmission også påvirker det). Og tab ved trådløs overførsel er uundgåeligt. ATmega128RFA1 har en hardwareimplementering af genanmodninger ved tvivl om korrektheden af overførslen, men forfatteren besluttede at implementere det samme programmæssigt selv. Han udviklede en protokol, hvor der sendes langt flere data i den ene retning end i den anden.
Den er ikke perfekt, men alt fungerer. Den 256-byte side opdeles i fire segmenter, som hver overføres via radiokanal i form af pakker. En pakke kan indeholde op til 125 byte data plus én byte - længde og to - CRC. Så fragmenter af 64 byte sammen med sidernes og segmenternes numre (fra 0 til 3) bliver sendt. I modtagerenheden er der en variabel, der gør det muligt at spore, hvor mange segmenter der er blevet modtaget, og når alle fire ankommer, sends der en bekræftelse til den afsendende enhed om, at hele siden er modtaget. Ingen bekræftelse (CRC stemmer ikke overens) - vi sender hele siden igen. Hastigheden viser sig at være endnu højere end ved overførsel via kabel. Se:
Men i virkeligheden bør der overvejes en bekvem måde at tilslutte kabler til enhederne til upload af sketches. For eksempel ved at placere en sådan interface-konverter som CP2102 indeni, som på billedet, og klæbe den til printpladen, så den kan tåle belastningen ved tilslutning og frakobling af Micro USB-kablet.
Der er også en 3,3-volts regulator i den (og hvordan man bruger den i en enhed med 6-volts strømforsyning — hvis der i så fald er en tilsvarende regulator, kan man tilføje to dioder for automatisk at vælge, hvilken enhed der skal forsynes). Alle tre lysdioder skal fjernes fra interface-kortet, ellers vil de belaste batterierne yderligere, når de arbejder fra dem, samt forstyrre tastaturets polling og arbejdet med flash-hukommelsen med SPI-interface.
Jagten på målet viste sig at være mere interessant end at nå det (og lad være med den vittighed om bussen). Forfatteren lærte meget om bootloadere til AVR, flash-hukommelse med SPI-interface, STK500-protokollen og 802.15.4-standarten.
Hele den øvrige kode samt den ovenfor beskrevne biblioteksdel — , og den er også under GPL v3. Forfatterens Twitter — .
Kilde: habr.com
