Tag Archive for Assembly

Timer Fotografico AVR

O Rodrigo Pinheiro Matias, colega da PICLISTBR, teve a idéia de criar um Temporizador Fotográfico usando um AVR AtMega8, e escreveu o código na linguagem C.

Ele fez o layout da plaquinha PCI e lançou o trabalho dele na PICLISTBR para comentários e sugestões. Eu olhei o código do programa em C que ele escreveu, e literalmente achei muito complicado para pouca coisa. De verdade a programação C é assim mesmo. Para coisas pequenas ela fica muito grande. Então eu resolvi ajudar o Rodrigo, e me divertir ao mesmo tempo, e prometi a ele reescrever o firmware desse mesmo temporizador, com exatamente as mesmas funções, em Assembly.

Esse temporizador permite programar de 1 a 99 minutos, para tal utiliza tres teclas, uma para incrementar o tempo selecionado em minutos, outra para decrementar e uma terceira para dar inicio ao processo do temporizador, acionar o relay e decrementar os minutos.

Ao decrementar até zero, o relay é desligado e o LED pisca indefinamente para informar o usuário. Claro que a terceira tecla não faz nada se o temporizador está com zero minutos programado. Se o contador já estiver no limite de 99 minutos, a tecla #1  não incrementará se pressionada, e piscará o LED tres vezes como informação de limite. O mesmo para a tecla #2 que decrementa, se o contador estiver com zero, essa tecla não irá decrementar, e piscará o LED tres vezes para informar o usuário do limite. Não apertei muito o código, e ocupou em torno de 240 bytes na Flash, uma ninharia.

Abaixo o texto do código em assembly, e ao final o link para fazer download do arquivo hex a gravar na Flash do AtMega8. Fuses são H-Fuse:D9, L-Fuse:64, que basicamente seleciona Clock interno de 8MHz.

Essa versão de software (1.0) roda na mesma plaquinha desenhada pelo Rodrigo.A próxima versão, 7.1, permitirá incluir dois displays de sete segmentos para mostrar o valor do timer e nessa nova versão, haverá mudança de pinos para as teclas e LED, e não rodará na plaquinha atual.

Update: 28 Março 2014
O codigo fonte abaixo já é o novo, com 2 displays 7 Segmentos, e 398 bytes de código. Leia no texto abaixo a forma de uso e funcionamento.

AtMega128 vs At89s8252 firmware

Pois é, estou desenvolvendo um firmware para uma máquina nova, usando o AtMega128 (Atmel) 16MHz com 256kBytes SRAM externa, 1MB Eeprom externa, etc, mas cada nova rotina deve ser testada, e para isso tem que gravar a Flash do AtMega toda vez… tá bom, a flash dele suporta 10 mil regravações, mas é um saco pensar nisso.   O AtMega128 que estou usando é um TQFP64 soldado na placa de teste, tá bom, é só dessoldar e meter outro, mas, é um saco pensar nisso.

Na época do 8051, usava-se eprom externa, que beleza.  Tinha que apagar, gravar, os cambal, demorava mais, até um dia eu fazer uma engenhoca com SRAM e um código minusculo em eprom.  Na verdade fiz um bootloader, na época que nem se pensava nesse nome.  O código mínimo fazia o 8051 rodar a UART na velocidade mais alta possível aceita pelo PC e esse despejava o novo código a rodar via serial, o 8051 recebia, gravava na SRAM externa e ao final ele mesmo virava um flip-flop e substituia a eprom pela SRAM e o novo código entrava no ar.   Muito rápido e funcional.

Não dá para fazer isso com os AtMega, exceto com um novo chip AVR32 que permite rodar código de memória externa.

A grande vantagem de usar o AtMega128, com 128kBytes de Flash, é que me deixa respirar.   Escrevendo tudo em assembly, é claro, pois *não existe* nenhuma outra linguagem de programação que se possa considerar séria… rsrs… eu sempre me preocupo em reduzir código, reutilizar código, se o mesmo trecho será usado mais de uma vez – passa a ser subrotina, etc e tal.  Essa “neura” consome tempo, e sempre se pensa em fazer um grande código com uma memória flash minuscula.  Não é à toa que tudo o que eu já escrevi na vida, e tem coisa muito complexa, nunca passou de 7kBytes.   Mas agora, com 128kBytes de flash à disposição, eu respiro e a coisa mudou de cor e cheiro, agora eu não mais me preocupo em economizar espaço, nem de Flash, nem de SRAM, e agora eu deito e rolo, me preocupo sim com velocidade de processamento, e tenho medido tudo para garantir que nada mantenha o AtMega ocupado fora do razoável.

Para ter uma idéia, ainda estou na dúvida sobre controlar os displays de sete segmentos, 20 no total, com refresh de 100Hz do AtMega, usando chips 74HC595 e transistores, ou o Max7219, que faz o serviço de refresh sozinho, mas, a rotina do refresh para o HC595 toma só 3.5 microsegundos. Isso é nada, certo?  Simples, eu não faço o bit-bang de mandar bit a bit, eu uso o dispositivo interno do AtMega chamado SPI, é um tipo de serial que pode transmitir a velocidades altíssimas, de no máximo Clock/2, ou seja, 16MHz/2 = 8Mbps, eu soco o byte no registrador da SPI e ela faz o serviço sujo.  Ou seja, 3.5us a cada 10ms, é um overhead de somente 0.035%, com isso garanto que o AtMega estará 99.965% do tempo livre para outras coisas.

Então, com a nova liberdade de flash do AtMega128, hoje eu entendo porque muita gente não gosta de Assembly e prefere C, pois não precisa se preocupar muito com a maneira que o código final ficará, o tamanho dele, a performance, etc.  É mais fácil, mais livre e menos preocupante.

Agora, veja só.   Esse novo firmware que estou escrevendo, parti do scratch, reescrevendo algo que foi escrito para o At89S8252, um 8051 da Atmel, em 1997.  Já está 98% pronto, escrevi em torno de 5 mil linhas de código em assembly e comentários, em menos de 2 semanas, e está ocupando menos de 5kBytes de código, contra os 7k do 8051.

É estranho, que mesmo não me preocupando em economizar espaço, o que escrevo hoje fica menor que o anterior, e então penso, ou o mesmo tipo de código para o 8051 ocupa mais memória que os AVRs, ou depois de 16 anos eu aprendi naturalmente a escrever de forma mais produtiva e inteligente.  Creio que ambos.

O custo de um AtMega128 compensa, pois passa-se a ter 6 e meia portas de 8 bits, (mais de 50 pinos de I/O), 8 ADCs, alguns podendo ser programados para entrada complementar, duas USARTs, PWM de pancada, 128k de Flash, 4k de SRAM interna, 4k de eeprom interna e permite usar SRAM ou I/Os externos como o 8051 o fazia, e acessa-se esses I/Os ou memória externa como uma extensão da interna, maravilha, além de uma carrada de outros dispositivos internos disponíveis.  Ou seja, o AtMega128 vem carregado com tudo que pode, exceto USB e Ethernet.

Eu iniciei nos AVRs brincando com o At90S2313, depois passei para o AtMega8 e naturalmente sai matando o AtMega128.

Tudo bem que uma série de novos chips da concorrência rodam a mais de 50MHz e possuem muita flash, principalmente os novos ARMs da vida.

Mas é muito gostoso trabalhar com um AVR rodando a 16MHz (16 MIPS) e ver a coisa zunir bits à torto e direito.