Precisão nas temporizações com uC

[MOR_AL]

Faço pequenos projetos com uC. Como são pequenos, geralmente uso a linguagem assembler.
Quando envolvem algum cálculo, que eu não possa escolher uma solução mais simples, uso uma linguagem de mais alto nível, que a assembler.

Já fiz um frequencímetro com a linguagem assembler, em que o período de contagem dos pulsos é de 1 segundo, tal que este período é formado por EXATOS 5.000.000 de pulsos de um clock de um cristal de 20MHz / 4 = 5MHz.

Quando uso a programação em linguagem de mais alto nível, e auxiliado pelos temporizadores internos do uC, nunca descobri um modo de obter a precisão obtida com a linguagem assembler. Tem sempre uma interrupção, que degringola a precisão da medida.
Até aí tudo bem!
Agora vem a pergunta!
Como vocês fazem para obter uma grande precisão nas temporizações usadas em seus projetos?
MOR_AL

[xultz]

Quase todos os microcontroladores deste século possuem sistema de interrupção por timer precisos. O hardware do timer recebe um clock (esse deve ser preciso, por razões óbvias), que aciona um contador, e um comparador (em hardware) compara com um valor que você define. Quando der match, ele levanta um flag de interrupção, zera o contador e o processo reinicia.
Se o flag de interrupção estiver configurado para gerar a interrupção, o código imediatamente desvia para o vetor de tratamento da interrupção, e ali dentro você faz o que tem que fazer. Só precisa tratar o evento rápido o suficiente para não gerar outra interrupção por este mesmo timer enquanto está tratando o evento.
Dessa maneira, a interrupção é gerado em intervalos de tempos precisos, o jitter entre gerar a interrupção e o código tratar é determinístico, e o processamento fica todo preciso.

[andre_luis]

Aparentemente voce está fazendo a calibração fina do tempo adicionando uma ou mais instruções na isr, se for esse o caso no C também é possível chamar instruções em assembly, ou até adicionar por exemplo uma instrução _NOP() se era esse seu caso.

[MOR_AL]

Quase todos os microcontroladores deste século possuem sistema de interrupção por timer precisos....
Dessa maneira, a interrupção é gerado em intervalos de tempos precisos, o jitter entre gerar a interrupção e o código tratar é determinístico, e o processamento fica todo preciso.

Aparentemente voce está fazendo a calibração fina do tempo adicionando uma ou mais instruções na isr, se for esse o caso no C também é possível chamar instruções em assembly, ou até adicionar por exemplo uma instrução _NOP() se era esse seu caso.

Já tentei isso, mas esbarrei em um problema.
Com PIC:
A contagem pode chegar a 40Mc/s, precisando registrar este valor em 26 bits ou 4 registradores de 8 bits.
Dois registradores encontram-se no timer 1 e o timer 2 tem dois registros, sendo que o segundo é dividido em dois. sendo assim, só dá para contar 65k. Os outros dois registradores necessários, são incrementados por software. A cada transbordo do timer (1 ou 2) deve-se incrementar o registro 3. Mas deve-se considerar a possibilidade deste registro transbordar, aí deve-se zerar o registro e incrementar o segundo. O programa nesta situação possui diversos percursos que são função do valor existente no registro 3. Claro que o problema pode ser resolvido facilmente, fazendo o que você informou. Mas você perde a precisão com o número de clocks com o desvio para a interrupção, quando ocorre o fim do período de contagem (como com um T = 1s). Você precisa parar de receber os pulsos pelo pino de entrada e passar a enviar clocks por software até chegar ao transbordo seguinte. Assim você tem o valor dos pulsos enviados por software e pode saber qual era a contagem ao final do período de contagem T.

Com AVR Atmega 328 o problema é ainda maior. Ao final do período de contagem (T), via um outro timer, você tem que saber quantos registros são salvos antes de fazer o tratamento da interrupção que gerou o fim de T. Só depois é que você pode interromper a contagem para ler o valor da contagem.

Com o pic é relativamente fácil, incluir um trecho em assembler, para garantir o período T. Já com o Atmega tem que saber quais registradores são salvos antes de iniciar o tratamento de mandar parar a contagem e ler o valor da contagem no exato momento do fim do período T.

Acho que minha explicação pode ter sido confusa, mas o problema está em conseguir criar um período de contagem T correto, poder iniciar e parar a entrada dos pulsos sincronizados com este período T.

Em tempo: Não estou recebendo e-mail informando que o tópico foi respondido.

MOR_AL

[ze]

