Come installare Real Time Clock (RTC) su Raspbian?

Io ho:

• Raspberry Pi con 2015-05-05-raspbian-wheezy
• ds1307 allegato (è una scheda Adafruit, resistori pullup non installati).

Come posso:

• configurare i driver
• assicurarsi che il Pi utilizzi effettivamente l'ora RTC all'avvio?

In realtà ho fatto la prima parte, per quanto posso dire, ma senza fortuna con la seconda. Molte delle informazioni disponibili, comprese le istruzioni di Adafruit, sono obsolete a causa di ciò: https://www.raspberrypi.org/forums/viewtopic.php?t=97314

Quindi, primo passo: abiliti I2c e driver in raspi-config, aggiungi dtoverlay=i2c-rtc,ds1307alla fine di /boot/config.txt, e hai i driver e hwclockfunziona per me ora, a quanto pare (non è possibile eseguire i2cdetect, altro più avanti).

Ora è necessario rimuovere fake-hwclock e configurarlo in modo che legga effettivamente l'RTC all'avvio. Ho cercato di seguire questo consiglio - che è in gran parte in accordo con altre cose che ho visto ed è molto recente - https://www.raspberrypi.org/forums/viewtopic.php?p=842661#p842661

(vale per un diverso RTC, ma sto solo seguendo la seconda parte sulla rimozione di fake-hwclock e così via).

Ma nessuna fortuna, e le "righe da commentare" non esistono sul mio pi. Il mio pi arriva il 1 gennaio 1970 00:00 e hwclock -rdice che l'RTC è corrotto. Anche se non mi sono spento da quando ho impostato RTC e riavviato il pi, quindi sembra che sia stato corrotto all'avvio.

Inoltre, non sono stato in grado di eseguire i2cdetect. Si lamenta che i dispositivi / dev / i2c (qualcosa) non esistono - e in effetti non ...

Aggiornamento intermedio

OK, ho stabilito che:

• la corruzione è solo delle informazioni di data / ora. Se utilizzo i2cset per riempire il nvram con un modello, tali informazioni non vengono modificate al riavvio, ma l'anno passa a 0x66
• Se rimuovo il ,ds1307dalla linea dtoverlay=i2c-rtc,ds1307in config.txt, allora il sistema viene fuori senza corrompere l'RTC! Il che supporta l'idea che il driver stesso sta corrompendo i dati. Ho guardato il codice del driver, che passa attraverso il tempo e cambia le cose che non gli piacciono (ad esempio cambia il formato da 12 ore a 24 ore). Quindi, forse il problema è che il driver è installato in un momento in cui la porta I2C non è effettivamente pronta per funzionare (forse perché gli orologi non sono pronti?)
• Se lo faccio dopo l'avvio: sudo sh -c 'echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device'fa caricare il driver rtc_ds1307 e appare / dev / rtc0. E il tempo è ancora OK. E così che può essere usato come base per modificare gli script init
• Un altro dettaglio divertente: se uso hwclock -sin uno script subito dopo aver scritto su /sys/..../new_device, non riesce. Ci deve essere un sleep 0.5o qualcosa tra.

Quindi sembra che ora ho un sistema che può essere spento e avviato e avrò l'ora corretta - lo scriverò correttamente presto.

Ecco come l'ho fatto funzionare.

Quasi tutto qui deve essere fatto come superutente, quindi usa 'sudo bash' o metti sudo di fronte a tutto (se non è già mostrato).

Sono necessari i seguenti passaggi di base:

• Organizzare la presenza dei driver 'i2c' se non già;
• esiste un driver aggiuntivo per rtc_ds1307
• rimuovere fake-hwclock. Questo è un sottosistema che verrà normalmente utilizzato quando non si dispone di una rete per fornire il tempo; salva l'ora di sistema in un file quando il sistema viene spento e lo carica dallo stesso file all'avvio. Quindi il tempo non è giusto, ma almeno non torna a zero (1 gennaio 1970) ogni volta che si riavvia. Con RTC installato, l'ora inizierà ragionevolmente corretta anche senza la rete.
• fare in modo che il sistema legga l'ora dall'RTC all'avvio.

