Tudo começou com a aquisição pelo autor de um dispositivo interessante no mercado secundário - Smart Response XE (). Destina-se às escolas: cada aluno da turma recebe um aparelho semelhante a um caderno eletrônico ou tradutor da década de noventa, o professor faz uma pergunta e os alunos digitam as respostas nos teclados dos aparelhos, que são recebidas por meio de um canal de rádio (802.15.4) a um receptor conectado ao PC do professor.
Esses dispositivos foram descontinuados há vários anos, e o que as escolas compraram por US$ 100 a US$ 200 cada agora está aparecendo no eBay por US$ 10 ou menos. O hardware lá é muito adequado para experimentos geeks:
- teclado de 60 teclas
- tela com resolução de 384×136, 2 bits por pixel - semelhante a BC, CGA, mas 4 não cores, mas gradações de brilho
- microcontrolador ATmega128RFA1 (memória flash de 128 kB, ROM de 4 kB, RAM de 16 kB, transceptor 802.15.4)
- externa (em relação ao microcontrolador, não ao dispositivo inteiro) memória flash de 1 megabit (128 kilobyte) com interface SPI
- compartimento para 4 elementos AAA.
Pelo nome do microcontrolador fica claro que ele pertence à família AVR, o que significa que tornar o dispositivo compatível com Arduino é uma tarefa mais do que trivial...
Das notícias em diante o autor descobriu o que é (o mesmo link informa o que conectar e onde), tendo a oportunidade de rodar jogos para Arduboy:
Mas o autor está mais interessado na oportunidade não de jogar no aparelho, mas de estudar:
- memória flash com interface serial SPI
- gerenciadores de inicialização para AVR
- padrão 802.15.4
O autor começou escrevendo (GPL v3), que permite inicializar a exibição, gerar texto e retângulos e acessar a memória flash SPI. Então ele começou a ter ideias para o uso prático do aparelho: um terminal de bolso compatível com VT-100, jogos multiplayer. Depois de reconstruir três dispositivos, ele decidiu “ensiná-los” a receber esboços “pelo ar”. O que seria não apenas interessante, mas também muito conveniente: a caixa do dispositivo é sempre difícil de abrir e sob a tampa do compartimento da bateria existem apenas orifícios que permitem conectar um programador JTAG à placa.
Isso é suficiente para carregar o bootloader do Arduino, mas não o esboço - a porta serial não está conectada lá, então você ainda não pode fazer isso sem abrir o gabinete. Além disso, as linhas TX0 e RX0 da primeira porta serial são combinadas com as linhas de polling da matriz do teclado, ou seja, aquelas que pesquisam as teclas de função nas laterais do display. Mas o que você pode fazer - o autor construiu isto:
Ele trouxe as linhas JTAG para lá e agora não há necessidade de abrir o compartimento da bateria. E para que os esboços pudessem ser carregados, conectei as duas portas seriais no mesmo conector, acrescentando também um switch, pois com as baterias instaladas é fisicamente impossível desligar o aparelho de qualquer outra forma.
Demorou algum tempo para trabalhar com um ferro de soldar, um canivete e uma pistola de cola. Em geral, enviar esboços “over the air” é muito mais conveniente, precisamos urgentemente inventar algo para isso.
Arduino IDE usa o programa para fazer upload de esboços . Ele interage com o microcontrolador usando o protocolo , que permite transferir arquivos em ambas as direções. É pouco compatível com canais onde são possíveis atrasos variáveis, distorções e perda de dados. Se algo se soltar ou fizer barulho no canal serial, você pode enlouquecer procurando a causa. Certa vez, o autor sofreu meio dia até perceber que o problema era um cabo ruim, além de um conversor de interface CP2102 caprichoso. Mesmo um microcontrolador com um conversor de interface integrado, por exemplo, ATmega32u4, às vezes pode agir assim. Todo usuário do Arduino notou que erros ao enviar esboços não são tão raros. Às vezes a gravação corre bem, mas durante uma leitura de teste é detectado um erro. Isso não significa que houve um erro durante a escrita - houve uma falha durante a leitura. Agora imagine que ao trabalhar “over the air” acontecerá a mesma coisa, mas com muito mais frequência.
Depois de tentar diferentes maneiras de superar esse problema, o autor descobriu o seguinte. O aparelho possui memória flash de 128 KB com interface SPI - recebemos dados pelos fios (lembre-se que o autor já possui um aparelho com conector na lateral), usamos essa memória como buffer e enviamos os dados pelo rádio canal para outro dispositivo. Olá de Cybiko.
Depois de escrever o código para trabalhar com o canal de rádio, assim como a fonte, o carregador passou a ter mais de 4 kilobytes. Portanto, o valor HFUSE teve que ser alterado de 0xDA para 0xD8. Agora o bootloader pode ter até 8 kilobytes e o endereço inicial agora é 0x1E000. Isso se reflete no Makefile, mas também deve ser levado em consideração ao preencher via Avrdude.
O transceptor 802.15.4 no ATmega128RFA1 foi originalmente projetado para operar usando o protocolo , o que é bastante complicado, então o autor decidiu apenas transmitir pacotes. Isso é implementado em hardware no ATmega128RFA1, portanto, pouco código é necessário. Além disso, para simplificar, o autor decidiu utilizar um canal fixo, não permitindo selecioná-lo nem mesmo manualmente. O padrão 802.15.4 suporta 16 canais com números de 11 a 26. Eles são bastante lotados, alguns também se sobrepõem aos canais WiFi (vermelho são canais ZigBee, azul, verde e amarelo são WiFi).
Descobriu-se que os canais 15 e 26 são menos suscetíveis a interferências de WiFi. O autor escolheu o segundo deles. Isenção de responsabilidade: o tradutor não sabe se é permitido simplificar o ZigBee desta forma. Talvez devêssemos fazer um pouco mais de programação e implementá-la completamente?
No primeiro dispositivo é necessário implementar uma máquina de estados finitos que transmita dados através do protocolo STK500. Na maioria das vezes, as mensagens transmitidas e recebidas são autossuficientes, mas algumas estão vinculadas àquelas que passaram pelo canal anteriormente. A descrição do diálogo é fornecida .
Um componente importante deste diálogo é a transmissão de pacotes destinados a serem gravados na memória flash do dispositivo de destino. Para microcontroladores simples da família AVR, o tamanho da página é de 128 bytes, mas para o ATmega128RFA1 é de 256. E para a memória flash conectada via protocolo SPI é o mesmo. O programa do primeiro dispositivo, ao carregar um esboço, não o transfere imediatamente para o segundo, mas o grava nesta memória. Quando o IDE do Arduino verifica a exatidão da entrada, é enviado o que foi escrito ali. Agora precisamos transmitir os dados recebidos via canal de rádio para o segundo dispositivo. Ao mesmo tempo, a mudança de recepção para transmissão e vice-versa ocorre com bastante frequência. O protocolo STK500 é indiferente a atrasos, mas não tolera perda de dados (estranho, mas foi dito acima que atrasos também afetam a transferência de dados). E as perdas durante a transmissão sem fio são inevitáveis. O ATmega128RFA1 possui uma implementação de hardware integrada para solicitações repetidas quando há dúvidas sobre a exatidão da transferência, mas o próprio autor decidiu implementar o mesmo em software. Ele desenvolveu um protocolo no qual muito mais dados fluem para um lado do que para o outro.
Não é perfeito, mas funciona. A página de 256 bytes é dividida em quatro segmentos, cada um dos quais é transmitido pelo ar como um pacote. Um pacote pode conter até 125 bytes de dados mais um byte para comprimento e dois bytes para CRC. Portanto, fragmentos de 64 bytes junto com números de páginas e segmentos (de 0 a 3) são colocados lá. O dispositivo receptor possui uma variável que permite rastrear quantos segmentos foram recebidos e, quando todos os quatro chegam, o dispositivo remetente recebe a confirmação de que a página inteira foi recebida. Sem confirmação (CRC não corresponde) – reenvie a página inteira. A velocidade é ainda maior do que na transmissão via cabo. Ver:
Mas, em geral, seria necessário fornecer uma maneira conveniente de conectar o cabo aos dispositivos para fazer upload de esboços e através dele. Por exemplo, coloque dentro de um conversor de interface no CP2102, como na foto, e cole-o na placa para que possa suportar a força ao conectar e desconectar o cabo Micro USB.
Ele também possui um estabilizador de 3,3 volts (e como usá-lo em um dispositivo com fonte de alimentação de 6 volts - desde que tenha o mesmo estabilizador, e você pode adicionar dois diodos para selecionar automaticamente qual deles alimentará o dispositivo) . Todos os três LEDs devem ser dessoldados da placa conversora de interface, caso contrário, eles carregarão adicionalmente as baterias ao operar com eles e também interferirão na pesquisa do teclado e no trabalho com memória flash com interface SPI.
Perseguir um objetivo acabou sendo ainda mais interessante do que alcançá-lo (e não precisa daquela piada do ônibus). O autor aprendeu muito sobre bootloaders AVR, memória flash SPI, protocolo STK500 e padrão 802.15.4.
Todos os outros códigos além da biblioteca descrita acima são - , e também está sob GPL v3. Twitter do autor - .
Fonte: habr.com