¿Todos los RTC utilizan 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é pasa 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 (sumar segundos o calcular el tiempo transcurrido). Las comparaciones de tiempo como: "es la hora actual mayor que la hora de alarma establecida por el usuario" son igual de sencillas.

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

Es muy agradable dividir los campos cuando cuidas la fecha del calendario. Los calendarios humanos tienen cosas divertidas como meses de diferentes longitudes y además de esos años bisiestos. Intente hacer eso en un solo contador (puede obtener un punto de bonificación por no usar casi ninguna potencia). Ah, y trate de admitir los días de la semana (bastante útil en todo tipo de dispositivos destinados a personas: desde relojes de alarma hasta controladores de calefacción) con esto.

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

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

Resumen

1. Si desea un reloj monotónico, use 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 ten en cuenta que simplemente mostrar la fecha será difícil. :)

2. Cuando necesite visualizar la hora y la fecha y configurar alarmas en función de las entradas y horas del usuario, utilice un RTC. Y recuerde que cuando el usuario cambia la hora y fecha actuales, sus interrupciones basadas en RTC pueden ser inexactas.

Al usar relojes al final, es más probable que esté interesado en minutos y decenas de segundos (para mostrarlos) que solo en 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 separados, 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 como los contadores BCD no requieren mucho espacio extra sobre los contadores binarios, tiene sentido elegir BCD.

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 mantente 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), tratar con un número grande (como su contador de 47 bits) es un gran problema. 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 hay muchas más puertas que hacerlas en modo binario.

Uno puede imaginar un sistema en el que obtenga contadores de horas, minutos, etc. separados 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 ya está para hacer algunas conversiones al mostrar la cosa de todos modos.

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

Los MCU tempranos 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 se usa a menudo con fines de interfaz humana, tenía más sentido mantener los datos más cercanos al formato utilizado para mostrar / recibir información de los humanos.

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

En el caso de que alguien esté interesado, solo observo la serie 32F de ST y parece que mientras la nueva serie 32L usa un RCD BCD, la 32F usa un contador directo de 32 bits con preclase configurable y proporciona una entrada de batería por separado. (¡hurra!). Preferiría tener un contador directo más largo sin un prealar 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 establecer la escala de preaviso de 1/64 s, el temporizador podría funcionar Dos años sin rebosar. No es ideal, pero no está tan mal. Es un poco poco estético que si alguien enciende la máquina después de haber estado apagada durante más tiempo (más de 2.1 años), la fecha / hora se deslizaría de manera indetectable en 2.1 años, pero difícilmente un problema importante (el contador tiene una bandera de desbordamiento, pero en muchos casos no serían muy útiles. Si la máquina estuviera 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 sé de ninguna bandera para eso.

Maxim parece estar haciendo lo que quieres 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 una precisión de más de 1 segundo y la velocidad de reloj de salida más baja es de $ \ aproximadamente $ 4kHz.