¿Con qué frecuencia debo consultar un RTC?

11

Todavía no he usado un RTC, así que no estoy completamente seguro de la forma "normal" de leer un reloj en tiempo real. Hay algunos enfoques diferentes en los que he pensado pero esperaba algún consejo al respecto.

Estas son las formas en que he pensado leer y usar el tiempo hasta ahora:

Obtenga la fecha y la hora al encender y guarde en la RAM, y luego, mediante el uso de la interrupción del temporizador, incremente los valores de RAM cada segundo, etc. El código luego usaría los valores en la RAM cada vez que fuera necesario para conocer la fecha / hora.
Mediante el uso de una interrupción del temporizador, consulte el RTC cada segundo y copie la fecha y hora recibidas en la RAM. Una vez más, el código usaría los valores en RAM siempre que fuera necesario para conocer la fecha / hora.
Cada vez que necesite averiguar el tiempo, consulte el RTC y use su respuesta directamente.

¿Cuál sería el mejor enfoque?

microcontroller rtc

— usuario9993
fuente

15

El mejor enfoque es el que cumpla con sus especificaciones mientras usa una cantidad mínima de recursos. Como realmente no conocemos sus necesidades, "mejor" tiene muy poco significado para nosotros.

— Scott Seidman

Todas muy buenas respuestas ¡No puedo elegir una respuesta!

— user9993

23

Yo usaría una cuarta opción.

La mayoría de los chips RTC tienen la opción de emitir un pulso de 1 segundo. Debe conectar ese pulso a una entrada habilitada para interrupción en su MCU.

Obtiene el tiempo del chip una vez al comienzo de su programa, y tal vez ocasionalmente a partir de entonces, tal vez una vez por hora.
Luego, la señal de interrupción activa una rutina de interrupción en su MCU en la que incrementa el tiempo en un segundo.

Esa disposición le brinda la precisión al segundo del RTC sin la sobrecarga de leer activamente el RTC.

— Majenko
fuente

55

Cuando se usa este enfoque, es importante saber qué borde del reloj representa un incremento y también asegurarse de que cualquier lectura que esté en progreso durante ese borde del reloj se deba abandonar.

— supercat

O asegúrese de que la lectura solo sea activada por el ISR: obtendrá un espacio de un segundo para hacer la lectura antes de que se active el próximo ISR.

— Majenko

Siempre que sea posible, prefiero configurar los relojes en tiempo real para que se ejecuten más rápido que un tic por segundo y usarlos para la sincronización de eventos de propósito general, si la resolución RTC se puede configurar lo suficientemente bien como para satisfacer las necesidades de sincronización de eventos; por lo tanto, no siempre se produce una interrupción en cada marca RTC. Además, cuando se configuran las alarmas, a menudo es importante saber exactamente cuál es la hora del RTC en el momento en que se configura la alarma, y sondear el RTC para ver si se movió mientras se configuraba la alarma. No sé por qué los vendedores de chips de 32 bits no ofrecen simplemente un contador de 47 bits con la capacidad de leer ...

— supercat

... los 32 bits superiores o los 31 inferiores más el estado de entrada del reloj, tienen una alarma que puede encenderse y apagarse en cualquier momento sin demora de sincronización, y un registro de alarma que puede escribirse en cualquier momento cuando se activa la alarma apagado, con la semántica de que la alarma se produce si se produce un incremento mientras la alarma está habilitada . Si un chip puede aceptar activaciones asincrónicas y el software realiza una doble verificación de sondeo cuando sea apropiado, no se requerirá ninguna otra sincronización de hardware, y el software no tendría que solucionar problemas causados por otras formas de sincronización de hardware.

— supercat

9

3ro y 2do son más viables.

El tercer enfoque es lo que uso en la mayoría de los casos. Su beneficio es que no necesito preocuparme por reflejar el RTC en la RAM. Su posible inconveniente es que interrogar al RTC a través del bus serie introduce un retraso. Si está escribiendo datos una vez por segundo, este retraso probablemente no importará.

