¿Por qué los chips de reloj en tiempo real usan BCD?

14

He visto docenas de diferentes chips de reloj en tiempo real en el mercado, así como varios procesadores con un módulo de reloj en tiempo real incorporado que funciona por separado.

Casi todos ellos no solo almacenan el tiempo como año-mes-día-horas-minutos-segundos, sino que incluso los campos individuales se almacenan en BCD en lugar de en formato binario.

¿Hay alguna razón subyacente para esto?

¿Hay alguna aplicación de microprocesador que haga algo más sofisticado que simplemente mostrar un reloj donde el formato BCD es más útil que el binario, o donde el formato año-mes-día-hora-minutos-segundos sería más útil que un recuento directo de 47 bits de los cambios de estado del oscilador?

Por lo que puedo decir, parece que los fabricantes de RTCC agregan muchos circuitos adicionales para que sus chips sean menos útiles; La única razón por la que puedo imaginar que los módulos RTCC en los procesadores se comporten de esa manera es que los proveedores de procesadores usan alguna implementación BCD preexistente en lugar de producir la suya propia.

rtc Super gato
fuente
2
No sé la respuesta, pero me pregunto si hay alguna correlación con BCD con el decodificador de 7 segmentos .
Prof. Meow Meow
@Profe. Miau Miau: Buen nombre. El método más práctico para almacenar números que se mostrarán en el hardware es BCD. Hay sistemas que almacenan números para mostrarlos en otros formatos, pero en muchos casos simplemente usaron una ROM para asignar directamente desde el número a su representación visual (por ejemplo, la máquina arcade "Tank" usó contadores de puntaje de 6 bits y un 512 byte ROM para convertir cada valor de puntaje a una forma de 8x8) pero esto generalmente solo funcionaba si el valor numérico máximo era bastante pequeño.
supercat

Respuestas:

12

¿Todos los RTC usan codificación BCD?

Los RTC de Philips / NXP (tanto independientes como integrados en los chips ARM7 o Cortex-M3) no usan codificación BCD.

¿Qué hay de malo con un BCD RTC?

En comparación con el contador plano, las únicas operaciones que son más difíciles con un reloj BCD dividido son los cálculos de diferencia de tiempo (agregar segundos o calcular el tiempo transcurrido). Las comparaciones de tiempo como: "es el tiempo actual mayor que el tiempo de alarma establecido por el usuario" son igual de fáciles.

¿Qué tiene de bueno los BTC (y generalmente los RTC de campo dividido)?

Dividir los campos es realmente bueno cuando te importa la fecha del calendario. Los calendarios humanos tienen cosas divertidas como meses de diferentes duraciones y además de esos años bisiestos. Intenta hacerlo en un solo contador (puedes obtener un punto de bonificación por usar casi ningún poder). Ah, e intente soportar los días de la semana (bastante útil en todo tipo de dispositivos destinados a humanos: desde despertadores hasta controladores de calentadores) con esto.

El enfoque BCD tiene una característica adicional: obtienes interrupciones "cada segundo" o "cada diez segundos" de forma gratuita, sin tener que hacer ningún cálculo de horas o fechas.

Para el cálculo del año bisiesto récord, está un poco fuera de lugar en los RTC de NXP ya que solo se preocupa por la regla divisible por 4 y no verifica la división por 100 y 400. Si mantuviera el contador del año en BCD, esto sería trivial y muy probablemente bien hecho.

Resumen

  1. Si quieres un reloj monótono, usa uno. Puede comprar un PIC o AVR con el "contador RTC" (que es solo un contador asíncrono con un oscilador autónomo de 32 kHz). Solo tenga en cuenta que simplemente mostrar la fecha será difícil. :)

  2. Cuando necesite mostrar la hora y la fecha y configurar alarmas basadas en la entrada del usuario de horas y fechas, use un RTC. Y recuerde que cuando el usuario cambia la hora y fecha actuales, sus interrupciones basadas en RTC pueden ser inexactas.

