Comment installer Real Time Clock (RTC) sur Raspbian?

9

J'ai:

  • Raspberry Pi avec 2015-05-05-raspbian-wheezy
  • DS1307 attaché (c'est une carte Adafruit, résistances de pullup non installées).

Comment puis-je:

  • configurer les pilotes
  • assurez-vous que le Pi utilise réellement l'heure RTC au démarrage?

J'ai fait la première partie, pour autant que je sache, mais pas de chance avec la seconde. Une grande partie des informations disponibles, y compris les instructions Adafruit, sont obsolètes pour cette raison: https://www.raspberrypi.org/forums/viewtopic.php?t=97314

Donc, première étape: vous activez l'I2c et les pilotes dans raspi-config, ajoutez dtoverlay=i2c-rtc,ds1307à la fin de /boot/config.txt, et vous avez des pilotes, et cela hwclockfonctionne pour moi maintenant, apparemment (ne peut pas exécuter i2cdetect, plus à ce sujet plus tard).

Vous devez maintenant supprimer fake-hwclock et configurer de sorte qu'il lit réellement le rtc au démarrage. J'ai essayé de suivre ce conseil - qui est en grande partie en accord avec d'autres choses que j'ai vues et qui est très récent - https://www.raspberrypi.org/forums/viewtopic.php?p=842661#p842661

(c'est pour un RTC différent, mais je ne fais que suivre la deuxième partie sur la suppression des fausses heures et ainsi de suite).

Mais pas de chance, et les «lignes à commenter» n'existent pas sur mon pi. Mon pi arrive avec 1 janvier 1970 00:00 et hwclock -rdit que le RTC est corrompu. Même si je ne me suis pas éteint depuis la configuration du RTC et le redémarrage du pi, il semble donc qu'il ait dû être corrompu par le démarrage.

Je n'ai également pas pu exécuter i2cdetect du tout. Il se plaint que les périphériques / dev / i2c (quelque chose) n'existent pas - et en effet ils n'existent pas ...


Mise à jour provisoire

OK, j'ai établi que:

  • la corruption n'est que de l'heure / date info. Si j'utilise i2cset pour remplir le nvram avec un modèle, cette information n'est pas modifiée au redémarrage, mais l'année passe à 0x66
  • Si je supprime le ,ds1307de la ligne dtoverlay=i2c-rtc,ds1307dans config.txt, le système apparaît sans corrompre le RTC! Ce qui soutient l'idée que le pilote lui-même est en train de corrompre les données. J'ai regardé le code du pilote, et il passe par le temps et change les choses qu'il n'aime pas (par exemple, il passe de 12 heures au format 24 heures). Donc, peut-être que le problème est que le pilote est installé à un moment où le port I2C n'est pas réellement prêt à fonctionner (peut-être parce que les horloges ne sont pas prêtes?)
  • Si je fais cela après le démarrage: sudo sh -c 'echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device'cela provoque le chargement du pilote rtc_ds1307 et l'apparition de / dev / rtc0. Et le temps est encore OK. Et donc cela peut être utilisé comme base pour modifier les scripts d'initialisation
  • hwclock -sEncore un détail amusant: si j'utilise dans un script juste après avoir écrit dans /sys/..../new_device, il échoue. Il doit y avoir un sleep 0.5ou quelque chose entre.

Il semble donc que j'ai maintenant un système qui peut être arrêté et démarré, et aura le bon moment - je vais écrire cela correctement bientôt.

greggo
la source
La corruption peut (ou non) être liée à l'exécution de ntpdate ... raspberrypi.org/forums/viewtopic.php?p=690492#p690492
greggo
J'ai ajouté dtparam=i2c1=onà config.txt comme travaillé pour micksulley en janvier raspberrypi.org/forums/viewtopic.php?f=28&t=97639 - Reboot. Toujours pas / dev / i2c *, toujours pas de détection i2c.
greggo
@goldilocks - merci, une pièce de puzzle importante. i2cdetect fonctionne maintenant et 1: 0x68 apparaît comme UU. J'essaierai d'autres choses plus tard dans la journée.
greggo
1
la note sudo invoke-rc.d hwclock.sh startne fait rien, elle sort car /run/udevexiste. Mais sudo invoke-rc.d hwclock.sh showlit l'horloge et sudo invoke-rc.d hwclock.sh stopcopie l'horloge système sur l'horloge matérielle.
greggo

Réponses:

6

Voici comment je l'ai fait fonctionner.

Presque tout ici doit être fait en tant que super-utilisateur, alors utilisez 'sudo bash' ou placez sudo devant tout (si ce n'est déjà fait).

Les étapes de base suivantes sont nécessaires:

  • Faites en sorte que les pilotes «i2c» soient présents s'ils ne le sont pas déjà;
  • il existe un pilote supplémentaire pour rtc_ds1307
  • supprimer faux-hwclock. Il s'agit d'un sous-système qui sera normalement utilisé lorsque vous n'avez pas de réseau pour fournir l'heure; il enregistre l'heure système dans un fichier lorsque le système est arrêté et le charge à partir du même fichier au démarrage. Le moment n'est donc pas venu, mais au moins il ne revient pas à zéro (1er janvier 1970) à chaque redémarrage. Avec le RTC installé, l'heure commencera raisonnablement correcte même sans le réseau.
  • faire en sorte que le système lise l'heure du RTC au démarrage.

Veuillez noter qu'il s'agit de l'image 2015-05-05-raspian-wheezy, sur un rev 2.0 'Pi 1' et un ds1307 rtc attaché au connecteur d'extension. Une partie ou une grande partie devrait s'appliquer à d'autres situations (mais probablement pas aux raspian plus âgés). Il est possible que le problème de corruption du RTC soit spécifique au pilote ds1307, il pourrait donc être plus simple pour d'autres puces. Et ce problème pourrait être corrigé lors d'une prochaine version.

De plus, ces instructions sont écrites pour le PCB du modèle 2, où le bus I2C # 1 est utilisé. Si vous avez un PCB rev1 (qui n'a pas le connecteur `` P5 '' à 8 broches près de P1), vous connecterez le RTC au bus I2C # 0. Donc, chaque fois que vous voyez /i2c-1/ci-dessous, utilisez /i2c-0/plutôt.

Tout d'abord, exécutez raspi-config, et sous «options avancées», vous trouverez un paramètre pour activer l'I2C et le chargement des pilotes I2C. Activez-les.

Maintenant, vous pouvez en principe, ajouter une ligne au bas de /boot/config.txt: dtoverlay=i2c-rtc,ds1307qui va charger le lecteur DS1307; mais - comme plusieurs l'ont constaté - le chargement du pilote corrompra le contenu de l'horloge, ce qui ira à l'encontre de son objectif. Je ne sais pas pourquoi, mais j'ai regardé la source du pilote, et j'ai constaté qu'au démarrage, il lit l'horloge puis, s'il trouve des choses qu'il n'aime pas (comme un format de 12 heures au lieu de 24), il «corrige» ces paramètres avec des écritures. Donc, je soupçonne que ce qui peut arriver, c'est que le pilote se charge trop tôt après le démarrage de l'I2C, et peut-être que les horloges ne sont pas configurées correctement ou quelque chose, et que les communications sont corrompues. Dans tous les cas, cela ne fonctionne pas avec la configuration que j'ai, et nous allons donc charger le pilote plus tard.

À ce stade, vous pouvez redémarrer et en utilisant, lsmod | grep i2cvous devriez voir le i2c_bcm2708pilote chargé (comme demandé dans raspi-config).

Ensuite, exécutez cette commande:

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

ou (s'il n'est pas déjà superutilisateur):

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

( sudo echone fonctionnera pas car >c'est ce qui doit être superutilisateur).

Cela devrait entraîner le rtc_ds1307chargement du pilote et créer un périphérique /dev/rtc0. Vous devriez maintenant pouvoir exécuter hwclock:

sudo hwclock -r

... Ceci affiche l'heure du RTC. Cela pourrait bien générer une erreur car votre horloge n'est pas encore correctement initialisée. Dans tous les cas, nous allons maintenant le régler.

(1) assurez-vous que l'horloge système est réglée à l'aide de date. Si vous êtes sur un réseau, il doit déjà être défini; sinon, sortez votre téléphone ou votre montre de poche et essayez quelque chose comme

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

lorsque vous avez correctement réglé l'heure du système - en veillant à bien l'adapter au fuseau horaire - vous pouvez le faire

sudo hwclock -w

qui le copie au RTC.

Et puis le hwclock -rdevrait fonctionner, et afficher l'heure dans le RTC, et vous devriez le voir avancer si vous le lisez plus d'une fois.

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

Remarque: la valeur d'horloge est stockée par rapport au fuseau horaire UTC, mais elle est affichée en heure locale.

Étape suivante: supprimez les fausses heures. Tout d'abord, désactivez-le et assurez-vous que hwclock.sh est activé:

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.shne fera rien au démarrage - il détecte la présence d'udev et suppose que udev a fait le travail de démarrage - mais il fait quelque chose d'utile, qui est d'écrire l'heure système sur le RTC au démarrage. Ainsi, lorsque vous vous connectez à un réseau, le temps Pi se synchronise avec le réseau et votre dérive RTC est corrigée lorsque vous arrêtez.

Une chose reste - nous devons nous arranger pour lire le RTC à la mise sous tension, donc l'heure du système sera réglée. udev contient un élément qui essaie de le faire, mais qui échouera ou sera ignoré, car le pilote RTC n'est pas chargé.

La façon dont j'ai configuré cela, est d'ajouter ces quatre lignes en haut de /etc/rc.local(en haut à droite, en dessous des commentaires):

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

Cela garantira que le pilote est chargé et l'heure système définie à partir de l'horloge matérielle, à chaque démarrage du système. Le 'sleep 0.5' est là parce que j'ai trouvé que la hwclockcommande ne fonctionnerait pas sans cela - l'action déclenchée par l'écriture /sys/class/i2c-adapter/i2c-1/new_device(y compris la création de / dev / rtc0) prend apparemment un peu de temps (probablement bien en dessous de 0,5 sec).

Et c'est tout. Je ne suis pas vraiment satisfait de cette utilisation de /etc/rc.local- je préfère le configurer beaucoup plus tôt, car beaucoup de choses se produisent avant l' rc.localexécution et il serait préférable de régler l'horloge avant que ces choses ne fonctionnent. Mais ça marche pour moi. Je mettrai à jour cette réponse si je trouve un meilleur moyen.

Références 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/

greggo
la source
J'avais un RTC sur commande et j'avais lu des messages RTC. C'est l'un des rares sur ce site qui mentionne RTC. Mon RTC est arrivé, j'ai ajouté dtoverlay=i2c-rtc,ds3231à config.txtsur le dernier Raspbian (Jessie). Tout semble fonctionner correctement. Aucune configuration spéciale requise. Certes, il s'agit d'une puce différente (bien que la fiche technique soit à peu près la même, à l'exception de la puce Xtal et elle fonctionne à 3,3 V). hwclockBesoins PSsudo
Milliways
1
@Milliways /etc/rc.locals'exécute en tant que root. Je ne me souviens pas si le ds3231 utilise le même pilote, et je ne sais pas ce qui cause la corruption de toute façon, juste que cela se produit lorsque le pilote se charge. De plus, comme je l'ai mentionné dans un commentaire ci-dessus, je soupçonne que certains de ces problèmes peuvent être dus à des conditions de concurrence lors de l'initialisation (par exemple, le pilote rtc peut se charger avant que l'i2c soit correctement configuré), et peut être considérablement affecté par la vitesse de la carte SD. Quand j'ai exécuté Jessie pour la première fois, c'était sur une carte de classe 4, et elle était sérieusement cassée; des erreurs étranges, et il a ignoré shutdown. Était bien sur une classe 10
Greggo
@Milliways mais oui, je recommanderais fortement d'aller avec le ds3231, il fonctionne sur 3.3v, c'est beaucoup plus précis. Si cela vous évite également ces tracas, c'est un énorme bonus.
greggo
2

Réponse supplémentaire - Dépannage avec les outils I2C

En essayant de le faire fonctionner, j'ai trouvé utile d'utiliser les outils i2c pour examiner le RTC, et vous trouverez de nombreuses références à cela dans d'autres discussions. J'avais ajouté quelques informations à la question sur ce que j'en ai trouvé; Je l'ai déplacé vers cette réponse au cas où cela serait utile.

Vous aurez besoin d'I2C activé (raspi-config) et du module i2c-dev chargé - vous pouvez forcer cela avec a sudo modprobe i2c-dev. i2c-devn'est pas nécessaire pour faire fonctionner le RTC, mais il est nécessaire d'utiliser les outils i2c.

Vous pouvez installer les outils i2c en utilisant sudo apt-get install i2c-tools, si «i2cdetect» n'est pas présent.

Si vous avez un PCB Rev. 1: changez i2cdetect -y 1en i2cdetect -y 0et changez tous les 1 0x68en 0 0x68dans les i2cdumpcommandes.

Tu peux faire 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: -- -- -- -- -- -- -- --

... le '68' montre qu'un périphérique a répondu à l'adresse 0x68 à être adressé sur le bus I2C. Si vous avez chargé le pilote rtc_ds1307, il apparaîtra comme «UU» car il est réservé par le pilote.

La commande i2cdump -y -f -r 0-6 1 0x68 cpeut être utilisée pour vider les 7 premiers registres du ds1307 qui contiennent l'heure (le '-f' n'est nécessaire que si vous avez installé le pilote rtc; il remplace la réservation).

Voici ce qui se passe après la mise sous tension, lorsque le RTC est corrompu en raison du chargement du pilote par dtoverlay=i2c-rtc,ds307.

hwclock -r signale initialement que le réglage de l'horloge est corrompu, et en effet l'année est «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??????         

Les sept nombres d'i2cdump sont: [sec min h jour de semaine jour mois année], tous en bcd, donc la dernière fois est le 17-nov-2015, 01:09:46 UTC.

L'heure `` corrompue '' est le 1er janvier 66, et j'ai vu d'autres personnes qui ont signalé la même valeur apparaître.

greggo
la source
2

J'ai eu un problème similaire sur deux Raspberry Pi 2 Model B avec Arch Linux, un avec un TinyRTC (avec le ds1307) et un autre avec un condensateur RTC (avec le ds3231).

L'exécution de NTPD en tant que démon a corrompu la date de RTC et l'a définie sur 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).

