Todo comezou coa compra do autor dun dispositivo interesante no mercado secundario: Smart Response XE (). Está pensado para centros educativos: cada alumno da clase recibe un dispositivo semellante a un caderno electrónico ou un tradutor dos anos noventa, o profesor fai unha pregunta, e os alumnos teclean as respostas nos teclados dos dispositivos, que se reciben a través dun canle de radio (802.15.4) a un receptor conectado ao ordenador do profesor.
Estes dispositivos foron descontinuados hai varios anos, e o que as escolas compraron por $ 100- $ 200 cada unha aparece agora en eBay por $ 10 ou menos. O hardware alí é moi axeitado para experimentos geek:
- Teclado de 60 teclas
- pantalla cunha resolución de 384 × 136, 2 bits por píxel - similar a BC, CGA, pero 4 non cores, senón gradacións de brillo
- microcontrolador ATmega128RFA1 (128 kB de memoria flash, 4 kB de ROM, 16 kB de RAM, transceptor 802.15.4)
- externa (en relación ao microcontrolador, non ao dispositivo completo) memoria flash de 1 megabit (128 kilobytes) con interface SPI
- compartimento para 4 elementos AAA.
Polo nome do microcontrolador despréndese que pertence á familia AVR, o que significa que facer que o dispositivo sexa compatible con Arduino é unha tarefa máis que trivial...
A partir das noticias o autor descubriu o que é (a mesma ligazón indica que conectar onde), tendo a oportunidade de executar xogos para Arduboy:
Pero o autor está máis interesado na oportunidade de non xogar no dispositivo, senón de estudar:
- memoria flash con interface serial SPI
- cargadores de arranque para AVR
- norma 802.15.4
O autor comezou escribindo (GPL v3), que lle permite inicializar a pantalla, emitir texto e rectángulos e acceder á memoria flash SPI. Entón comezou a ter ideas para o uso práctico do dispositivo: un terminal de peto compatible con VT-100, xogos multixogador. Despois de reconstruír tres dispositivos, decidiu "ensinarlles" a recibir bosquexos "polo aire". O que non só sería interesante, senón tamén moi cómodo: a carcasa do dispositivo é difícil de abrir cada vez e debaixo da tapa do compartimento da batería só hai orificios que permiten conectar un programador JTAG á placa.
Isto é suficiente para cargar o cargador de arranque de Arduino, pero non o bosquexo: o porto serie non está conectado alí, polo que aínda non podes prescindir de abrir o caso. Ademais, as liñas TX0 e RX0 do primeiro porto serie combínanse coas liñas de sondeo da matriz do teclado, é dicir, aquelas que consultan as teclas de función dos lados da pantalla. Pero que podes facer: o autor construíu isto:
Trouxo alí as liñas JTAG e agora non hai que abrir o compartimento da batería. E para que se puidesen subir bocetos, conectei os dous portos serie ao mesmo conector, engadindo tamén un interruptor, xa que coas baterías instaladas é fisicamente imposible apagar o dispositivo doutro xeito.
Levou bastante tempo traballar cun soldador, unha navalla e unha pistola de pegamento. En xeral, cargar bosquexos "polo aire" é moito máis conveniente; necesitamos urxentemente inventar algo para iso.
Arduino IDE usa o programa para cargar bosquexos . Interactúa co microcontrolador mediante o protocolo , que permite transferir ficheiros en ambas direccións. É pouco compatible con canles onde son posibles atrasos variables, distorsión e perda de datos. Se algo se solta ou hurga na canle en serie, podes volver tolo buscando a causa. Unha vez o autor sufriu durante medio día ata que se decatou de que o problema era un cable malo, así como un caprichoso conversor de interface CP2102. Incluso un microcontrolador cun conversor de interface incorporado, por exemplo, ATmega32u4, ás veces pode actuar así. Todos os usuarios de Arduino decatáronse de que os erros ao cargar esbozos non son tan raros. Ás veces a gravación vai ben, pero durante unha lectura de proba detéctase un erro. Isto non significa que houbo un erro durante a escritura - houbo un fallo durante a lectura. Agora imaxina que ao traballar "ao aire" pasará o mesmo, pero con moita máis frecuencia.
Despois de probar diferentes formas de superar este problema, o autor presentou o seguinte. O dispositivo ten unha memoria flash de 128 KB cunha interface SPI: recibimos datos polos cables (lembre que o autor xa ten un dispositivo cun conector lateral), usa esta memoria como búfer e enviamos os datos pola radio. canle a outro dispositivo. Saúdos de Cybiko.
Despois de escribir o código para traballar coa canle de radio, así como o tipo de letra, o cargador pasou a ter máis de 4 kilobytes. Polo tanto, o valor HFUSE tivo que cambiarse de 0xDA a 0xD8. Agora o cargador de arranque pode ter ata 8 kilobytes de lonxitude e o enderezo de inicio agora é 0x1E000. Isto reflíctese no Makefile, pero tamén se debe telo en conta ao encher vía avrdude.
O transceptor 802.15.4 do ATmega128RFA1 foi deseñado orixinalmente para funcionar mediante o protocolo , que é bastante complicado, polo que o autor decidiu só transmitir paquetes. Isto está implementado no hardware do ATmega128RFA1, polo que se require pouco código. Ademais, para simplificar, o autor decidiu utilizar unha canle fixa, non permitindo seleccionala nin sequera manualmente. O estándar 802.15.4 admite 16 canles con números do 11 ao 26. Están bastante cheas, algunhas tamén se solapan con canles WiFi (o vermello son canles ZigBee, o azul, o verde e o amarelo son as WiFi).
Resultou que as canles 15 e 26 son as menos susceptibles a interferencias da WiFi.O autor escolleu a segunda delas. Descargo de responsabilidade: o tradutor non sabe se está permitido simplificar ZigBee deste xeito. Quizais deberíamos facer un pouco máis de programación e implementala completamente?
No primeiro dispositivo, é necesario implementar unha máquina de estados finitos que transmita datos a través do protocolo STK500. Na súa maior parte, as mensaxes transmitidas e recibidas son autosuficientes, pero algunhas están vinculadas ás que pasaron pola canle antes. Ofrécese descrición do diálogo .
Un compoñente importante deste diálogo é a transmisión de paquetes destinados a ser escritos na memoria flash do dispositivo de destino. Para microcontroladores simples da familia AVR, o tamaño da páxina é de 128 bytes, pero para o ATmega128RFA1 é de 256. E para a memoria flash que está conectada a través do protocolo SPI, é o mesmo. O programa do primeiro dispositivo, ao cargar un bosquexo, non o transfire inmediatamente ao segundo, senón que o escribe nesta memoria. Cando o IDE de Arduino comproba a corrección da entrada, envíaselle o que alí estaba escrito. Agora necesitamos transmitir os datos recibidos a través da canle de radio ao segundo dispositivo. Ao mesmo tempo, o cambio de recepción a transmisión e de volta ocorre con bastante frecuencia. O protocolo STK500 é indiferente aos atrasos, pero non tolera a perda de datos (estraño, pero dicíase anteriormente que os atrasos tamén afectan á transferencia de datos). E as perdas durante a transmisión sen fíos son inevitables. O ATmega128RFA1 ten unha implementación de hardware incorporada de solicitudes repetidas cando hai dúbidas sobre a corrección da transferencia, pero o autor decidiu implementar o mesmo no software. Desenvolveu un protocolo no que flúen moito máis datos dun xeito que doutro.
Non é perfecto, pero funciona. A páxina de 256 bytes está dividida en catro segmentos, cada un dos cales se transmite polo aire como un paquete. Un paquete pode conter ata 125 bytes de datos máis un byte de lonxitude e dous bytes de CRC. Polo tanto, colócanse alí fragmentos de 64 bytes xunto cos números de páxina e segmento (de 0 a 3). O dispositivo receptor ten unha variable que lle permite rastrexar cantos segmentos se recibiron e, cando chegan os catro, o dispositivo emisor recibe a confirmación de que se recibiu toda a páxina. Sen confirmación (CRC non coincide) - reenvíe a páxina enteira. A velocidade é aínda maior que cando se transmite por cable. Ver:
Pero, en xeral, sería necesario proporcionar un xeito cómodo de conectar o cable aos dispositivos para cargar bosquexos e a través del. Por exemplo, colócase dentro dun conversor de interface deste tipo no CP2102, como na foto, e pégueo ao taboleiro para que poida soportar a forza ao conectar e desconectar o cable Micro USB.
Tamén ten un estabilizador de 3,3 voltios (e como usalo nun dispositivo cunha fonte de alimentación de 6 voltios - se só ten o mesmo estabilizador, e pode engadir dous díodos para seleccionar automaticamente cal deles alimentará o dispositivo) . Os tres LED deben estar dessoldados da tarxeta do conversor da interface, se non, cargarán adicionalmente as baterías ao operar neles, e tamén interferirán coa consulta do teclado e funcionarán coa memoria flash cunha interface SPI.
Perseguir un obxectivo resultou aínda máis interesante que conseguilo (e non fai falta esa broma sobre o autobús). O autor aprendeu moito sobre os cargadores de arranque AVR, a memoria flash SPI, o protocolo STK500 e o estándar 802.15.4.
Todo o outro código ademais da biblioteca descrita anteriormente é − , e tamén está baixo GPL v3. Twitter do autor - .
Fonte: www.habr.com