jpc
fuente
1
Acabo de comenzar a usar el Gekko, que tiene un RTC de 24 bits que es casi lo que quiero, excepto que no puede mantener la hora cuando el procesador está muerto. También estaba mirando un ST Micro ARM, que tiene un módulo BCD RTC tonto que solo admite interrupciones por un segundo. Si el chip ST nunca se quedaría sin energía durante más de tres años, podría maldecir los preescalares RTC para que funcionen a una velocidad de 32x, y luego usar trucos de software para compensar, obteniendo así una resolución de tiempo de 1/32 segundos en los eventos de activación, pero los tiempos almacenados en el RTC no tendrían una relación significativa con el tiempo del calendario y ...
supercat
1
... por lo que la necesidad de convertir del formato tonto del RTC a incrementos de 1/32 segundos sería molesto, especialmente porque tal conversión sería necesaria en cada ciclo de sueño / activación. Creo que tengo curiosidad por saber cuántas personas usan lecturas RTCC sin convertir en segundos unificados. Tal vez haya suficientes para que el formato YMDHMS valga la pena, pero en mi opinión es mucho más útil reservar YMDHMS para E / S humanas , y usar segundos seguidos (o cualquier fracción del mismo) para todo lo demás.
supercat
1
@jpc: Mi inclinación en realidad hubiera sido nunca establecer la hora del chip RTC, sino mantener el "tiempo desde que se instaló la batería del reloj" y almacenar la diferencia entre eso y la hora de la pared. Utilicé ese enfoque en una generación del producto que usaba un PIC separado para mantener el tiempo de batería (el tiempo en ese PIC era de solo lectura) y lo usaría en un chip con un contador directo. Sin embargo, parecía una idea algo tonta, hacer que el RTC de la máquina almacenara un valor con formato de fecha sin sentido, aunque si uso el chip ST Micro podría hacerlo.
supercat
1
Por cierto, la serie STM32F100 utiliza un RTC de 32 bits segundos (no BCD), pero la serie STM32F400 regresa a un RTC codificado BCD. Suspiro.
Mark Lakata
1
@FedericoRusso: el campo dividido tendría algún sentido, aunque es más probable que sea un obstáculo que una ayuda en la mayoría de las aplicaciones. Sin embargo, la elección de BCD parece francamente extraña como una opción para combinar con una CPU que no tiene soporte BCD .
supercat
3

Al usar los relojes al final, es más probable que te interesen los minutos y decenas de segundos (para mostrarlos) que solo el total de segundos, minutos, etc. En caso de que no esté interesado en dígitos separados, es probable que tampoco le interesen los valores de minutos o segundos por separado, y que también podría usar un contador binario largo como sugirió.
Es más fácil convertir de BCD a binario en software que al revés. Y dado que los contadores de BCD no requieren mucho espacio adicional sobre los contadores binarios, tiene sentido elegir BCD.

stevenvh
fuente
2
¿Con qué frecuencia una aplicación no quiere hacer nada con una fecha y hora que no sea mostrarla? Me parece que es mucho más común querer hacer cosas como calcular un tiempo a cierta distancia en el futuro, o determinar cuánto tiempo ha transcurrido desde un evento en particular, etc. Lo que es más fácil de calcular: la fecha y la hora 45 segundos después del 28 de febrero de 2000 23:59:52, o 5097582 + 45 (el último valor suponiendo la medianoche del 01 de enero de 2000 como la época)? ¿Qué tal determinar si han transcurrido 5 minutos entre el 28 de febrero de 2000 a las 23:59 y el 01 de marzo de 2000 a las 00:03 (vs 5097540.0 y 5184180.0)
Supercat
1
Un RTC con un contador de 48 bits para 65.536 de segundo y un módulo de comparación de alarmas que cubría los últimos 24 bits más o menos sería extremadamente útil para sistemas de baja potencia, ya que podría usarse como base para la programación del sistema operativo independiente de procesador despierto y durmiendo. Si se supone que algo sucederá dentro de 4 segundos, el sistema podría observar el valor RTC cuando debería ocurrir el evento. Si dentro de 2 segundos el procesador se encuentra sin nada que hacer, podría configurar la alarma RTC e irse a dormir. Cuando se produzca el evento, el sistema se activará.
supercat
@supercat: para computadoras de uso general, deje que el sistema operativo controle el tiempo y haga "cosas útiles" con esa información de tiempo. El RTC solo se consulta una vez para inicializar la información de tiempo del sistema operativo, y luego el tiempo se actualiza por interrupciones. Pero para muchos usos integrados simples, es mucho más probable que
Toybuilder
1
@Toybuilder: este último es exactamente el enfoque que terminé usando en las últimas generaciones de bloqueo electrónico. Mis mayores molestias fueron la falta de opciones de salida de pulso entre 32Khz y 16Hz (ya que no confiaba en un pullup de 1M para operar de manera confiable con una salida de colector abierto de 32Khz, la única opción razonable era 16Hz), y la descuido de los PIC. temporizador de circuitos.
supercat
1
@FedericoRusso: Si uno tuviera un contador de tiempo binario directo, no tendría que volver a convertirlo en horas, minutos y segundos, excepto tal vez para una pantalla legible para humanos. Uno simplemente agrega 3723 y eso es todo. Cuando se trabaja con valores de fecha / hora YMD-HMS, se necesita un código separado para aumentar y disminuir, el horario de verano es una pesadilla para la que los fabricantes de chips parecen agregar soporte roto [como un comando que resta uno del conteo de horas, excepto cuando es cero, en cuyo caso no hace nada]. El horario de verano también es un dolor en binario, pero no tan horrible.
supercat
3

