Por que os chips de relógio em tempo real usam BCD

14

Eu já vi dezenas de chips de clock em tempo real diferentes no mercado, além de vários processadores com um módulo de clock em tempo real interno, com alimentação separada.

Quase todos eles não apenas armazenam o tempo como ano-mês-dia-horas-minutos-segundos, mas mesmo os campos individuais são armazenados no BCD, e não no formato binário.

Existe alguma razão subjacente para isso?

Existem aplicativos de microprocessador que fazem algo mais sofisticado do que simplesmente exibir um relógio em que o formato BCD é mais útil que binário, ou onde o formato ano-mês-dia-hora-minutos-minutos-segundos seria mais útil do que uma contagem direta de 47 bits das mudanças de estado do oscilador?

Pelo que sei, parece que os fabricantes de RTCC adicionam muitos circuitos extras para tornar seus chips menos úteis; a única razão pela qual posso imaginar que os módulos RTCC nos processadores se comportem dessa maneira é que os fornecedores de processadores usam alguma implementação BCD pré-existente, em vez de produzirem seus próprios.

rtc supercat
fonte
2
Eu não sei a resposta, mas gostaria de saber se existe alguma correlação entre o BCD e o decodificador de 7 segmentos .
Prof. Meow Meow
@Prof. Miau miau: nome bonito. O método mais prático para armazenar números que serão exibidos no hardware é o BCD. Existem sistemas que armazenam números para serem exibidos em outros formatos, mas em muitos casos eles simplesmente usam uma ROM para mapear diretamente do número para sua representação visual (por exemplo, a máquina de fliperama "Tank" usava contadores de pontuação de 6 bits e um 512 ROM de bytes para converter cada valor de pontuação em uma forma 8x8), mas isso geralmente só é viável se o valor numérico máximo for razoavelmente pequeno.
supercat

Respostas:

12

Todos os RTCs usam codificação BCD?

Os RTCs da Philips / NXP (independentes e integrados nos chips ARM7 ou Cortex-M3) não usam codificação BCD.

O que há de errado com um BCD RTC?

Quando comparadas com o contador plano, as únicas operações mais difíceis com um relógio BCD dividido são os cálculos de diferença de tempo (adicionando segundos ou calculando o tempo decorrido). Comparações de tempo como: "o tempo atual é maior que o tempo de alarme definido pelo usuário" são igualmente fáceis.

O que há de bom nos RTCs BCD (e geralmente em campos divididos)?

Dividir os campos é muito bom quando você se importa com a data do calendário. Os calendários humanos têm coisas engraçadas, como meses de diferentes comprimentos e além desses anos bissextos. Tente fazer isso em um único contador (você pode obter um ponto de bônus por quase não usar energia). Ah, e tente apoiar os dias da semana (bastante úteis em todos os tipos de dispositivos destinados ao ser humano: de despertadores a controladores de aquecimento) com isso.

A abordagem do BCD possui um recurso adicional: você recebe "a cada segundo" ou "a cada dez segundos" gratuitamente, sem precisar fazer cálculos em horários ou datas.

Para o recorde do ano bissexto, o cálculo é um pouco complicado nos RTCs do NXP, pois ele se importa apenas com a regra divisível por 4 e não verifica a divisão entre 100 e 400. Se mantivesse o contador do ano no BCD, isso seria trivial e provavelmente bem feito.

Sumário

  1. Se você quiser um relógio monotônico, use um. Você pode comprar um PIC ou AVR com o "contador RTC" (que é apenas um contador assíncrono com um oscilador autônomo de 32kHz). Lembre-se de que simplesmente exibir a data será difícil. :)

  2. Quando você precisar exibir a hora e a data e definir alarmes com base na entrada de horas e datas pelo usuário, use um RTC. E lembre-se de que quando o usuário altera a hora e a data atuais, as interrupções baseadas no RTC podem ser imprecisas.

