Ogni quanto devo interrogare un RTC?

11

Non ho ancora usato un RTC, quindi non sono completamente sicuro del modo "normale" di leggere un orologio in tempo reale. Ci sono alcuni approcci diversi a cui ho pensato ma speravo in qualche consiglio a riguardo.

Ecco i modi in cui ho pensato di leggere e usare il tempo finora:

Ottieni la data e l'ora all'accensione e salva su RAM, e quindi tramite l'interruzione del timer incrementa i valori della RAM ogni secondo, ecc. Il codice utilizza quindi i valori nella RAM ogni volta che è necessario conoscere la data / ora.
Tramite l'uso di un interrupt timer, interrogare RTC ogni secondo e copiare la data e l'ora ricevute nella RAM. Ancora una volta, il codice utilizza quindi i valori nella RAM ogni volta che è necessario conoscere la data / ora.
Ogni volta che devo scoprire l'ora, interrogare l'RTC e usare direttamente la sua risposta.

Quale sarebbe l'approccio migliore?

microcontroller rtc

— user9993
fonte

15

L'approccio migliore è quello che soddisfa le tue specifiche utilizzando una quantità minima di risorse. Dal momento che non conosciamo veramente le tue esigenze, "best" ha ben poco significato per noi.

— Scott Seidman,

Tutte ottime risposte Non riesco a scegliere una risposta!

— user9993

23

Vorrei usare una quarta opzione.

La maggior parte dei chip RTC ha la possibilità di emettere un impulso di 1 secondo. È necessario collegare tale impulso a un ingresso abilitato per l'interruzione sull'MCU.

Ottieni il tempo dal chip una volta all'inizio del tuo programma, e forse occasionalmente da allora in poi - forse una volta ogni ora.
Il segnale di interruzione attiva quindi una routine di interruzione nell'MCU in cui si aumenta il tempo di un secondo.

Tale disposizione offre la precisione del secondo RTC senza il sovraccarico di leggere attivamente il RTC.

— Majenko
fonte

5

Quando si utilizza questo approccio, è importante sapere quale bordo dell'orologio rappresenta un incremento e anche assicurarsi che qualsiasi lettura in corso durante quel bordo dell'orologio debba essere abbandonata.

— supercat

Oppure assicurati che la lettura venga attivata solo dall'ISR: otterrai un intervallo di un secondo per eseguire la lettura prima che venga attivato l'ISR successivo.

— Majenko,

Quando possibile, preferisco impostare gli orologi in tempo reale in modo che vengano eseguiti più velocemente di un tick al secondo e utilizzarli per il timing degli eventi per scopi generici, se la risoluzione RTC può essere impostata abbastanza bene per soddisfare le esigenze di timing degli eventi; pertanto potrebbe non esserci sempre un interruzione che si verifica su ogni tick RTC. Inoltre, quando si impostano gli allarmi, è spesso importante sapere esattamente quale sia l'ora RTC nel momento in cui l'allarme viene impostato e interrogare l'RTC per vedere se si è mosso mentre era impostato l'allarme. Non so perché i venditori di chip a 32 bit non offrano semplicemente un contatore a 47 bit con la possibilità di leggere ...

— supercat

... i 32 bit superiori o i 31 inferiori più lo stato di ingresso dell'orologio, hanno un allarme che può essere attivato e disattivato in qualsiasi momento senza ritardo di sincronizzazione e un registro di allarme che può essere scritto in qualsiasi momento quando l'allarme è spento, con semantica che si verifica l'allarme se si verifica un incremento mentre l'allarme è abilitato . Se un chip può accettare riattivazioni asincrone e il software esegue un doppio controllo del polling, se del caso, non sarebbe necessaria alcuna altra sincronizzazione hardware e il software non dovrebbe aggirare i problemi causati da altre forme di sincronizzazione hardware.

— supercat

9

3 ° e 2 ° sono più praticabili.

Il terzo approccio è quello che uso nella maggior parte dei casi. Il vantaggio è che non devo preoccuparmi del mirroring dell'RTC nella RAM. Il suo potenziale difetto è che l'interrogazione dell'RTC tramite il bus seriale introduce un ritardo. Se stai scrivendo dati una volta al secondo, questo ritardo probabilmente non importerà.

