Det hele startede med, at forfatteren købte en interessant enhed på det sekundære marked - Smart Response XE (). Det er beregnet til skoler: hver elev i klassen modtager en enhed, der ligner en elektronisk notesbog eller en oversætter fra halvfemserne, læreren stiller et spørgsmål, og eleverne skriver svarene på enhedernes tastaturer, som modtages via en radiokanal (802.15.4) til en modtager tilsluttet lærerens pc.
Disse enheder blev udgået for flere år siden, og hvad skoler købte for $100-$200 hver, dukker nu op på eBay for $10 eller mindre. Hardwaren der er meget velegnet til nørdede eksperimenter:
- 60 taster tastatur
- skærm med en opløsning på 384×136, 2 bits pr. pixel - svarende til BC, CGA, men 4 ikke farver, men graduer af lysstyrke
- mikrocontroller ATmega128RFA1 (128 kB flashhukommelse, 4 kB ROM, 16 kB RAM, 802.15.4 transceiver)
- ekstern (i forhold til mikrocontrolleren, ikke hele enheden) 1 megabit (128 kilobyte) flashhukommelse med SPI-interface
- rum til 4 AAA-elementer.
Fra navnet på mikrocontrolleren er det tydeligt, at den tilhører AVR-familien, hvilket betyder at gøre enheden Arduino-kompatibel er en mere end triviel opgave...
Fra nyhederne forfatteren fandt ud af, hvad det er (det samme link fortæller dig, hvad du skal forbinde hvor), har mulighed for at køre spil til Arduboy:
Men forfatteren er mere interesseret i muligheden for ikke at spille på enheden, men at studere:
- flashhukommelse med seriel SPI-interface
- bootloadere til AVR
- 802.15.4 standard
Forfatteren begyndte med at skrive (GPL v3), som giver dig mulighed for at initialisere skærmen, udskrive tekst og rektangler og få adgang til SPI-flashhukommelse. Så begyndte han at komme med ideer til praktisk brug af enheden: en VT-100-kompatibel lommeterminal, multiplayer-spil. Efter at have genopbygget tre enheder besluttede han at "lære" dem at modtage skitser "over the air." Hvad ville ikke kun være interessant, men også meget praktisk: enhedshuset er svært at åbne hver gang, og under batterirummets dæksel er der kun huller, der giver dig mulighed for at tilslutte en JTAG-programmør til kortet.
Dette er nok til at uploade Arduino bootloaderen, men ikke skitsen - den serielle port er ikke tilsluttet der, så du kan stadig ikke undvære at åbne kabinettet. Desuden er TX0- og RX0-linjerne på den første serielle port kombineret med polling-linjerne på tastaturmatricen, nemlig dem, der poller funktionstasterne på siderne af skærmen. Men hvad kan du gøre - forfatteren byggede dette:
Han bragte JTAG-linjerne dertil, og nu er der ingen grund til at åbne batterirummet. Og for at skitser kunne uploades, koblede jeg begge serielle porte til det samme stik og tilføjede også en switch, for med batterierne installeret er det fysisk umuligt at slukke for enheden på anden måde.
Det tog ret lang tid at arbejde med en loddekolbe, en værktøjskniv og en limpistol. Generelt er det meget mere bekvemt at uploade skitser "over the air"; vi har et presserende behov for at opfinde noget til dette.
Arduino IDE bruger programmet til at uploade skitser . Den interagerer med mikrocontrolleren ved hjælp af protokollen , som giver dig mulighed for at overføre filer i begge retninger. Den er dårligt kompatibel med kanaler, hvor variable forsinkelser, forvrængning og datatab er mulige. Hvis noget løsner sig eller rasler i seriekanalen, kan du gå amok og lede efter årsagen. Engang led forfatteren i en halv dag, indtil han indså, at problemet var et dårligt kabel, såvel som en lunefuld CP2102-interfacekonverter. Selv en mikrocontroller med en indbygget interface-konverter, for eksempel ATmega32u4, kan nogle gange opføre sig sådan. Hver Arduino-bruger har bemærket, at fejl ved upload af skitser ikke er så sjældne. Nogle gange går optagelsen godt, men under en testaflæsning opdages der en fejl. Det betyder ikke, at der var en fejl under skrivningen - der var en fejl under læsningen. Forestil dig nu, at når du arbejder "over the air", vil det samme ske, men meget oftere.
Efter at have prøvet forskellige måder at overvinde dette problem på, kom forfatteren frem til følgende. Enheden har en 128 KB flash-hukommelse med et SPI-interface - vi modtager data over ledningerne (husk at forfatteren allerede har en enhed med et stik på siden), bruger denne hukommelse som buffer og sender dataene over radioen kanal til en anden enhed. Hej fra Cybiko.
Efter at have skrevet koden til at arbejde med radiokanalen, såvel som skrifttypen, blev loaderen længere end 4 kilobyte. Derfor skulle HFUSE-værdien ændres fra 0xDA til 0xD8. Nu kan bootloaderen være op til 8 kilobyte lang, og startadressen er nu 0x1E000. Dette afspejles i Makefilen, men bør også tages i betragtning ved udfyldning via avrdude.
802.15.4 transceiveren i ATmega128RFA1 er oprindeligt designet til at fungere ved hjælp af protokollen , hvilket er ret kompliceret, så forfatteren besluttede sig for bare at sende pakker i stedet for. Dette er implementeret i hardware i ATmega128RFA1, så lidt kode er påkrævet. For nemheds skyld besluttede forfatteren også at bruge en fast kanal, så du ikke selv kunne vælge den manuelt. 802.15.4-standarden understøtter 16 kanaler med tal fra 11 til 26. De er ret overfyldte, nogle overlapper også WiFi-kanaler (rød er ZigBee-kanaler, blå, grøn og gul er WiFi).
Det viste sig, at kanal 15 og 26 er mindst modtagelige for interferens fra WiFi. Forfatteren valgte den anden af dem. Ansvarsfraskrivelse: oversætteren ved ikke, om det er tilladt at forenkle ZigBee på denne måde. Måske skulle vi lave lidt mere programmering og implementere det fuldstændigt?
På den første enhed er det nødvendigt at implementere en finite state-maskine, der transmitterer data via STK500-protokollen. For det meste er de meddelelser, der sendes og modtages, selvforsynende, men nogle er knyttet til dem, der passerede gennem kanalen tidligere. Beskrivelse af dialogen gives .
En vigtig komponent i denne dialog er transmissionen af pakker beregnet til at blive skrevet til destinationsenhedens flashhukommelse. For simple mikrocontrollere af AVR-familien er sidestørrelsen 128 bytes, men for ATmega128RFA1 er den 256. Og for flashhukommelsen, der er tilsluttet via SPI-protokollen, er det det samme. Programmet i den første enhed, når du uploader en skitse, overfører den ikke umiddelbart til den anden, men skriver den til denne hukommelse. Når Arduino IDE kontrollerer indtastningens rigtighed, sendes den, hvad der er skrevet der. Nu skal vi overføre de modtagne data via radiokanal til den anden enhed. Samtidig sker skift fra at modtage til at sende og tilbage ret ofte. STK500-protokollen er ligeglad med forsinkelser, men tolererer ikke datatab (mærkeligt, men det blev sagt ovenfor, at forsinkelser også påvirker dataoverførslen). Og tab under trådløs transmission er uundgåelige. ATmega128RFA1 har en indbygget hardwareimplementering af gentagne anmodninger, når der er tvivl om rigtigheden af overførslen, men forfatteren besluttede at implementere det samme i software selv. Han udviklede en protokol, hvor meget mere data flyder den ene vej end den anden.
Det er ikke perfekt, men det virker. Siden på 256 byte er opdelt i fire segmenter, som hver transmitteres trådløst som en pakke. En pakke kan indeholde op til 125 bytes data plus en byte for længden og to bytes for CRC. Så fragmenter på 64 bytes sammen med side- og segmentnumre (fra 0 til 3) placeres der. Den modtagende enhed har en variabel, der gør det muligt at spore, hvor mange segmenter der er modtaget, og når alle fire ankommer, modtager den afsendende enhed en bekræftelse på, at hele siden er modtaget. Ingen bekræftelse (CRC matchede ikke) - send hele siden igen. Hastigheden er endnu større, end når man sender via kabel. Se:
Men generelt ville det være nødvendigt at give en bekvem måde at forbinde kablet til enhederne for at uploade skitser og gennem det. Placer f.eks. inde i sådan en interface-konverter på CP2102, som på billedet, og lim den til brættet, så den kan modstå kraften, når du tilslutter og frakobler Micro USB-kablet.
Den har også en 3,3-volts stabilisator (og hvordan du bruger den i en enhed med en 6-volts strømforsyning - hvis bare den har den samme stabilisator, og du kan tilføje to dioder for automatisk at vælge, hvilken af dem der skal drive enheden) . Alle tre LED'er skal være uloddet fra interface-konverterkortet, ellers vil de yderligere belaste batterierne, når de betjenes på dem, og også forstyrre tastaturpolling og arbejde med flashhukommelse med en SPI-grænseflade.
At forfølge et mål viste sig at være endnu mere interessant end at nå det (og behøver ikke den joke om bussen). Forfatteren lærte meget om AVR-bootloadere, SPI-flashhukommelse, STK500-protokollen og 802.15.4-standarden.
Al anden kode ud over biblioteket beskrevet ovenfor er − , og det er også under GPL v3. Forfatterens Twitter - .
Kilde: www.habr.com