Tot va començar amb la compra de l'autor d'un dispositiu interessant al mercat secundari: Smart Response XE (). Està pensat per a centres educatius: cada alumne de la classe rep un dispositiu semblant a un quadern electrònic o un traductor dels anys noranta, el professor fa una pregunta, i els alumnes escriuen les respostes als teclats dels aparells, que es reben mitjançant un canal de ràdio (802.15.4) a un receptor connectat a l'ordinador del professor.
Aquests dispositius es van deixar de fabricar fa uns quants anys, i el que les escoles van comprar per 100-200 dòlars cadascuna apareixen ara a eBay per 10 dòlars o menys. El maquinari que hi ha és molt adequat per a experiments geek:
- Teclat de 60 tecles
- pantalla amb una resolució de 384 × 136, 2 bits per píxel - similar a BC, CGA, però 4 no colors, sinó gradacions de brillantor
- microcontrolador ATmega128RFA1 (128 kB de memòria flaix, 4 kB de ROM, 16 kB de RAM, transceptor 802.15.4)
- externa (en relació amb el microcontrolador, no amb tot el dispositiu) memòria flash d'1 megabit (128 kilobytes) amb interfície SPI
- compartiment per a 4 elements AAA.
Pel nom del microcontrolador es desprèn que pertany a la família AVR, la qual cosa significa fer que el dispositiu sigui compatible amb Arduino és una tasca més que trivial...
A partir de la notícia l'autor va descobrir què és (el mateix enllaç us indica què heu de connectar on), tenint l'oportunitat d'executar jocs per a Arduboy:
Però l'autor està més interessat en l'oportunitat de no jugar al dispositiu, sinó estudiar:
- memòria flash amb interfície SPI sèrie
- carregadors d'arrencada per a AVR
- estàndard 802.15.4
L'autor va començar escrivint (GPL v3), que us permet inicialitzar la pantalla, sortir text i rectangles i accedir a la memòria flash SPI. Llavors va començar a plantejar idees per a l'ús pràctic del dispositiu: un terminal de butxaca compatible amb VT-100, jocs multijugador. Després d'haver reconstruït tres aparells, va decidir "ensenyar-los" a rebre esbossos "per l'aire". El que seria no només interessant, sinó també molt còmode: la caixa del dispositiu és difícil d'obrir cada cop i sota la coberta del compartiment de la bateria només hi ha forats que permeten connectar un programador JTAG a la placa.
Això és suficient per carregar el carregador d'arrencada Arduino, però no l'esbós: el port sèrie no hi està connectat, de manera que encara no podeu prescindir d'obrir la caixa. A més, les línies TX0 i RX0 del primer port sèrie es combinen amb les línies de sondeig de la matriu del teclat, és a dir, les que sondegen les tecles de funció als laterals de la pantalla. Però què pots fer? L'autor va construir això:
Va portar allà les línies JTAG i ara no cal obrir el compartiment de la bateria. I perquè es poguessin pujar esbossos, vaig connectar els dos ports sèrie al mateix connector, afegint també un interruptor, perquè amb les bateries instal·lades és físicament impossible apagar el dispositiu d'una altra manera.
Va trigar força temps a treballar amb un soldador, un ganivet i una pistola de cola. En general, penjar esbossos "a l'aire" és molt més convenient; hem d'inventar alguna cosa urgentment per a això.
Arduino IDE utilitza el programa per carregar esbossos . Interacciona amb el microcontrolador mitjançant el protocol , que permet transferir fitxers en ambdues direccions. És poc compatible amb canals on són possibles retards variables, distorsió i pèrdua de dades. Si alguna cosa es desfà o ruixada al canal sèrie, pots tornar-te boig buscant la causa. Una vegada l'autor va patir mig dia fins que es va adonar que el problema era un cable dolent, així com un convertidor d'interfície CP2102 capritxós. Fins i tot un microcontrolador amb un convertidor d'interfície integrat, per exemple, ATmega32u4, de vegades pot actuar així. Tots els usuaris d'Arduino s'han adonat que els errors en penjar esbossos no són tan rars. De vegades l'enregistrament va bé, però durant una lectura de prova es detecta un error. Això no vol dir que hi hagi hagut un error durant l'escriptura: hi ha hagut un error durant la lectura. Ara imagineu-vos que quan treballeu "a l'aire" passarà el mateix, però molt més sovint.
Després de provar diferents maneres de superar aquest problema, l'autor va plantejar el següent. El dispositiu té una memòria flaix de 128 KB amb una interfície SPI: rebem dades pels cables (recordeu que l'autor ja té un dispositiu amb un connector al costat), utilitzeu aquesta memòria com a memòria intermèdia i enviem les dades per la ràdio. canal a un altre dispositiu. Hola de Cybiko.
Després d'escriure el codi per treballar amb el canal de ràdio, així com el tipus de lletra, el carregador va fer més de 4 kilobytes. Per tant, el valor HFUSE es va haver de canviar de 0xDA a 0xD8. Ara el carregador d'arrencada pot tenir una longitud de fins a 8 kilobytes i l'adreça inicial és ara 0x1E000. Això es reflecteix al Makefile, però també s'ha de tenir en compte a l'hora d'omplir via avrdude.
El transceptor 802.15.4 de l'ATmega128RFA1 està dissenyat originalment per funcionar mitjançant el protocol , que és bastant complicat, així que l'autor va decidir transmetre paquets. Això s'implementa al maquinari de l'ATmega128RFA1, de manera que es requereix poc codi. A més, per simplificar, l'autor va decidir utilitzar un canal fix, que no permetia seleccionar-lo ni tan sols manualment. L'estàndard 802.15.4 admet 16 canals amb números de l'11 al 26. Són força concorreguts, alguns també se superposen amb canals WiFi (el vermell són els canals ZigBee, el blau, el verd i el groc són WiFi).
Va resultar que els canals 15 i 26 són els menys susceptibles a les interferències de WiFi.L'autor va triar el segon d'ells. Exempció de responsabilitat: el traductor no sap si està permès simplificar ZigBee d'aquesta manera. Potser hauríem de fer una mica més de programació i implementar-la completament?
En el primer dispositiu, cal implementar una màquina d'estats finits que transmeti dades mitjançant el protocol STK500. En la seva majoria, els missatges transmesos i rebuts són autosuficients, però alguns estan lligats als que van passar pel canal abans. Es dóna una descripció del diàleg .
Un component important d'aquest diàleg és la transmissió de paquets destinats a ser escrits a la memòria flaix del dispositiu de destinació. Per als microcontroladors simples de la família AVR, la mida de la pàgina és de 128 bytes, però per a l'ATmega128RFA1 és de 256. I per a la memòria flash que està connectada mitjançant el protocol SPI, és el mateix. El programa del primer dispositiu, quan es carrega un esbós, no el transfereix immediatament al segon, sinó que l'escriu a aquesta memòria. Quan l'IDE d'Arduino comprova la correcció de l'entrada, s'envia el que hi havia escrit. Ara hem de transmetre les dades rebudes per canal de ràdio al segon dispositiu. Al mateix temps, el canvi de la recepció a la transmissió i la tornada es produeix amb força freqüència. El protocol STK500 és indiferent als retards, però no tolera la pèrdua de dades (estrany, però anteriorment es va dir que els retards també afecten la transferència de dades). I les pèrdues durant la transmissió sense fil són inevitables. L'ATmega128RFA1 té una implementació de maquinari integrada de sol·licituds repetides quan hi ha dubtes sobre la correcció de la transferència, però l'autor va decidir implementar el mateix al programari. Va desenvolupar un protocol en el qual flueixen moltes més dades d'una manera que de l'altra.
No és perfecte, però funciona. La pàgina de 256 bytes es divideix en quatre segments, cadascun dels quals es transmet per aire com un paquet. Un paquet pot contenir fins a 125 bytes de dades més un byte de longitud i dos bytes de CRC. Així, s'hi col·loquen fragments de 64 bytes de longitud juntament amb números de pàgina i segment (de 0 a 3). El dispositiu receptor té una variable que li permet fer un seguiment de quants segments s'han rebut, i quan arriben els quatre, el dispositiu emissor rep la confirmació que s'ha rebut tota la pàgina. Sense confirmació (CRC no coincideix) - torna a enviar la pàgina sencera. La velocitat és encara més gran que quan es transmet per cable. Veure:
Però, en general, caldria proporcionar una manera còmoda de connectar el cable als dispositius per carregar esbossos i a través d'ell. Per exemple, col·loqueu-lo dins d'aquest convertidor d'interfície al CP2102, com a la foto, i enganxeu-lo a la placa perquè pugui suportar la força quan connecteu i desconnecteu el cable Micro USB.
També té un estabilitzador de 3,3 volts (i com utilitzar-lo en un dispositiu amb una font d'alimentació de 6 volts, si només té el mateix estabilitzador, i podeu afegir dos díodes per seleccionar automàticament quin d'ells alimentarà el dispositiu) . Els tres LED s'han de dessoldar de la placa del convertidor d'interfície, en cas contrari, carregaran les bateries quan funcionin amb ells, i també interferiran amb l'enquesta del teclat i funcionen amb la memòria flaix amb una interfície SPI.
Perseguir un objectiu va resultar encara més interessant que aconseguir-lo (i no cal aquesta broma sobre l'autobús). L'autor va aprendre molt sobre els carregadors d'arrencada AVR, la memòria flash SPI, el protocol STK500 i l'estàndard 802.15.4.
Tots els altres codis, a més de la biblioteca descrita anteriorment, són - , i també està sota GPL v3. Twitter de l'autor - .
Font: www.habr.com