Si noti che questo è per l'immagine 2015-05-05-raspian-wheezy, su un rev 2.0 'Pi 1' e un ds1307 rtc collegato al connettore di espansione. Una parte o gran parte di essa dovrebbe applicarsi ad altre situazioni (ma probabilmente non al vecchio raspian). È possibile che il problema con l'RTC danneggiato sia specifico del driver ds1307, quindi potrebbe essere più semplice per altri chip. E quel problema potrebbe essere risolto in una versione futura.

Inoltre, queste istruzioni sono scritte per la PCB del modello 2, dove è in uso il bus I2C n. 1. Se si dispone di un PCB rev1 (che non ha il connettore 'P5' a 8 pin vicino a P1) si collegherà l'RTC al bus I2C # 0. Quindi, ogni volta che vedi /i2c-1/sotto, usa /i2c-0/invece.

Innanzitutto, esegui raspi-config e in "opzioni avanzate" troverai un'impostazione per abilitare I2C e caricare i driver I2C. Abilitali.

Ora, è possibile in linea di principio, aggiungere una riga al fondo /boot/config.txt: dtoverlay=i2c-rtc,ds1307, che caricherà il disco DS1307; ma - come molti hanno scoperto - il caricamento del driver corromperà il contenuto dell'orologio, vanificandone lo scopo. Non ho idea del perché, ma ho guardato l'origine del driver e ho scoperto che all'avvio legge l'orologio e quindi, se trova cose che non gli piacciono (come un formato di 12 ore invece di 24), 'corregge' queste impostazioni con le scritture. Quindi, sospetto che ciò che potrebbe accadere sia che il driver si carica troppo presto dopo l'avvio dell'I2C, e forse gli orologi non sono impostati correttamente o qualcosa del genere e le comunicazioni sono danneggiate. In ogni caso, ciò non funziona con la configurazione che ho e quindi il driver verrà caricato in un secondo momento.

A questo punto, puoi riavviare, e usando lsmod | grep i2cdovresti vedere il i2c_bcm2708driver caricato (come richiesto in raspi-config).

Quindi, esegui questo comando:

echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device

o (se non già superutente):

sudo sh -c 'echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device'

( sudo echonon funzionerà poiché >è ciò che deve essere un superutente).

Ciò dovrebbe causare il rtc_ds1307caricamento del driver e creerà un dispositivo /dev/rtc0. Ora dovresti essere in grado di eseguire hwclock:

sudo hwclock -r

... Visualizza l'ora dall'RTC. Potrebbe generare un errore perché l'orologio non è ancora inizializzato correttamente. In ogni caso, ora lo imposteremo.

(1) assicurarsi che l'orologio di sistema sia impostato usando date. Se sei su una rete, dovrebbe essere già impostato; in caso contrario, esci dal telefono o dall'orologio da tasca e prova qualcosa del genere

sudo date -s '18 nov 2015 22:20:24'

quando l'ora di sistema è impostata correttamente - facendo attenzione a farlo correttamente per il fuso orario - puoi farlo

sudo hwclock -w

che lo copia su RTC.

Quindi hwclock -rdovrebbe funzionare e mostrare l'ora nell'RTC e dovresti vederlo avanzare se lo leggi più di una volta.

Wed 18 Nov 2015 22:48:41 EST  -0.181329 seconds
Wed 18 Nov 2015 22:48:53 EST  -0.013721 seconds

Nota: il valore dell'orologio viene memorizzato rispetto al fuso orario UTC, ma viene visualizzato nell'ora locale.

Passaggio successivo: rimuovere fake-hwclock. Prima disabilitalo e assicurati che hwclock.sh sia abilitato:

sudo update-rc.d hwclock.sh enable
sudo update-rc.d fake-hwclock remove

