ASM51

Pessoal, eu estou fazendo um relógio, sim é isso mesmo um relógio que marca Horas e Minutos.

Porém não quero utilizar esses chips do tipo timer counter, tipo 1307 da vida, eu quero fazer tudo na mão mesmo. O motivo é custo, final!

Já implementei as rotinas e estou utilizando como fonte de clock uma rotina DDS e o clock eu pego o da própria CPU (pic16f887a).

Porém tenho notado que há um erro na contagem dos segundos, esta adiantando em 4 segundos, num periodo de 24horas, estou pegando como base o relógio do PC para fazer essa comparação.

Eu estou um tanto admirado, porque o DDS é muito preciso, pelos menos em frequencias acima de 100hz...será que o DDS é o culpado desse erro?

Se vocês, puderem me ajudar indicando uma forma de ter uma fonte de clock precisa, por favor...abaixo segue minha rotina DDS:

inicialização:

cpp code

#define HZ 4000000   
   #define TOGGLE (((HZ * 5) / 1) * 5)   

 // long 32bits:
   volatile unsigned long accum_01, accum_02;
   volatile unsigned long noteon, freqhz_01, freqhz_02;

  T2CON = 0b00000100;                         
   PR2 = (100-1);                               
   INTCON = 0b11000000;                        
   PIE1.TMR2IE = 1;                             
   freqhz_01 = 20000;                           // BASE DE TEMPO 1 HZ = 0,5 nível 1 e 0,5 nível 0.
   freqhz_02 = 20000;                          
   accum_01 = 0;
   accum_02 = 0;

/***********************************************
 ROTINA DE INTERRUPÇÕES
************************************************/
void interrupt()
     { //Vetor de interrupção , endereço 04h de memória
      PIR1.TMR2IF = 0;            
      accum_01 += freqhz_01;      
     accum_02 += freqhz_02;
                          /* OSCILADOR DDS: */
     if(accum_01 >= TOGGLE)
     {
      accum_01 -= TOGGLE;    
         pisca=~pisca;
            if(pisca==0) {if(segundos==60) {segundos=0; if(minuto==59) {minuto=0; if(hora==23) hora=0; else hora++;} else minuto++;} segundos++;}
    }
}

Então, agora que fui "pensar", o óbvio, fui verificar no osciloscópio a base de tempo que estou gerando, através de um pino de saida do pic que esta ligado na interrupção.

Verifiquei que a marcação de tempo esta hiper precisa, ou seja 1 segundo.

Agora fiquei na dúvida: Será que eu errei alguma coisa na rotina do temporizador DDS? Ou será que o relógio do PC daria todo esse erro?....afi,

Geralmente as rotinas para este implemento são feitas em ASM,deste modo o tempo que leva as instruções são calculadas uma por uma

Qual é o crystal que está utilizando como gerador de clock?

Eu não gastaria os meus cabelos restantes tentando reinventar a roda, pra isso já existem os RTCs prontos, inclusive os de melhor qualidade contém as necessárias compensações térmicas e de carga do crystal.

Se tu quer gerar a referência do relógio a partir do crystal do uC vai penar para acertar os capacitores e, no caso de produção, vai ser difícil garantir que os lotes tenham precisão.

Segundos em 24 horas = 24 horas /dia x 60 minutos / hora x 60 segundos / minuto = 86.400 SEGUNDOS / DIA (observar a simplificação das unidades).
Erro de 4 segundos / dia.
Erro relativo = (4 segundos / dia) / 86.400 segundos / dia = 4,6296 E-5 (adimensional), ou seja 1 em 21.600.
Se você estiver usando um cristal normal, o erro pode se encontrar dentro do esperado.

Fiz um frequencímetro (em asm), que no circuito consegui alterar, muito pouco, a frequência de oscilação do cristal. Mas é um "cobertor de pobre". Quanto mais for o desvio, mais instável fica o oscilador, chegando mesmo a deixar de oscilar.
Talvez, seu erro possa ser reduzido, mas você só saberá, se comparar a oscilação de seu cristal com a oscilação de um equipamento sabidamente com maior precisão.
Se quiser maior precisão, além de ter um cristal mais preciso, é necessário mante-lo funcionando à uma pequena faixa de temperatura.
MOR_AL

Eu agradeço as informações de todos,

A frequencia do cristal é 4mhz,

Eu já utilizei um lm1307 para o relógio, e confesso que fiquei um tanto descepcionado, pois em algumas unidades há atrasos ou adiantamentos, é pouca coisa, tipo 1, 2 ou até 5 segundos em 24horas...não entendi o do porque, e pesquisando notei que algumas outras pessoas relataram isso também.