Olá Moris
Não sei se entendi direito (se é que entendo alguma coisa, lembremos que 1.jpg>1k.txt.., publique desenhos e seus fontes se achar que deve) mas me permita observar com base em bola de cristal...

Na esmagadora maioria dos projetos a precisão dos timers é suficiente pra uso prático ou aceitável. O correto setup dos registros dos timers é independente da linguagem e obviamente atende bem as expectativas. Mas caso esteja fazendo algo cuja precisão absoluta é necessária (algo como um concorrente pra um relógio atômico ) há opções:
-não use o mc como base de tempo. Se tiver que usar:
-há o microajuste no sw como o NOP mostrado pelo amigo acima
-microajustes no hw como trimmer no cristal
-usar cristal à parte pro timer: p.ex. pic's dão esta opção pro timer1: um cristal 32768 + trimmer.

Em tempo... recentemente precisei fazer um gerador de 70Khz com um pic12f683 (o que eu tinha na reta). A 1ª coisa que pensei é ele roda a 4Mhz e dava conta só com sw. Ledo engano. Parti então pra temporização em hw de um timer. Deu na casca. Foi a conta de cair na interrupt, inverter o pino e mais naaadda. Sobram 2 ou 3 ciclos de máquina pro loop principal. Percebi que o compilador gera sim código otimizado. O problema é que ele ao entrar na int ele tem duas ou 3 funções pra guardar registros que ele julga importantes (algo como push e pop) que come boa parte do tempo. Pensei por vários minutos em fazer esta parte em asm pra otimizar ainda mais bit a bit. Neste meio tempo tempo, vi um pic10f322 a 16Mhz e dei seta pra ele. Numa análise superficial do d.s. vi que ele tem um tal de NCO (oscilador controlado numérico de tradução livre) que caiu como uma luva ao meu desafio. O bacana é que é totalmente por hw bastando escrever nuns registros que ele altera a freq. Na teoria (simulação) está funcionando legal. Freq de 25k a 72Khz com boa granulação de uns 200 ou menos herts.

Portanto fica também a dica de se dar uma olhadela do lado pra ver se tem opções diferentes. P.ex. tem mc's arm 32 bits que roda a dezenas ou centenas de Mhz com custo igual as vezes inferior ao pic e atmegas... falar que sua idade não comporta novidades não é resposta aceitável

abç e tmj... por enquanto...

[KrafT]

Eu uso o hardware de detecção de borda que salva a contagem e dispara a interrupção, então o impacto do delay do atendimento da interrupção é minimizado.

Claro que em tudo tem um jitter e para cada caso há um tratamento adequado.

Certa vez, eu colei um ímã na roda do fusca e coloquei um sensor hall para ler a velocidade do veículo, sabendo a circunferência do pneu. Foi a maior decepção da minha vida, por causa do jitter nas leituras. Desisti sem resolver.

[ze]

Desculpe minha burrice teórica... mas em que contexto o termo jitter, um ligeiro atraso que nunca fez parte do meu vocabulário prático, influenciaria em circuito relativamente simples como um frequencímetro, tacômetro, velocímetro e afins?
Me (me) parece que na prática ele é tão tão pequeno que não chega a inviabilizar ou impedir o uso de um mc simples para a aplicação supramencionada e seu tratamento me (me) parece não ser impossível. Talvez pra vc caro leitor, jitter seja algo diferente do que supõe minha vã filosofia. Se achar que deve, contextualize, explique e exemplifique pra mim... ou pro futuro.

[KrafT]

Desculpe minha burrice teórica... mas em que contexto o termo jitter, um ligeiro atraso que nunca fez parte do meu vocabulário prático, influenciaria em circuito relativamente simples como um frequencímetro, tacômetro, velocímetro e afins?
Me (me) parece que na prática ele é tão tão pequeno que não chega a inviabilizar ou impedir o uso de um mc simples para a aplicação supramencionada e seu tratamento me (me) parece não ser impossível. Talvez pra vc caro leitor, jitter seja algo diferente do que supõe minha vã filosofia. Se achar que deve, contextualize, explique e exemplifique pra mim... ou pro futuro.

Vai na mesma linha que ao transformar um número inteiro em float, você nunca mais terá o número original de volta. Quem nunca fez uma calculadora com microcontrolador em que 2+2 dá 3,9999999...?

De volta ao plano físico, todo sinal periódico tem um jitter que pode incomodar ou não. Parece que os critérios do MOR_AL são bastante exigentes e isso (o jitter) acaba sendo relevante.