El segundo enfoque también es bueno. Mantener un reloj espejo puede introducir un error de cronometraje, si el dispositivo está funcionando durante mucho tiempo. El reloj del espejo puede separarse del RTC. Si lee el RTC regularmente, la deriva no se acumulará.
Sin embargo, aconsejaría que no se hiciera una comunicación en serie en la rutina del servicio de interrupción (ISR). Establezca una bandera en el ISR y realice la comunicación en serie en el main ().

ps En todos los casos, estaba usando DS1307.

— Nick Alexeev
fuente

6

Algunos RTC (p. Ej., MC68HC68T1 [que ciertamente ya casi nadie debería usar]) pausarán su conteo interno cuando se lean para dar una respuesta consistente. Deben leerse tan raramente como sea posible para minimizar la interrupción. Lea de ellos una vez y luego use las interrupciones del temporizador para actualizar el valor de tiempo almacenado en la RAM de la MCU.

— Ignacio Vazquez-Abrams
fuente

Tales diseños aturden la mente. Tener lecturas que ocurren durante un incremento de rendimiento de datos aleatorios sería un problema fácil de solucionar. Tener lecturas hace que se pierdan los recuentos es un problema que no se puede solucionar, excepto aceptar los recuentos perdidos.

— supercat

2

Aparentemente, el doble buffer es algo en lo que algunas personas no piensan cuando diseñan sus chips.

— Ignacio Vazquez-Abrams

Si el código verifica al sondear para garantizar que un valor no ha cambiado, no hay necesidad de doble almacenamiento en búfer. Para un reloj en tiempo real en el chip, este sondeo de repetición hasta que no cambie funcionará incluso si una interrupción intenta leer el RTC al mismo tiempo que lo hace el código de la línea principal. Algunos diseños de doble búfer hacen que sea difícil escribir código de línea principal e interrupción que pueda coexistir de manera segura, y nunca he visto uno que realmente considere "útil".

— supercat

5

Asumiré que el RTC es un chip separado con su propio cristal, o un módulo integrado con su microcontrolador que nuevamente tiene una fuente de tiempo separada (como un cristal de 32 kHz) que el reloj principal. Y la fuente de tiempo para el RTC es más precisa que la del microcontrolador.

Para determinar con qué frecuencia necesita leer el RTC, debe averiguar cuál es el error máximo que puede tener su reloj principal. Por ejemplo, si el cristal principal se especifica a 20 ppm, eso es lo mismo que 0.002%. Por lo tanto, un reloj basado únicamente en la fuente del reloj principal podría derivar 0.00002 * 3600 * 24 = 1.728 segundos al día.

Entonces, si lee el RTC solo dos veces al día, y en el medio incrementa el tiempo una vez por segundo usando una interrupción del temporizador, nunca estaría apagado más de un segundo, nunca estará apagado más de un segundo en comparación con el RTC que es.

Si, como supuse anteriormente, su RTC es un chip separado con su propio cristal o un módulo integrado con su microcontrolador, eso no significa que sea correcto. Un RTC también puede tener un error. Por ejemplo, si está utilizando un cristal de 32 kHz con una tolerancia de 5 ppm (que son un poco más caras que las de 10 ppm), podría estar apagado en 0,43 segundos por día, o 13 segundos por mes.

Para evitar esto, deberá ajustar el RTC, donde debe escribir un factor de corrección en un registro. Hacerlo te permitirá llevar el error prácticamente a cero. Pero, por supuesto, tendrá que tener una tercera fuente de reloj externa para usar como referencia cuando realice la sintonización. Una referencia extremadamente precisa en los EE. UU. Es la línea de CA de 60 Hz, que se garantiza que será exactamente 60 * 60 * 60 * 24 (5,184,000) ciclos en un período de 24 horas entre sucesivas noches de medianoche. Para que esto sea útil, debe tomarse el tiempo durante las 24 horas completas, ya que los 60 Hz pueden variar entre la medianoche.

Otra excelente referencia de tiempo sería usar GPS (precisión de 10 ns), si uno ya tuviera hardware de GPS en su proyecto.

Si, en cambio, sus tiempos de RTC provienen de una fuente externa, como la hora de la red celular (llamada AT + CCLK?) O un servidor de tiempo de la red que usa NTP, entonces puede usar el valor de RTC tal como está ya que no habrá nada que "ajustar" .

— tcrosley
fuente