Eu retestei o DDS, alocando outras frequencias e a precisão é muito boa, chegando a ótima, com erro de infímo.

Mas estou começando a entender que o problema pode mesmo ser o cristal, apesar do desvio ser muito pequeno, isso ainda considerando que a divisão é de 20.000 para 1,

Doidera,

Eu vou deixar na placa o velho e bom sinal de 60hz da rede elétrica...

Guri escreveu:Eu agradeço as informações de todos,

...
Eu vou deixar na placa o velho e bom sinal de 60hz da rede elétrica...

É, mas e se houver interrupção na rede? Mesmo se for pequena, vai afetar na precisão.
MOR_AL

O erro de um cristal é na base de 20ppm (1/50.000), o que no universo de um dia (86.400s) dá cerca de 1,7s. Repare entretanto que a rotina de recarga do timer dentro da interrupção demora adiciona um atrazo de umas poucas instruções, e portanto implementar um RTC desse modo não é preciso, a menos que seu uC possua algum mecanismo de recarga automatica do Timer.

Então, cheguei a essa mesma conclusão, depois de testar cuidadosamente na prática e fazendo medições com o osciloscópio.

Realmente, se ouver desvio do cristal o erro será desanimador no contador de tempo, quer seja DDS, ou o próprio TIMR e isso é acumulativo.

Os melhores resultados foram com um cristal de quartzo, isso porque utilizei um ressonador cerãmico, onde os erros foram maiores.

O interessante e que eu ainda não compreendi, foi porque sendo o DDS muito preciso, apresentar o erro, penso isso devido ao número de divisão elevadissímo. É porque eu uso DDS para gerar frequencias na faixa de audio em um ARM STM e também num DSPIC e a precisão é ótima...

Mas pensem aqui comigo, no DDS existe um erro de defasagem conhecido como jiter, será que esse erro é ampliado e consequentemente reflete-se numa divisão tão alta como é o caso de 1hz, se bem que o jiter diminui quanto maior for o número de divisão...

Bom, nos testes, que fiz, notei que se a frequencia for exatamente 4mhz, o erro é zero, considerando o calculo inicial do DDS para f=4mhz...caso haja desvio para cima ou para baixo no cristal, isso reflete consideravelmente acumulando o erro no time de divisão final.

Eu conclui que se você uitlizar o TMR1 com um cristal de 32.768hz, o erro é muito pequeno, chegando a ser aceitável...

Fazendo aqui uma correção: Eu havia feito alguns testes com o DS1307, e notei erros também, porém notei que a minha rotina tinha um erro "besta" de temporização, após ter concertado esse erro, o time ds1307 ficou redondo...

Eu então sugiro utilizar um timer kiper para relógios, quer seja externo como o ds1307 ou interno...

Agradeço a ajuda de todos, aprendi muito com vocês, obrigado

Uma pergunta ou dúvida que tenho a muito tempo...

Porque os fabricantes de UC de 8 bits, usam timers com recarga via software, ao invés de utilizar recarga "autoreload"...a recarga via software produz erros de quantização. Já a recarga "autoreload" não esse erro, porque isso é feito por hardware.

Já chips como ARM e maioria que tenho visto de 32 bits, já possuem autoreload por hardware.

Será que adotaram isso de recarga via software, só para complicar o que funciona tão bem que é o autoreload?

Enfim, poderiam antes de criar a arquitetura de um chip microcontrolador de 8 bits, "olhar" para esse detalhe que faz toda diferença num projeto onde precisão do tmr é importante.

Doidera,

Se basear na estabilidade de um DS1307 é ruim hein?!! Este RTC é antigo e muito instável (em relação a outros mais novos)

Se consegue avaliar com precisão o que está ganhando ou perdendo num dado período poderia implementar uma compensação, mas a coisa não funciona assim, o ganho ou perda varia...

Eliminando todos os eventuais erros de programação, com a variação de temperatura haveria variação na contagem de tempo, pois o sistema de clock não possui compensação.

Caso precise de uma contagem de tempo estável a solução é um DS3231 ou outros similares que possuem compensação de temperatura e garantem uma estabilidade de +/- 2 ppm 0-40C (isso dá 1 segundo a cada 5,78 dias).

No frequencímetro que fiz, com PIC16F628A e um cristal de 20MHz, consegui, à temperatura ambiente fixa, a precisão de 1 em 1 milhão.
Abaixo segue o link do vídeo.
https://www.youtube.com/watch?v=3aIugpKWxVg