sudo apt-get remove fake-hwclock
sudo rm /etc/cron.hourly/fake-hwclock
sudo rm /etc/init.d/fake-hwclock

hwclock.shnon farà nulla all'avvio - rileva la presenza di udev e presume che udev abbia svolto il lavoro di avvio - ma fa qualcosa di utile, che è quello di far scrivere l'ora di sistema all'RTC all'accensione. Pertanto, quando ci si connette a una rete, il tempo Pi si sincronizzerà con la rete e la deriva RTC verrà corretta quando si spegne.

Una cosa è rimasta: dobbiamo provvedere a leggere l'RTC all'accensione, quindi verrà impostato l'orario del sistema. udev contiene qualcosa che tenta di farlo, ma che fallirà o verrà bypassato perché il driver RTC non è caricato.

Il modo in cui l'ho impostato è quello di aggiungere queste quattro righe in alto /etc/rc.local(proprio in alto, sotto i commenti):

echo 'setting up RTC'
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
sleep 0.5
hwclock -s

Ciò assicurerà che il driver sia caricato e che l'ora del sistema sia impostata dall'orologio hardware, ogni volta che il sistema si avvia. Il 'sleep 0.5' è lì perché ho scoperto che il hwclockcomando non funzionerebbe senza di esso - l'azione innescata dalla scrittura su /sys/class/i2c-adapter/i2c-1/new_device(incluso fare / dev / rtc0 esiste) apparentemente richiede un po 'di tempo (probabilmente ben meno di 0,5 sec).

E questo è tutto. Non sono davvero contento di questo uso di /etc/rc.local- Preferirei che fosse impostato molto prima, poiché molte cose accadono prima che rc.localvenga eseguito e sarebbe molto meglio avere l'orologio impostato prima che queste cose funzionino. Ma funziona per me. Aggiornerò questa risposta se trovo un modo migliore.

Riferimenti https://www.raspberrypi.org/forums/viewtopic.php?t=97314 https://www.raspberrypi.org/forums/viewtopic.php?p=842661 https://www.raspberrypi.org/forums /viewtopic.php?t=85683 https://www.raspberrypi.org/blog/upcoming-board-revision/

Risposta supplementare - Risoluzione dei problemi con gli strumenti I2C

Mentre cercavo di farlo funzionare, ho trovato utile usare i2c-tools per guardare l'RTC e troverai molti riferimenti a questo in altre discussioni. Avevo aggiunto alcune informazioni alla domanda su ciò che ho trovato con esso; L'ho spostato a questa risposta nel caso fosse utile.

Avrai bisogno di I2C abilitato (raspi-config) e il modulo i2c-dev caricato - puoi forzarlo con a sudo modprobe i2c-dev. i2c-devnon è necessario per far funzionare RTC, ma è necessario utilizzare i2c-tools.

Puoi installare i2c-tools usando sudo apt-get install i2c-tools, se 'i2cdetect' non è presente.

Se si dispone di un PCB Rev. 1: Cambiare i2cdetect -y 1a i2cdetect -y 0, e cambiare tutte le 1 0x68alle 0 0x68nei i2cdumpcomandi.

Tu puoi fare i2cdetect -y 1

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

... il "68" mostra che un dispositivo ha risposto all'indirizzo 0x68 per essere indirizzato sul bus I2C. Se hai caricato il driver rtc_ds1307, verrà visualizzato come 'UU' poiché è riservato dal driver.

Il comando i2cdump -y -f -r 0-6 1 0x68 cpuò essere usato per scaricare i primi 7 registri di ds1307 che contengono il tempo (il '-f' è necessario solo se hai il driver rtc installato; sovrascrive la prenotazione).

Di seguito è riportato ciò che accade dopo l'accensione, quando RTC è danneggiato a causa del caricamento del driver da parte di dtoverlay=i2c-rtc,ds307.

hwclock -r inizialmente segnala che l'impostazione dell'orologio è corrotta e in effetti l'anno è '66'.