Sospecho varias razones:

Histórico: lo han estado haciendo de esta manera desde hace algún tiempo. Si desea que su nueva parte reemplace a otra parte, entonces tiene que funcionar más o menos igual. Así que sigue con el BCD.

Aplicación: si alguien está usando un RTC de un micro pequeño (algo en el rango de 8 bits, como un PIC de gama baja), entonces lidiar con un gran número (como su contador de 47 bits) es un gran dolor en el cuello. Es MUCHO más fácil lidiar con los dígitos BCD, ya que no tiene que trabajar para dividir las cosas.

No es tan difícil: hacer los contadores de BCD no es tan difícil, y de hecho creo que no son muchas más puertas que hacerlos binarios.

Uno puede imaginar un sistema en el que obtenga contadores de horas, minutos, etc. por separado en binario en lugar de BCD (evitando así el problema de 'descomponer el número de 47 bits'), pero no es mucho más fácil, y va a hacer algunos conversiones al mostrar la cosa de todos modos.

Michael Kohne
fuente
1
El número de 48 bits sería un número de segundos de 32 bits y una fracción de 16 bits. Trabajar con números de 32 bits en un micro de 8 bits no es tan malo. Me imagino que en algo como un 6502 que podría manejar bien el BCD empaquetado, el formato BCD podría ahorrar unos pocos bytes en algunos casos, aunque la complejidad adicional de manejar el transporte entre segundos-horas-minutos compensaría cualquier ventaja. Pero seguramente las personas que construyeron un RTCC en los chips ARM de ST micro no esperaban que alguien usara un 6502 para procesar los datos, ¡no con un ARM de 32 bits allí mismo!
supercat
1
@supercat: aunque no es difícil, hacer el trabajo de 32 bits en el micro de 8 bits sigue siendo un dolor en el <bleep>. Y en algo como un PIC (con instrucción MUY limitada y espacios de registro y ram) es aún más doloroso. En cuanto al chip ARM, apuesto a que tiene más que ver con el precedente histórico que cualquier otra cosa, todos están acostumbrados a hacerlo de esa manera, por lo que siguen haciéndolo de esa manera.
Michael Kohne
1
Me pregunto qué fracción de las personas que usan periféricos RTCC no convierten fechas / horas en contadores de segundos estilo Unix.
supercat
1
supercat: ¿todos ellos? ¿De qué sirven las marcas de tiempo estilo Unix en un reloj? OTOH, su único caso de uso son las alarmas RTOS que funcionan mejor con un temporizador normal o con una simple interrupción de "segundo incremento" del RTC.
jpc
1
@jpc: ¿Qué sucede si desea determinar si una fecha determinada se encuentra en el horario de verano o si un programa que se inicia en una fecha / hora determinada y dura cierta duración se superpondrá a otra? Tales cosas son fáciles con segundos seguidos, pero más difíciles con YMDHMS. En cuanto a usar un temporizador normal, lo que uso actualmente es un tic de 1/16 segundos de un chip RTC que maneja TMR1 y TMR3 en un PIC; eso me da una activación precisa de 1/16 de segundo que funciona incluso cuando el reloj principal de la CPU está parado, y deduzco todo mi tiempo de eso.
supercat
1