Primeiro gerei (em assembler) uma janela de leitura precisa (Ton) para a contagem dos pulsos de entrada. Essa janela tem exatos 5.000.000 de pulsos de clock. No instante 1m19s eu mostro o valor do número de clocks contados dentro desta janela (Ton).

Depois gero a frequência de 1.000.000 Hz no PIC e aplico ao frequencímetro comercial. Foi o instrumento mais preciso que eu possuía. Essa frequência é gerada com base no cristal do PIC. Acrescentei um ajuste na frequência de oscilação desse cristal. Vide o instante 2m20s. Claro que a faixa de ajuste é muito pequena, mas foi possível fazê-lo. Cerca de 3Hz em 1MHz.
Com isso garantia que o período Ton tivesse 5.000.000 de pulsos e cada um com 200ns.

Não fiz um circuito para manter a temperatura no cristal constante, consequentemente, certamente deve haver variação na frequência de oscilação do cristal.
O que eu quero dizer, é que com um simples cristal pode-se obter boa precisão de oscilação. Mas nesse ajuste é imperativo se dispor de um equipamento sabidamente com melhor precisão. A precisão de frequência obtida no osciloscópio (ou qualquer equipamento) é função do número de dígitos corretos que ele pode oferecer.

MOR_AL

Olá MOR_AL.


Parabéns pelo ótimo trabalho, ficou muito bem elaborado e planejado.

Eu entendi o que quis dizer e agraço pelas informações preciosas.

Então brasilma, sua dica é muito boa, vou dar uma olhada nesse chip que você deu a dica, obrigado.

Como eu tinha uma velha placa de um alarme "MALUCO" que fabricava a uns anos atrás, resolvi usar ela nos testes,

Nela há um DS1307, que no projeto original era tudo em assembler, até eu me apaixonar por linguagem C

Bom fiz tudo em C, o erro, existe no DS1307, mas é aceitável do ponto de vista que eu estou planejando usar, é bem menor que com o uso do cristal fazendo tudo na unha.

Ele apresenta horas e minutos, alternadamente mostra a temperatura até 0~99 graus e tem uma função secundária que aciona um relé em tempos determinados durante a noite para simular presença no ambiênte.
Agora vou partir para um painel de mensagens e vou usar o o chip que o brasilma indicou...depois posto os resultados:
NOTA: estou fazendo isso apenas como hobby, minha diversão no trabalho é mexer com eletrônica e nas horas de folga, o hoby principal é eletrônica kkk

Segue o video:

https://www.youtube.com/watch?v=FPlObEO ... e=youtu.be

[quote="Guri"]Olá MOR_AL.


Parabéns pelo ótimo trabalho, ficou muito bem elaborado e planejado.

Eu entendi o que quis dizer e agraço pelas informações preciosas.

Então brasilma, sua dica é muito boa, vou dar uma olhada nesse chip que você deu a dica, obrigado.

Como eu tinha uma velha placa de um alarme "MALUCO" que fabricava a uns anos atrás, resolvi usar ela nos testes,

Nela há um DS1307, que no projeto original era tudo em assembler, até eu me apaixonar por linguagem C

Bom fiz tudo em C, o erro, existe no DS1307, mas é aceitável do ponto de vista que eu estou planejando usar, é bem menor que com o uso do cristal fazendo tudo na unha.

Oi Vonillmann::setNewName(Guri);

É alarmantemente inocente da sua parte querer ver um erro de alguns segundos em 24 horas num osciloscópio, assim como o é achar que um chip tipo DS1307 resolve magicamente os problemas do cristal. O DS1307 ou equivalente vai sofrer os mesmos desvios que teu processador, para um dado cristal.

Você tem alguma opções (algumas já sugeridas pelos colegas):
- Usar a rede CA quando disponível, como você mesmo sugeriu, e nas eventuais faltas dele rodar com uma base de tempo do cristal do processador;
- Usar um caro TXCO ou OCXO, que você já restringiu pelo custo;
- Usar um NTP, mas também é caro e nem sempre se tem acesso à rede;
- Usar o sensor de temperatura externo ou interno do mcu e tentar compensar o desvio do cristal por software;
- Permitir parametrizar a correção do desvio, depois de montado o produto (algo que o antigo trimmer fazia por hardware);
- Orar para deus te dar um cristal 100% preciso.

E por aí vai. Lembre-se que a engenharia é a ciência do suficiente, na impossibilidade do absoluto.