jpc
fonte
1
Acabei de começar a usar o Gekko, que tem um RTC de 24 bits que é quase o que eu quero, exceto que ele não aguenta o tempo em que o processador está morto. Eu também estava olhando para um ST Micro ARM, que possui um módulo BCD RTC bobo que suporta interrupções apenas em um segundo. Se o chip ST nunca ficasse sem energia por mais de três anos, eu poderia pressionar os pré-escalares do RTC para rodar na velocidade de 32x e usar truques de software para compensar, obtendo assim uma resolução de tempo de 1/32 segundos nos eventos de ativação, mas os horários armazenados no RTC não teriam uma relação significativa com o horário do calendário e ... #
307
1
... portanto, a necessidade de converter do formato bobo do RTC para incrementos de 1/32 de segundo seria irritante, especialmente porque essa conversão seria necessária em todos os ciclos de suspensão / ativação. Acho que estou curioso para saber quantas pessoas usam leituras RTCC sem converter em segundos unificados. Talvez haja o suficiente para fazer o formato YMDHMS valer a pena, mas, na minha opinião, é muito mais útil reservar o YMDHMS para E / S humana e usar segundos seguidos (ou qualquer fração dele) para todo o resto.
supercat
1
@jpc: Na verdade, minha tendência era nunca definir o horário do chip RTC, mas manter o "tempo desde que a bateria do relógio foi instalada" e armazenar a diferença entre esse e o tempo da parede. Usei essa abordagem em uma geração do produto que utilizava um PIC separado para manter o tempo de bateria (o tempo em que o PIC era somente leitura) e o usava em um chip com contador direto. Parecia uma idéia um tanto pateta, porém, fazer com que o RTC da máquina armazena um valor no formato de data sem sentido, embora se eu usar o chip ST Micro, posso fazer isso.
supercat
1
BTW, a série STM32F100 usa um RTC de 32 bits segundos (não BCD), mas a série STM32F400 regressa novamente a um RTC codificado em BCD. Suspiro.
Mark Lakata
1
@FedericoRusso: o campo Split faria algum sentido, embora seja mais provável que seja um obstáculo do que uma ajuda na maioria das aplicações. A escolha do BCD, no entanto, parece absolutamente bizarra como uma opção de empacotar com uma CPU que não tem suporte para o BCD .
supercat
3

Ao usar relógios no final, é mais provável que você se interesse por minutos e dezenas de segundos (para exibi-los) do que apenas o total de segundos, minutos e assim por diante. Caso você não esteja interessado em dígitos separados, é provável que você também não se importe com valores separados de minutos ou segundos e também use um contador binário longo, como sugeriu.
É mais fácil converter de BCD para binário em software do que o contrário. E como os contadores BCD não exigem muito espaço extra em relação aos contadores binários, faz sentido escolher o BCD.

stevenvh
fonte
2
Com que frequência um aplicativo deseja fazer nada com uma data e hora diferente de exibi-lo? Parece-me que é muito mais comum querer fazer coisas como calcular um tempo a alguma distância no futuro ou determinar quanto tempo decorreu desde algum evento em particular etc. O que é mais fácil de calcular: a data e a hora 45 segundos depois de 28 de fevereiro de 2000 23:59:52 ou 5097582 + 45 (o último valor assumindo a meia-noite de 01 de janeiro de 2000 como a época)? Que tal determinar se 5 minutos se passaram entre 28 de fevereiro de 2000 23:59 e 01 de março de 2000 00:03 (vs 5097540.0 e 5184180.0)
supercat
1
Um RTC com um contador de 48 bits por 65.536 segundos e um módulo de comparação de alarmes que cobrisse os 24 bits mais ou menos seria extremamente útil para sistemas de baixa potência, pois poderia ser usado como base para o agendamento do sistema operacional independente de processador acordando e dormindo. Se algo acontecer daqui a quatro segundos, o sistema poderá anotar o valor do RTC quando o evento ocorrer. Se daqui a dois segundos o processador não encontrar nada para fazer, poderá definir o alarme do RTC e dormir. Quando o evento ocorrer, o sistema será ativado.
supercat
@supercat - para computadores de uso geral, deixe o SO acompanhar o tempo e faça "coisas úteis" com essas informações de tempo. O RTC é consultado apenas uma vez para inicializar as informações de horário do sistema operacional e, em seguida, o horário é atualizado por interrupções. Mas, para muitos simples uso embutido, é muito mais provável que
Toybuilder
1
@ Toybuilder: Esta é exatamente a abordagem que acabei usando nas últimas gerações de bloqueio eletrônico. Meus maiores aborrecimentos foram a falta de opções de saída de pulso entre 32Khz e 16Hz (já que eu não confiava em um pull-up de 1M para operar de forma confiável com uma saída de coletor aberto de 32Khz, a única opção razoável era 16Hz) e a negligência dos PICs circuito do temporizador.
supercat
1
@FedericoRusso: Se alguém tivesse um contador de tempo binário direto, não precisaria converter de volta para horas, minutos e segundos, exceto, talvez, para exibição legível por humanos. Simplesmente adicionamos 3723 e é isso. Ao trabalhar com valores de data / hora do YMD-HMS, é necessário um código separado para aumentar e diminuir, o horário de verão é um pesadelo para o qual os fabricantes de chips parecem gostar de adicionar suporte quebrado [como um comando que subtrai um da contagem de horas, exceto quando é zero; nesse caso, não faz nada]. O horário de verão também é uma dor no binário, mas não tão hediondo.
supercat
3