pi@raspberrypi ~ $ sudo hwclock -r
hwclock: The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095).
pi@raspberrypi ~ $ sudo i2cdump -y -f -r 0-6 1 0x68 c
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 50 04 00 05 01 01 66                               P?.???f         
pi@raspberrypi ~ $ sudo i2cdump -y -f -r 0-6 1 0x68 c
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 52 04 00 05 01 01 66                               R?.???f         
pi@raspberrypi ~ $ sudo hwclock -w
pi@raspberrypi ~ $ sudo i2cdump -y -f -r 0-6 1 0x68 c
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 35 09 01 03 17 11 15                               5??????         
pi@raspberrypi ~ $ sudo i2cdump -y -f -r 0-6 1 0x68 c
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 37 09 01 03 17 11 15                               7??????         
pi@raspberrypi ~ $ sudo hwclock -r
Tue 17 Nov 2015 01:09:42 UTC  -0.384866 seconds
pi@raspberrypi ~ $ sudo i2cdump -y -f -r 0-6 1 0x68 c
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 46 09 01 03 17 11 15                               F??????         

I sette numeri di i2cdump sono: [sec min hrs giorno della settimana giorno mese anno], tutti in bcd, quindi l'ultima volta è 17-nov-2015, 01:09:46 UTC.

Il tempo 'corrotto' è 1-gen-66, e ho visto altri che hanno riportato lo stesso valore apparire.

Ho avuto un problema simile su due Raspberry Pi 2 Modello B con Arch Linux, uno con un TinyRTC (con il ds1307) e un altro con un condensatore RTC (con il ds3231).

L'esecuzione di NTPD come demone ha corrotto la data di RTC e l'ha impostata su 2066/01/01.

#hwclock --debug
hwclock from util-linux 2.27
Using the /dev interface to the clock.
Last drift adjustment done at 1420070400 seconds after 1969
Last calibration done at 1420070400 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/rtc to change
...got clock tick
Time read from Hardware Clock: 2066/01/01 00:01:12
Invalid values in hardware clock: 2066/01/01 00:01:12
Time since last adjustment is -1420070400 seconds
Calculated Hardware Clock drift is 0.000000 seconds
hwclock: The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095).

Il set up

Ho aggiunto in /boot/config.txt

dtparam=i2c_arm=on
dtoverlay=i2c-rtc,ds1307

o

dtparam=i2c_arm=on
dtoverlay=i2c-rtc,ds3231

Ho aggiunto in /etc/modules-load.d/raspberrypi.conf

i2c-bcm2708
i2c-dev

Ho disabilitato systemd-timesyncd

# timedatectl set-ntp false

Ho installato NTP

# pacman -S ntp

Come l'ha risolto

Ho scoperto che avviando una singola istanza di NTPD prima di avviare il servizio aggiorna l'ora di sistema e non imposta RTC, ma se avvio il servizio NTPD dopo che aggiorna la data RTC senza corromperla.

Ho pensato che ci fosse un problema di autorizzazione. Il gruppo predefinito è audio.

# ls -l /dev/rtc0
crw-rw---- 1 root audio 254, 0 Jan  1  1970 /dev/rtc0

Ho creato /etc/udev/40-rtc-permissions.rules per testarlo

KERNEL=="rtc0", GROUP="ntp", MODE="0666"

ma non ha aiutato, quindi l'ho eliminato.

Ho anche dovuto aggiornare la data di sistema all'avvio in quanto non viene eseguita automaticamente.

Ho aggiunto al file /etc/ntpd.service

ExecStartPre=-/usr/bin/hwclock -s
ExecStartPre=/usr/bin/ntpd -gq

e abilitato il servizio NTPD

# systemctl enable ntpd

e la data si aggiorna e non si corrompe durante l'avvio.

Non ho scoperto che cosa causa il demone NTPD per corrompere RTC se avviato prima e apprezzerei se qualcuno migliora la mia soluzione, ma questo funziona per me.