La mise en place

J'ai ajouté dans /boot/config.txt

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

ou

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

J'ai ajouté dans /etc/modules-load.d/raspberrypi.conf

i2c-bcm2708
i2c-dev

J'ai désactivé systemd-timesyncd

# timedatectl set-ntp false

J'ai installé NTP

# pacman -S ntp

Comment ça l'a résolu

J'ai constaté qu'en démarrant une seule instance du NTPD avant de démarrer le service, l'heure du système est mise à jour et ne définit pas le RTC mais si je démarre le service NTPD après cela, il met à jour la date du RTC sans le corrompre.

Je pensais qu'il y avait un problème d'autorisation. Le groupe par défaut est audio.

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

J'ai créé /etc/udev/40-rtc-permissions.rules pour le tester

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

mais cela n'a pas aidé alors je l'ai supprimé.

J'ai également dû mettre à jour la date du système au démarrage car cela ne se fait pas automatiquement.

J'ai ajouté au fichier /etc/ntpd.service

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

et activé le service NTPD

# systemctl enable ntpd

et la date est mise à jour et n'est pas corrompue au démarrage.

Je n'ai pas découvert ce qui provoque le démon NTPD pour corrompre le RTC s'il était démarré en premier et j'apprécierais que quelqu'un améliore ma solution, mais cela fonctionne pour moi.

iomihai
la source
Merci pour le post. J'ai combattu cela sur Raspberry Pi 3 toute la journée, et votre message a finalement rassemblé les dernières pièces manquantes. J'utilise Fedberry pour le système d'exploitation et j'essaie de configurer l'unité en tant que serveur IPA (pourquoi? Parce que l'IPA gratuit à 10 watts - a bon goût, moins de remplissage!) J'ai maintenant un serveur IPA fonctionnel qui peut survivre aux pannes de courant sans intervention manuelle. J'utilise le ds1307 rtc et j'ai rencontré certains des mêmes problèmes lors du dépannage de l'horloge que vous aviez identifiée. Le pire était la corruption de la mémoire RTC au démarrage. Je ne sais pas si le dtparam = i2c_arm = on était l'astuce o