Anche il secondo approccio è buono. Il mantenimento di un orologio a specchio può comportare un errore di indicazione dell'ora, se il dispositivo è in esecuzione da molto tempo. L'orologio a specchio può allontanarsi dall'RTC. Se leggi l'RTC regolarmente, la deriva non si accumulerà.
Tuttavia, vorrei sconsigliare di fare la comunicazione seriale nella stessa routine di servizio di interruzione (ISR). Impostare un flag nell'ISR ed eseguire la comunicazione seriale in main ().

ps In tutti i casi, stavo usando DS1307.

— Nick Alexeev
fonte

6

Alcuni RTC (ad es. MC68HC68T1 [che certamente nessuno dovrebbe usare più]) interromperanno il conteggio interno quando vengono letti in modo da fornire una risposta coerente. Devono essere letti il più raramente possibile in modo da ridurre al minimo l'interruzione. Leggere da loro una volta e quindi utilizzare gli interrupt del timer per aggiornare il valore temporale memorizzato nella RAM dell'MCU.

— Ignacio Vazquez-Abrams
fonte

Tali progetti sconvolgono la mente. Avere letture che si verificano durante un incremento produce dati casuali sarebbe un problema facile da aggirare. La lettura causa la perdita dei conteggi è un problema che non può essere risolto se non accettando i conteggi persi.

— supercat

2

Apparentemente il doppio buffering è qualcosa a cui alcune persone non pensano quando progettano i loro chip.

— Ignacio Vazquez-Abrams,

Se il codice verifica durante il polling per garantire che un valore non sia cambiato, non è necessario il doppio buffering. Per un orologio in tempo reale su chip, tale polling ripetizione fino al non cambiamento funzionerà anche se un interrupt tenta di leggere l'RTC contemporaneamente al codice della linea principale. Alcuni progetti a doppio buffer rendono difficile la scrittura di codice di linea principale e di interruzione che può coesistere in modo sicuro, e non ne ho mai visto uno che considererei davvero "utile".

— supercat

5

Suppongo che l'RTC sia un chip separato con il suo cristallo o un modulo integrato con il tuo microcontrollore che ha di nuovo una sorgente di tempo separata (come un cristallo da 32 kHz) rispetto al clock principale. E l'origine temporale per RTC è più accurata di quella per il microcontrollore.

Per determinare la frequenza con cui è necessario leggere l'RTC, è necessario capire quale errore massimo può avere l'orologio principale. Ad esempio, se il cristallo principale è specificato a 20 ppm, è uguale allo 0,002%. Quindi un orologio basato solo sulla sorgente dell'orologio principale potrebbe spostarsi di 0,00002 * 3600 * 24 = 1,728 secondi al giorno.

Quindi, se leggi l'RTC solo due volte al giorno e tra un intervallo di tempo incrementato una volta al secondo e un interruzione del timer, non ti spegneresti mai più di un secondo, mai più di un secondo rispetto all'RTC che è.

Se, come ho ipotizzato in precedenza, il tuo RTC è un chip separato con il suo cristallo o un modulo integrato con il tuo microcontrollore, ciò non significa che sia corretto. Anche un RTC può avere un errore. Ad esempio, se utilizza un cristallo a 32 kHz con una tolleranza di 5 ppm (che sono leggermente più costosi di quelli a 10 ppm), potrebbe essere spento di 0,43 secondi al giorno - o 13 secondi al mese.

Per ovviare a questo, è necessario ottimizzare RTC, in cui si riscrive un fattore di correzione in un registro. Ciò ti consentirà di riportare l'errore praticamente a zero. Ma, naturalmente, si dovrà avere un terzo esterno sorgente di clock da utilizzare come riferimento quando si fa la messa a punto. Un riferimento estremamente accurato negli Stati Uniti è la linea CA a 60 Hz, che è garantita per essere esattamente 60 * 60 * 60 * 24 (5.184.000) cicli in un periodo di 24 ore tra mezzanotte successive. Affinché ciò sia utile, è necessario tempo per le 24 ore intere, poiché i 60 Hz possono spostarsi tra una mezzanotte e l'altra.

Un altro eccellente riferimento temporale sarebbe l'utilizzo del GPS (precisione di 10 ns), se uno aveva già hardware GPS nel suo progetto.

Se invece i tuoi orari RTC provengono da una fonte esterna, come l'ora della rete cellulare (AT + CCLK? Chiamata) o un server orario di rete che utilizza NTP, puoi utilizzare il valore RTC così com'è poiché non ci sarà nulla da "sintonizzare" .

— tcrosley
fonte