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.

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.

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.

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.

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.

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.

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.