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 hwclock
fonctionne 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 -r
dit 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
,ds1307
de la lignedtoverlay=i2c-rtc,ds1307
dans 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 -s
Encore 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 unsleep 0.5
ou 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.
la source
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.sudo invoke-rc.d hwclock.sh start
ne fait rien, elle sort car/run/udev
existe. Maissudo invoke-rc.d hwclock.sh show
lit l'horloge etsudo invoke-rc.d hwclock.sh stop
copie l'horloge système sur l'horloge matérielle.Réponses:
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:
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,ds1307
qui 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 i2c
vous devriez voir lei2c_bcm2708
pilote 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 echo
ne fonctionnera pas car>
c'est ce qui doit être superutilisateur).Cela devrait entraîner le
rtc_ds1307
chargement du pilote et créer un périphérique/dev/rtc0
. Vous devriez maintenant pouvoir exécuterhwclock
: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 commesudo 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 -r
devrait fonctionner, et afficher l'heure dans le RTC, et vous devriez le voir avancer si vous le lisez plus d'une fois.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é:
hwclock.sh
ne 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):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
hwclock
commande 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.local
exé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/
la source
dtoverlay=i2c-rtc,ds3231
àconfig.txt
sur 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).hwclock
Besoins PSsudo
/etc/rc.local
s'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 10Ré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-dev
n'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 1
eni2cdetect -y 0
et changez tous les1 0x68
en0 0x68
dans lesi2cdump
commandes.Tu peux faire
i2cdetect -y 1
... 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 c
peut ê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».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.
la source
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.
La mise en place
J'ai ajouté dans /boot/config.txt
ou
J'ai ajouté dans /etc/modules-load.d/raspberrypi.conf
J'ai désactivé systemd-timesyncd
J'ai installé 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.
J'ai créé /etc/udev/40-rtc-permissions.rules pour le tester
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
et activé le service 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.
la source