Suspeito de várias razões:

Histórico - eles estão fazendo isso dessa maneira há algum tempo. Se você deseja que sua nova peça substitua outra, ela precisa mais ou menos funcionar da mesma forma. Então você continua com o BCD.

Aplicação - se alguém estiver usando um RTC de um micro pequeno (algo na faixa de 8 bits, como um PIC low-end), lidar com um grande número (como o contador de 47 bits) é uma grande dor no pescoço. É MUITO mais fácil lidar com os dígitos do BCD, pois você não precisa se esforçar para separar as coisas.

Não é tão difícil - Fazer os contadores de BCD não é tão difícil e, na verdade, acho que não há muito mais portas do que fazê-los binários.

Pode-se imaginar um sistema em que você obtenha contadores separados de hora, minuto, etc, em binário, em vez de BCD (evitando assim o problema de 'quebrar o número de 47 bits'), mas não é tão fácil assim, e você fará algumas conversões ao exibir a coisa de qualquer maneira.

Michael Kohne
fonte
1
O número de 48 bits seria um número de segundos de 32 bits e uma fração de 16 bits. Trabalhar com números de 32 bits em um micro de 8 bits não é tão ruim assim. Eu posso imaginar que, em algo como um 6502, capaz de lidar bem com o BCD compactado, o formato BCD poderia economizar alguns bytes em alguns casos, embora a complexidade adicional de manipulação de transporte entre segundos-horas-minutos compensasse qualquer vantagem. Mas certamente as pessoas que incorporaram um RTCC nos chips ARM da ST micro não esperavam que alguém usasse um 6502 para processar os dados - não com um ARM de 32 bits bem ali!
supercat
1
@ supercat - embora não seja difícil, fazer o trabalho de 32 bits no micro de 8 bits ainda é uma dor no <bleep>. E em algo como um PIC (com instruções muito limitadas, espaços de registro e memória RAM), é ainda mais difícil. Quanto ao chip ARM - aposto que isso tem mais a ver com precedentes históricos do que qualquer outra coisa - todo mundo está acostumado a fazer dessa maneira, então continua fazendo dessa maneira.
Michael Kohne
1
Gostaria de saber que fração das pessoas que usam periféricos RTCC não convertem datas / horas em contadores de segundos no estilo Unix?
supercat
1
supercat: Todos eles? De que uso são os carimbos de data e hora no estilo Unix em um relógio? OTOH, seu único caso de uso são os alarmes RTOS que são melhor atendidos com um timer normal ou com uma simples interrupção de "segundo incremento" do RTC.
JPC
1
@jpc: E se você quiser determinar se uma determinada data está no horário de verão ou se um programa que inicia em uma determinada data / hora e dura um certo período, se sobrepõe a outra? Tais coisas são fáceis com segundos seguidos, mas mais difíceis com o YMDHMS. Quanto ao uso de um timer normal, o que eu uso atualmente é um tick de 1/16 segundos de um chip RTC que conduz TMR1 e TMR3 em um PIC; isso me dá uma ativação precisa de 1/16 de segundo que funciona mesmo quando o relógio principal da CPU está parado e deduzo todo o meu tempo disso.
supercat
1

