Tudo começou com a compra, pelo autor, de um interessante dispositivo no mercado de usados — Smart Response XE (). Foi projetado para escolas: cada aluno na sala de aula recebe um dispositivo semelhante a um caderno eletrônico ou um tradutor dos anos 90, o professor faz uma pergunta e os alunos digitam suas respostas nos teclados dos dispositivos, que são transmitidas via rádio (802.15.4) para um receptor conectado ao PC do professor.
O suporte para esses dispositivos foi encerrado há vários anos, e o que as escolas compravam por 100-200 dólares cada, agora aparece no eBay por 10 dólares ou menos. O "hardware" é realmente muito adequado para experiências de entusiastas:
- teclado de 60 teclas
- tela com resolução de 384×136, 2 bits por pixel — semelhante ao BK, CGA, mas 4 não cores, e sim gradações de brilho
- microcontrolador ATmega128RFA1 (128 kB de memória flash, 4 kB de EEPROM, 16 kB de RAM, transceptor padrão 802.15.4)
- memória flash externa (em relação ao microcontrolador, e não ao dispositivo inteiro) de 1 megabit (128 kilobytes) com interface SPI
- compartimento para 4 pilhas AAA.
Pelo nome do microcontrolador, é evidente que ele pertence à família AVR, e portanto, tornar o dispositivo compatível com Arduino é uma tarefa mais do que trivial...
Da notícia em o autor descobriu que isso (na mesma ligação é explicado onde conectar), permitindo executar jogos para Arduboy:
Mas o que o autor mais interessa é a possibilidade de não apenas jogar no dispositivo, mas estudar:
- memória flash com interface serial SPI
- carregadores para AVR
- padrão 802.15.4
O autor começou escrevendo (GPL v3), que permite inicializar a tela, exibir texto e retângulos, bem como acessar a memória flash com interface SPI. Em seguida, ele começou a pensar em ideias práticas de uso do dispositivo: terminal portátil compatível com VT-100, jogos multijogador. Depois de modificar três dispositivos, decidiu "ensinar" eles a receber sketches "sem fio". O que seria não apenas interessante, mas também muito conveniente: abrir o corpo do dispositivo a cada vez é difícil, e sob a tampa do compartimento da bateria só existem orifícios que permitem conectar um programador JTAG à placa.
Isso é suficiente para gravar o bootloader do Arduino, mas não o sketch — a porta serial não está disponível, portanto, não tem como evitar a abertura do corpo. Além disso, as linhas TX0 e RX0 da primeira porta serial estão combinadas com as linhas de leitura da matriz do teclado, ou seja, aquelas que fazem a leitura das teclas funcionais ao lado do display. Mas o que fazer — o autor fez o seguinte:
Ele conectou as linhas JTAG, e agora não é necessário abrir o compartimento das baterias. E para que seja possível carregar também os sketches, ele adicionou ambos os ports seriais a esse mesmo conector, incluindo também um interruptor, pois com as baterias instaladas, não há como desligar o dispositivo fisicamente de outra forma.
Levei bastante tempo trabalhando com o soldador, estilete e pistola de cola. Enfim, gravar os sketches via wireless é muito mais conveniente, preciso inventar algo rapidamente para isso.
O Arduino IDE usa o programa . Ele se comunica com o microcontrolador através do protocolo , que permite a transferência de arquivos em ambas as direções. Ele é mal compatível com canais onde há possíveis atrasos variáveis, distorção e perda de dados. Se algo falha ou barulha no canal serial, você pode enlouquecer tentando descobrir a causa. Uma vez, o autor trabalhou por meio dia até entender que o problema estava em um cabo ruim, além de um caprichoso conversor de interface CP2102. Até mesmo um microcontrolador com um conversor de interface embutido, como o ATmega32u4, pode às vezes ter essas “manha”. Todo usuário do Arduino já percebeu que erros ao carregar sketches não são tão raros. Às vezes, a gravação ocorre normalmente, mas ao fazer a leitura de verificação, um erro é encontrado. Isso não significa que houve um erro durante a gravação — a falha ocorreu durante a leitura. Agora imagine que ao operar “sem fio” isso aconteça, mas muito mais frequentemente.
Após experimentar diferentes maneiras de resolver esse problema, o autor concebeu o seguinte. O dispositivo possui uma memória flash de 128 kilobytes com interface SPI — recebendo dados através de fios (lembrando que já há um dispositivo com um conector lateral com o autor), usamos essa memória como um buffer, e enviamos os dados por meio de um canal de rádio para outro dispositivo. Essa é uma saudação da Cybiko.
Após escrever o código para trabalhar com o canal de rádio, bem como a fonte, o carregador se tornou maior que 4 kilobytes. Portanto, o valor de HFUSE teve que ser alterado de 0xDA para 0xD8. Agora, o carregador pode ter até 8 kilobytes de comprimento, e o endereço inicial é igual a 0x1E000. Isso está refletido no Makefile, mas deve ser considerado também ao carregar. com avrdude.
O transceptor padrão 802.15.4 no ATmega128RFA1 é originalmente projetado para operar sob o protocolo , que é bastante complexo, portanto, o autor decidiu, ao invés disso, simplesmente transmitir pacotes. Isso é implementado no ATmega128RFA1 de forma hardware, então o código exigido é pouco. Além disso, para simplificar, o autor decidiu usar um canal fixo, não permitindo até mesmo uma seleção manual. O padrão 802.15.4 suporta 16 canais numerados de 11 a 26. Eles estão bastante congestionados, alguns também sobrepõem os canais WiFi (os canais ZigBee estão marcados em vermelho, e os WiFi em azul, verde e amarelo).
Descobriu-se que os canais 15 e 26 são os menos suscetíveis a interferências de WiFi. O segundo foi o escolhido pelo autor. Aviso: o tradutor não sabe se é permitido simplificar assim o ZigBee. Talvez valha a pena programar um pouco mais e implementá-lo totalmente?
No primeiro dos dispositivos, é necessário implementar uma máquina de estados que transmita dados através do protocolo STK500. Na maior parte, as mensagens transmitidas e recebidas são autossuficientes, mas algumas estão ligadas a mensagens que passaram anteriormente pelo canal. A descrição do diálogo é fornecida. .
Um aspecto importante desse diálogo é a transmissão de pacotes destinados à gravação na memória flash do dispositivo de destino. Em microcontroladores simples da família AVR, o tamanho da página é de 128 bytes, mas no ATmega128RFA1, ele é de 256. E a memória flash que se conecta via protocolo SPI possui o mesmo tamanho. Quando o programa no primeiro dispositivo está carregando o sketch, ele não o envia imediatamente para o segundo, mas escreve na memória. Quando a IDE do Arduino verifica a correção da gravação, é enviado o que foi gravado. Agora, é necessário transmitir os dados recebidos pelo canal de rádio para o segundo dispositivo. Nesse processo, a alternância entre receber e transmitir acontece com bastante frequência. O protocolo STK500 é indiferente a atrasos, mas não tolera perda de dados (estranhamente, foi mencionado que os atrasos na transmissão de dados também têm impacto). E perdas na transmissão sem fio são inevitáveis. O ATmega128RFA1 tem uma implementação de hardware para solicitar retransmissões em caso de dúvidas sobre a correção da transmissão, mas o autor decidiu implementar isso programaticamente por conta própria. Ele desenvolveu um protocolo em que um lado transmite muito mais dados do que o outro.
Ele não é perfeito, mas tudo funciona. A página de 256 bytes é dividida em quatro segmentos, cada um dos quais é enviado pelo canal de rádio na forma de pacotes. Um pacote contém até 125 bytes de dados mais um byte para o comprimento e dois para CRC. Assim, fragmentos de 64 bytes junto com os números das páginas e segmentos (de 0 a 3) são colocados lá. No dispositivo receptor, existe uma variável que permite rastrear quantos segmentos foram recebidos, e quando todos os quatro chegam, uma confirmação é enviada para o dispositivo transmissor, indicando que a página inteira foi recebida. Se não houver confirmação (se o CRC não combinar), a página inteira é enviada novamente. A velocidade, nesse caso, é até maior do que na transmissão por cabo. Veja:
Mas, na verdade, seria bom prever uma maneira prática de conectar um cabo aos dispositivos para carregar os sketches por essa via. Por exemplo, colocar um conversor de interface CP2102 como na foto dentro do dispositivo e colá-lo na placa de modo que suporte a força ao conectar e desconectar o cabo Micro USB.
Além disso, há um regulador de 3,3 volts (e como utilizá-lo em um dispositivo com alimentação de 6 volts — a menos que haja um regulador semelhante, e seja possível adicionar dois diodos para escolher automaticamente de qual deles o dispositivo será alimentado). Deve-se remover todos os três LEDs da placa do conversor de interface, caso contrário, eles sobrecarregarão as baterias ao serem utilizados, além de interferirem na leitura do teclado e no funcionamento da memória flash com interface SPI.
A busca pelo objetivo acabou sendo até mais interessante do que alcançá-lo (e não precisamos daquela piada sobre o ônibus). O autor aprendeu muito sobre bootloaders para AVR, memória flash com interface SPI, protocolo STK500 e o padrão 802.15.4.
Todo o resto do código, além da biblioteca descrita acima — , e ele também está sob GPL v3. O Twitter do autor — .
Fonte: habr.com
