Upgrade do ATMega328P para ATMega 328PB

Sim, estou devendo algumas finalizações de “estórias”. Espero fechar essa semana. Enquanto isso, vou compartilhar uma experiência que tive e que pode poupar tempo se você é um daqueles que tem placa personalizada baseada no processador ATMega328P (usado no Arduino Uno ou Nano, um TQFP de 32 pinos). Não deixe de ler até o fim.

Continue Lendo “Upgrade do ATMega328P para ATMega 328PB”

Anúncios

Entendendo o nRF24L01 (IV)

Nesse post vamos discutir o quadro do rádio nRF24, deixando os próximos posts para os comandos/registros e, no gran finale, a apresentação do código. Se não leu os anteriores, os links para as partes I, II e III estão aqui.

O quadro empregado pelo rádio está a seguir, em mais uma imagem extraída do manual:

nrf24_07

O campo preâmbulo serve para estabilizar (sincronismo talvez fosse um termo melhor) o receptor com um padrão cheio de transições. Esse padrão é b01010101 ou b10101010, dependendo se o primeiro bit de endereço a ser transmitido começa com 0 ou com 1, respectivamente.

O endereço já foi discutido, podendo ser de 3 a 5 bytes de comprimento.

Já o campo de controle do quadro traz informações sobre o tamanho do campo de dados (de 0 a 32 bytes, num campo de 6 bits), identificação do pacote (PID, campo de 2 bits) e se a característica de auto reconhecimento está ativa ou não (campo de 1 bit):

nrf24_08

A cada transmissão de um quadro novo (não vale para retransmissões automáticas do mesmo quadro), o PTX incrementa o PID. Do outro lado, o PRX irá conseguir perceber se o quadro é uma retransmissão ou um novo, analisando esse campo e o CRC. Como o campo é de apenas dois bits, somente número de 0 a 3 são possíveis, girando rapidamente. No entanto, isso é condizente com a RX FIFO, de apenas três posições.

O manual cita a situação de possível perda de alguns quadros e giro do PID, gerando uma situação onde um quadro novo pode ser igual a outro do passado e que será rejeitado. O que ele não deixa claro é que, no meu entendimento, o tal quadro do passado ainda estará na RX FIFO,  ou seja, não teria sido recebido. Confuso ? Pense o seguinte: você está transmitindo o valor de um sensor continuamente. Imagine que o valor não mudou. Se mandou um quadro, perdeu outros três e mandou o seguinte, o PID será igual ao primeiro citado e esse quadro mais novo rejeitado. Ok, ele é idêntico ao já armazenado na RX FIFO mas, de fato, o da FIFO é velho e o novo foi rejeitado.

Pra finalizar, o payload (dados úteis) é a informação que você estará efetivamente enviando e o CRC, de um ou dois bytes (configurável), encerra o quadro.

O CRC, para um byte, é dado pelo polinômio x^8 + x^2 + x + 1, com valor inicial 0xFF. Quando dois bytes são usados, o polinômio é o x^16 + x^12 + x^5 + 1, valor inicial 0xFFFF. Esse é o CRC-16-CCITT, usado no Bluetooth, XModem, X.25, entre outros. O de um byte, pelo polinômio, é o CRC-8-CCITT. Vale uma lida na página da Wikipédia e no fantástico “A Painless Guide to CRC Error Dectection Algorithms“.

Parece complicado mas, no fundo, você só se preocupa com o payload. O Enhanced Shockburst cuida do resto para você. Até a próxima !

 

Já temos clima para entender o DHT11 ? (II)

Como eu havia comentado no final do primeiro post, o código de leitura do DHT11 está disponível aqui. A implementação é relativamente simples e segue a forma de funcionamento do sensor. No caso, uma máquina de estados é responsável por realizar todas as fases do sensor:

  • Acordá-lo e esperar um segundo (esse estado pode ser evitado caso o sensor não vá ser desligado)
  • Realizar a requisição (pulso de 18ms)
  • Aguardar o reconhecimento do pedido (os dois pulsos de 80us)
  • Esperar os vários bits 0 ou 1, dependendo da duração

Continue Lendo “Já temos clima para entender o DHT11 ? (II)”

Entendendo o nRF24L01 (III)

Se não leu ainda as postagens anteriores sobre o nRF24, é bom fazer isso agora  (I e II). Mas volta aqui depois !

Uma das características mais interessantes do nRF24 é o suporte ao que ele chama de Enhanced Shockburst. Essa característica permite a criação de um link bidirecional confiável, com um tratamento em hardware para envio de confirmações de recebimento (ACK, de acknowledge) , CRC e retransmissões automáticas em caso de falha.

Continue Lendo “Entendendo o nRF24L01 (III)”

Entendendo o nRF24L01 (II)

Hora de retomar a discussão sobre o nRF24L01. Se não leu o primeiro post, a hora certa de fazê-lo é agora. Basta clicar aqui. Mas volta depois, nhein ?

O nRF24L01 vem em um encapsulamento pequeno, 4x4mm, do tipo QFN de vinte pinos. A disposição dos pinos foi bem pensada, com uma lateral devotada para a comunicação e outra, a oposta, para a antena. Uma terceira lateral suporta o cristal e, junto com o quarto lado, realizam a alimentação e tensões de referências do chip.

Continue Lendo “Entendendo o nRF24L01 (II)”

Já temos clima para entender o DHT11 ? (I)

Antes de mais nada, vamos deixar claro. Esse sensor de temperatura e umidade, DHT11, é terrível. Mesmo sendo campeão em aparições em trabalhos de conclusão de curso ou em gambiarras diversas pra impressionar a sogrona, ele continua sendo bem fraco. Lento, pouco preciso, pouco exato e, o pior de tudo, com um protocolo de acesso proprietário que, por mais que lembre o protocolo one wire, é super chato de se implementar de forma adequada. Mas não desista, tem muita discussão boa até o final da página, até mesmo para quem já usou esse sensor.

Continue Lendo “Já temos clima para entender o DHT11 ? (I)”