Escolhendo a MCU e Atribuindo Pinos

Rec 22-jan-2008 23:04

Em posts anteriores, esbocei os conceitos iniciais para o meu dispositivo monitorador de energia elétrica. Hoje é hora de aprofundar algumas coisas e fazer algumas escolhas.

Primeiro: eu tenho vários microcontroladores AVR aqui, mas qual devo adotar? Isso depende de quais recursos e periféricos precisaremos e quantos pinos eles vão requerer. Vamos tentar enumerá-los, começando pelo mínimo absoluto:

Ha vários AVRs de 8 pinos que eu poderia usar, tais como o ATtiny13, 45 e o 85. Creio que o primeiro claramente está fora porque só tem 1KiB de memória de programa e, intuitivamente, chuto que o firmware vai ficar maior do que isso. Esses chips não têm UARTs, mas a porta USI pode emulá-las perfeitamente bem a baixas velocidades -- e, lembremos, nosso conversor de nível nos limita a 9,600 bps.

Os AVRs têm osciladores RC internos para geração do clock, mas eles não são muito precisos --2% na melhor das hipóteses. Usá-los tornaria a precisão das medidas de freqüência dependentes demais da temperatura. Então, precisamos mesmo de um cristal de quartzo para sermos capazes de obter medidas precisas. E é trivial usá-los, basta ligar o cristal e os dois capacitores de carga direto nos pinos apropriados do AVR, pois ele já vem com o circuito gerador de clock embutido.

Agora, se quisermos LCD e armazenamento, precisaremos de mais pinos:

Os LCDs compatíveis com o HD 44780 operam podem operar em dois modos, usando um barramento de dados de 4 ou 8 bits. Além diss, eles têm três pinos de controle: E, RS e RW. Então, em modo de 8 bits precisaremos de 11 pinos, e em modo de 4 bits precisaremos de 7. Na Internet pode-se encontrar implementações que usam apenas 6 pinos, aterrando o sinal RW e escrevendo na memória do LCD às cegas, sem aguardar confirmação, mas tomando o cuidado de mandar os dados devagar.

Precisamos ter a capacidade de desligar o LCD para economizar energia quando operando a partir das baterias. Ouço dizer que há LCDs que requerem meros 1mA para funcionar. Se você for usar um desses, pode até deixá-lo ligado o tempo todo. Mas como não tenho muita certeza de quanta corrente o meu LCD vai requerer, vou deixar essa opção na mesa.

A EEPROM I²C (também chamada de "TWI", na literatura da Atmel) requer apenas dois pinos. Assim, nosso total até o momento é 18 pinos, o que nos coloca fora do alcance dos ATtiny861s dos quais tenho alguns. Com efeito, o ATtiny2313 é o único AVR de 20 pinos cujos 18 são usáveis por software, mas ele não tem um conversor analógico-digital.

Pelo jeito então parece que vai ser mesmo o venerável ATmega8, que tem a vantagem de ser razoavelmente fácil de achar até mesmo aqui no Brasil. Ele provê 23 pinos usáveis (22 se você usar Programação no Próprio Circuito ou "ISP", da sigla em inlgês "In-System Programming"). Podemos usar os 4 pinos restantes para outras funções, tais como botões de controle (+1 pino) ou para um medidor de voltagem da bateria (+1 pino) para nos avisar quando a bateria ficar fraca. Falando nisso, podemos também adicionar um buzzer para fazer o dispositivo apitar quando faltar energia e vermos se condiz com os bipes do meu no-break.

Uma alternativa seria substituir a EEPROM por um cartão SD. Esses cartões têm uma interface SPI que combina perfeitamente com a porta SPI do ATmega8. Isso aumentaria nossa necessidade para 20 pinos: as portas SPI precisam de 4 sinais: SCK (serial clock), MISO (Master-In, Slave-Out), MOSI (Master-Out, Slave in) e CS (chip select). Esta última poderia até ser omitida, mas talvez isso impeça que usemos ISP -- o ISP usa a porta SPI e o pino CS do cartão SD é usado para dizer-lhe "ei, tou falando com você", de sorte que se o fixarmos, o cartão vai achar que toda atividade no barramento SPI é direcionada a ele, quando na verdade poderia ser para o subsistema ISP.

Os cartões SD também acrescentariam outras complicações. Precisaríamos de 512 bytes para enfileirar as escritas ao SD porque esse é o tamanho do setor, que é a menor unidade endereçável no SD. Os 1KiB de RAM que o ATmega8 possui deveriam comportar isso, mas certamente complica um pouco o software porque poderemos precisar ler do cartão (quando, logo após a energia voltar depois de uma queda, o computador principal pede para puxar as medidas que perdeu) sem interromper as medições em andamento. Em contraste, a EEPROM é endereçável byte a byte.

Além disso, os cartões SD requerem alimentação de 3,3V e podem consumir até 60mA quando escrevendo. Teoricamente eles têm um "modo de espera" que consome menos de 1mA quando ociosos. Mas não tenho lá muita certeza de que isso funcione bem, especialmente nesses cartões genéricos. O regulador de voltagem de baixa queda LM2931 que usaremos pode até prover (meio apertado) essa corrente, mas se o tal "modo de espera" não funcionar confiavelmente, vai arruinar a autonomia da bateria. Em contraste, a EEPROM consome microampères quando lendo ou em espera e poucos miliampères quando escrevendo (e por apenas alguns milissegundos).

A grande vantagem dos cartões SD é o tamanho: eles provêm centenas de megabytes de armazenamento a preços incrivelmente baixos, de sorte que poderíamos registrar não só o histórico de faltas de luz, mas também as medidas individuais de freqüência e voltagem durante anos.

Acho que deveria resistir à tentação de tornar esse dispositivo um registrador de parâmetros da linha elétrica. O que ele deve ser é um registrador de histórico de falhas: o que realmente me interessa é saber os horários e durações das falhas do suprimento de energia elétrica. As medidas de freqüência e voltagem são só os insumos para se chegar a isso. Então, por ora, vou ficar com a EEPROM I²C 24C512 de 64KiB como a escolha mais simples e segura.

Se usarmos blocos de 16 bytes para registrar um evento (mais do que suficiente para "ano-mês-dia hora:minuto:secundo.décimos" mais identificador do evento e outros parâmetros), poderíamos armazenar 4096 eventos nos 64KiB. Apesar de eu não ter definido exatamente muito bem o que venha a ser uma "falha na linha", intuitivamente duvido que teremos muito mais mais do que 10 eventos por dia em média. Então, teríamos espaço para uns 400 dias de eventos -- mais do que um ano, o que me parece bem razoável.

Mesmo se decidíssemos voltar atrás e registrar as voltagens e freqüências médias a cada 5 minutos (digamos, para fazer um gráfico com o MRTG ou RRDtool) e usássemos o mesmo formato de 16 bytes (que poderia ser muito menor), teríamos 4096 eventos / 288 (quantidade de blocos de 5 minutos em um dia) = 14,2 dias até que a memória enchesse -- o que também me parece bem decente. Além disso, podemos expandir para até quatro 24C512s usando apenas os mesmos dois pinos.

Resumindo: vamos usar um ATmega8 e as atribuições preliminares dos pinos serão:

O próximo passo será considerar exatamente como realizaremos as medições. Isso influenciará na escolha da freqüência do clock e na alocação dos recursos do microcontrolador.

Próximos posts sobre esse assunto:

• Cálculos para o Monitor de Energia Elétrica
• Começando a Montagem do Monitor de Linha Elétrica
• Progresso com o Monitorador de Falhas de Energia