Eu uso comunicação PLC (Dados sobre alimentação), no qual o formato da onda modulada é alterada pela impedância do cabo e varia com o comprimento do cabo, entre outros, o que é/são imprevisível(is). Então, como tudo na engenharia, eu tenho que aceitar uma certa variação no sinal (jitter), mas não a ponto de interpretar os dados de forma incorreta.

Edit: Na minha resposta anterior, eu me referi ao jitter causado pela leitura, não a jitter do sinal, que esse a gente (normalmente) não tem controle.

[ze]

ok.. foi uma andada meia lateral mas foi uma andada. Ainda não concebi mentalmente - ou não relacionei o rosto à pessoa - como o tal jitter poderia influenciar numa leitura de um pneu girando numa entrada de timer/contador que suporta MHz... talvez na fórmula 1 sei lá.

off
Sobre o tal plc que mencionaste (hôu mundo pequeno) permita-me mencionar/desabafar o meu "plc" 100% original. recentemente arrebentou um fio de minha campainha à uns 60m de casa. Pensei (e pesquisei) um sistema pra passar o botão da campainha pela rede ac que chega ao portão. Como mantive apenas a boa intenção, perdi o link mas era bem legal. Algo como um sinalzinho de alguns KHz somado à rede e um lm567 na recepção. Ainda em banho maria.
Mas como gosto de simplificar a vida, bolei um sistema um pouco + complexo com 1 par de fios apenas e em seu trajeto alguns sensores de presença. Com um R só em série o par alimenta todos. Cada 1 faz cair 1 pouco a tensão... algo como: o 1º cai pra 4.8, o 2º 4.6... até 4.0 que é o limite do lm317 que tem nos sensores PIR cada 1 num poste que chegam à minha varanda. Funcionou diretin na teoria: uma entrada ad de um mc avalia a queda e dá o grito(*) correspondente...
De algoritimo não muito simples pois tenho que avaliar acionamento paralelos, saber se é pessoa (lenta) ou cachorro (rápido), se está subindo, descendo e tal, ainda aguardado fds calmo pra ajustes e implementar na prática. Como viajo muito na imaginação, pretendo até mesmo fazê-lo falar(*) com um baratérrimo dfplayer mp3 mini que comprei 2 só pelo preço e ainda no plástico
É isso... teoricamente pretendo publicar minha saga neste e/ou no outro forum em que eu e Moris trocamos ideias e ideais.

[KrafT]

"Eu falo" bidirecionalmente com até 250 dispositivos em até 1500m de cabo alimentado em 24 V. É um pouco chato de fazer.

Mas sobre o tal jitter, não consigo te ajudar mais, pq não consigo entender adequadamente a tua dúvida... Assim, tem tanta coisa baratíssima que a gente não consegue reproduzir, como a já citada calculadora e um multímetro comum. A gente acaba pecando por Dunnig Kruger e achando tudo fácil e nunca é.

Esquece o termo "Jitter". Pense que se a precisão da leitura não fosse problema, o MOR_AL não abriria o tópico.

[ze]

Claro amigo. .. sem problema algum. De fato não sigo padrões de comportamento humanos digamos 'normais' e assumo a manutenção da incógnita em 100% ok?
Provavelmente não teve a intenção de me humilhar mas isso

"Eu falo" bidirecionalmente com até 250 dispositivos em até 1500m de cabo alimentado em 24 V

também me colocou no meu lugar... e eu achando que tava arrasando com um projetinho de meia dúzia de sensores em 5V a 60m...aff coisa de literal jardim de infância... ou asilo

Como o Moris não recebe notificação de resposta, penso que assim que ele passar por aqui deve te corroborar em 100% ok?
abç e fique bem.

[KrafT]

Provavelmente não teve a intenção de me humilhar mas isso

Jamais môquirido, mas como eu trabalho com cruéis restrições de custo, eu não consigo usar coisas glamorosas como Linux e plaquinhas da moda com WiFi, BLE, etc... Aí as minhas contribuições ficam sem graças

Sem contar que quem trabalha na indústria ainda tem restrições sobre PI da empresa, então tem que ser comedido e ponderar bem o que expõe.

[MOR_AL]

Ok!
1 - Antes de mais nada, deixei de receber notificações de resposta nos tópicos já há algum tempo. Por isso a demora nos retornos
2 - Levantei este tópico para obter ideia do que vocês fazem, quando precisam obter um período com boa precisão. As respostas foram esclarecedoras.
Por hardware, por assembler dentro da interrupção, por uC mais veloz...

Valeu, pessoal!
Obrigado pelas dicas.
MOR_AL