Concordo com Michael Kohne que há muito momento histórico.

Os MCUs iniciais também tinham muito menos espaço para código e dados (pense em 128 BYTES de RAM, por exemplo). Como as informações de tempo são frequentemente usadas para fins de interface com seres humanos, fazia mais sentido manter os dados mais próximos do formato usado para exibir / entrar com seres humanos.

Alguns MCUs mais novos, com mais espaço para código e dados, às vezes implementam contadores de hardware em tempo real - esses dispositivos geralmente mantêm contagens binárias de tiques de 32kHz.

Construtor de brinquedos
fonte
Eu codifiquei o Atari 2600 (128 bytes de RAM) e conheço as virtudes do BCD. Coisas como pontuações quase sempre são computadas no BCD; números de nível às vezes são. Mesmo em um 6502, porém, eu esperaria que, se precisasse determinar se duas datas / horas estavam a cinco minutos uma da outra e se o horário de verão estava em vigor, codifique para converter um contador de segundos de 32 bits em YMDHMS ser tão compacto quanto o código para fazer esses cálculos sem fazer essas conversões. Quanto às CPUs mais recentes, eu já vi algumas com contadores retos de 32Khz que exigem que a CPU principal esteja ativa ... #
31812
... mas os chips que notei que possuem um RTCC com alimentação separada usam BCD YMDHMS.
supercat
As CPUs mais recentes fazem isso porque são mais baratas e usam um pouco menos de corrente (especialmente importante porque o processo de semicondutores usado é otimizado para a fabricação de CPUs e não de RTCs).
JPC
@jpc: Por que é mais barato e de menor corrente usar o BCD YMDHMS? Eu acho que um contador de somente leitura de 47 bits com um comparador nos 32 bits inferiores seria mais simples do que todo o material de análise de datas em um chip RTC. A menos que haja algum filme mestre de um circuito de datas do BCD que, devido a alguma mágica esquecida por muito tempo esquecida, possa ser inserido em um design para obter correntes mais baixas do que as disponíveis nos métodos modernos, não sei por que o BCD seria mais barato ou usado menos atual?
supercat
Eu estava pensando na resposta do @Toybuilders, na qual ele declarou que as CPUs mais recentes têm apenas contadores e não RPCs completos.
JPC
1

Caso alguém esteja interessado, estou apenas olhando para a série 32F da ST e parece que, enquanto a série 32L mais recente usa um BCD RTC, a 32F usa um contador de 32 bits direto com prescalar configurável e fornece uma entrada de bateria separada para ele (hooray! ) Eu preferiria ter um contador mais longo sem um prescalar configurável (para obter precisão de 1 / 256seg, mas manter o tempo por anos sem ter que me preocupar com o acondicionamento), mas se eu definir a pré-escala para 1 / 64seg, o cronômetro poderá ser executado dois anos sem transbordar. Não é o ideal, mas não é tão ruim. Um pouco antiestético de que, se alguém ligar a máquina depois que ela estiver desligada por muito tempo (mais de 2,1 anos), a hora / data voltará indetectável em 2,1 anos, mas dificilmente será um grande problema (o contador tem uma bandeira de excesso, mas muitos casos que não seriam muito úteis. Se a máquina estivesse ligada por dois anos antes de ser desligada e ligada três meses depois, seria esperado que o temporizador transbordasse; a questão seria se ela havia transbordado duas vezes, e eu não conheço nenhuma bandeira para isso.

supercat
fonte
0

Maxim parece estar fazendo exatamente o que você deseja com o DS1372U . Precisa de menos de 1μA, custa 1,7 USD e está disponível (!) No DigiKey e na Mouser. O único problema é que ele não parece oferecer alarmes com mais de 1 segundo de precisão e a menor taxa de clock de saída é de $ \ aproximadamente $ 4kHz.

jpc
fonte
1
É um pouco caro e não permite ler incrementos menores que um segundo. Uma saída de 4096Hz seria agradável, embora fosse muito melhor se fosse baixa para 1/65536 de segundo e alta para 15/65536. As saídas de coletor aberto devem ser as mais baixas possíveis.
supercat