AUXÍLIO PARA FAZER UM PEQUENO CÓDIGO EM ASSEMBLY PARA AVR

Felipe Electronic · 9 de maio de 2014

entendi sei não hein, tem um loop dentro da ISR...

O grande problema de fazer assim é o fato de parar o processador ate encher o buffer... a solução ganha em velocidade por um lado, porém você perde CPU para outras tarefas, isso pode causar outro problema, se antes tinhamos register pressure, agora teremos starvation desse processor até que a CPU seja liberada a ao final do evento.

Vou olhar se ainda da pra otimizar mais sem parar a CPU...

Em todo caso se funciona, vai dai que eu vou daqui.

Abs.

aphawk · 9 de maio de 2014

@vtrx,

Pois é ... com certeza vai ter uma atualização sim !!!!!! voce tá adorando né Vtrx ????? heheheheh Imagino a hora que o Mor também começar a fazer isso ......

@,

Pera, isso não será feito em una ISR !!!!! É uma subrotina a ser chamada pelo Bascom ! Porisso que deu para fazer !

Sim, tive de implementar um loop. Veja o princípio de funcionamento deste analizador lógico que eu estou bolando aqui :

1 - Primeiro, tem um menú onde seleciono o STEP do counter, que na verdade é a mudança do Overflow feito no Timer0.

Do jeito que está, o Timer0 é um "Prescaler que divide por 40" o clock, o que dá uma resolução suficiente para atender até 500 Khz.

Mas olha o problema : o counter do Timer1 é de 16 bits, e estou armazenando 16 bits também. Então, tenho um problema, que é quando o Timer1 ultrapassa 65535 , a contagem vai virar, e o que eu ler no Timer1 vai estar totalmente errado. O período para dar overflow é de 65536*40 = 2.621440 ciclos, que a 20 Mhz dá um tempo de 131 milisegundos. Eu definí que se perder este timer, pára de capturar....

Esse é o tempo máximo que o meu programa vai esperar entre dois eventos, senão os tempos estarão tudo errado.

Esse tempo é o suficiente para quase tudo que conheço, mas existem alguns protocolos doidos de controle remoto por infravermelho que podem passar esse limite ! Tem um que eu ví que pode atingir 200 mseg....

Então, fiz o menú, que permite um tempo 2 vezes maior, o que permitiria ler 262 milisegundos. Mas com resolução menor, de cerca de 80 ciclos. A frequência máxima dos sinais, neste caso, vai ser de 250 Khz. Nada me impede de aumentar ainda mais os tempos, com a perda decorrente de resolução da amostragem. Afinal, nem tudo é perfeito, mas está bem superior ao projeto original.

2 - Segundo, como a resolução máxima é de 40 ciclos, eu tinha de dar um jeito para que o tratamento completo ficasse abaixo disso, que era o objetivo desde o início.

3 - Tenho um buffer suficiente para 600 medidas. Então, temos duas possibilidades para que a rotina termine :

a - Estouro do Timer1......

b - Estouro do Buffer de dados.

Porisso que tive de implementar aquela variável flag_24b_over que eu consulto dentro do loop. Eu programei uma interrupção por Overflow para o Timer1. Apenas essa pode ocorrer durante o intervalo de aquisição de dados..

A interrupção do Timer1 é gerada por hardware, onde cai numa rotina minha que apenas seta a variável flag_24b_over e sai.

Assim, quando o meu loop perceber que a variável está setada,. ele termina o processo, devolvendo o controle ao Bascom. E eu procedo de acordo com o sisteminha que bolei.

Não se preocupe com isso de parar a CPU, porque ela estará MESMO dedicada apenas a este processo de aquisição de dados. E afinal o tempo é bem pequeno, abaixo de 0,3 segundos no pior caso.

Não tem como fazer ficar abaixo de 40 ciclos usando interrupt, pois só para salvar o SREG e um par de registradores, perdemos 14 ciclos no total !

Este fim de semana eu termino o projetinho, voce vai gostar de ver ele !

Valeu mesmo pela ajuda, Mestre Felipe, sem ela eu ainda não teria tido incentivo prá usar esse assembly....

Paulo