Estoy de acuerdo con Michael Kohne en que hay mucho impulso histórico.

Los primeros MCU también tenían mucho menos espacio para el código y los datos (piense en 128 BYTES de RAM, por ejemplo). Dado que la información de tiempo a menudo se usa para fines de interfaz humana, tenía más sentido mantener los datos más cercanos al formato utilizado para mostrar / ingresar desde humanos.

Algunas MCU más nuevas con más código y espacio de datos a veces implementan contadores de hardware en tiempo real; estos dispositivos a menudo mantienen conteos binarios de tics de 32 kHz.

Constructor de juguetes
fuente
He codificado para el Atari 2600 (128 bytes de RAM), y sé las virtudes de BCD. Cosas como las puntuaciones casi siempre se calculan en BCD; los números de nivel a veces lo son. Sin embargo, incluso en un 6502, esperaría que si tuviera que determinar si dos fechas / horas estaban dentro de cinco minutos una de la otra y determinar si el horario de verano estaba vigente, el código para convertir un contador de segundos de 32 bits en YMDHMS ser tan compacto como el código para hacer esos cálculos sin hacer tales conversiones. En cuanto a las CPU más nuevas, he visto algunas con contadores directos de 32Khz que requieren que la CPU principal esté viva ...
supercat
... pero los chips que he notado que tienen un RTCC alimentado por separado usan BCD YMDHMS.
supercat
Las CPU más nuevas hacen esto ya que es más barato y usa un poco menos de corriente (especialmente importante ya que el proceso de semiconductores utilizado está optimizado para hacer CPU y no RTC).
jpc
@jpc: ¿Por qué es más barato y de menor corriente usar BCD YMDHMS? Creo que un contador de solo lectura de 47 bits con un comparador en los 32 bits inferiores sería más simple que todo el análisis de fechas en un chip RTC. A menos que haya alguna película maestra de un circuito de fecha BCD que, debido a una magia arcana olvidada durante mucho tiempo, pueda desplegarse en un diseño para lograr corrientes más bajas que las disponibles con los métodos modernos, no estoy claro por qué BCD sería más barato o usaría menos actual?
supercat
Estaba pensando en la respuesta de @Toybuilders en la que afirmó que las CPU más nuevas solo tienen contadores y no RPC en toda regla.
jpc
1

En caso de que alguien esté interesado, solo estoy mirando la serie 32F de ST y parece que si bien la serie 32L más nueva usa un BCD RTC, el 32F usa un contador directo de 32 bits con preescalar configurable y proporciona una entrada de batería por separado (¡hurra! ) Preferiría tener un contador directo más largo sin un preescalar configurable (para poder obtener una precisión de 1 / 256seg pero mantener el tiempo durante años sin tener que preocuparme por el ajuste), pero si tuviera que configurar la preescala para 1 / 64sec, el temporizador podría funcionar Dos años sin desbordarse. No es ideal, pero no está mal. Un poco poco estético que si alguien enciende la máquina después de que ha estado apagada durante demasiado tiempo (más de 2.1 años), la hora / fecha se reduciría de forma indetectable en 2.1 años, pero no es un gran problema (el contador tiene un indicador de desbordamiento, pero en muchos casos que no serían de gran ayuda. Si la máquina estuvo encendida durante dos años antes de apagarse y se encendió tres meses después, se esperaría que el temporizador se desbordara; la pregunta sería si se había desbordado dos veces, y no conozco ninguna bandera para eso.

Super gato
fuente
0

Maxim parece estar haciendo exactamente lo que quiere con DS1372U . Necesita menos de 1 μA, cuesta 1.7 USD y está disponible (!) En DigiKey y Mouser. El único problema es que no parece ofrecer alarmas con más de 1 segundo de precisión y la frecuencia de reloj de salida más baja es de $ \ aproximadamente $ 4kHz.

jpc
fuente
1
Es un poco caro y no permite leer incrementos menores de un segundo. Una salida de 4096Hz sería buena, aunque sería mucho mejor si fuera baja durante 1/65536 de segundo y alta para 15/65536. Las salidas de colector abierto deben ser lo más bajas posible.
supercat