¿Cómo instalar Real Time Clock (RTC) en Raspbian?


9

Yo tengo:

  • Raspberry Pi con 2015-05-05-raspbian-wheezy
  • ds1307 conectado (es una placa Adafruit, las resistencias pullup no están instaladas).

Cómo puedo:

  • configurar controladores
  • ¿se asegura de que el Pi realmente use el tiempo RTC al inicio?

De hecho, he hecho la primera parte, por lo que puedo ver, pero no tuve suerte con la segunda. Gran parte de la información disponible, incluidas las instrucciones de Adafruit, son obsoletas debido a esto: https://www.raspberrypi.org/forums/viewtopic.php?t=97314

Entonces, primer paso: habilita el I2c y los controladores en raspi-config, agrega dtoverlay=i2c-rtc,ds1307al final de /boot/config.txt, y tiene controladores, y hwclockfunciona para mí ahora, aparentemente (no puede ejecutar i2cdetect, más en eso luego).

Ahora necesita eliminar fake-hwclock y configurarlo para que realmente lea el rtc al inicio. He estado tratando de seguir este consejo, que está en gran medida de acuerdo con otras cosas que he visto, y es muy reciente: https://www.raspberrypi.org/forums/viewtopic.php?p=842661#p842661

(eso es para un RTC diferente, pero solo estoy siguiendo la segunda parte sobre la eliminación de fake-hwclock y así sucesivamente).

Pero no tuve suerte, y las 'líneas para comentar' allí no existen en mi pi. Mi pi aparece el 1 de enero de 1970 a las 00:00 y hwclock -rdice que el RTC está dañado. Incluso si no me apagué desde que configuré el RTC y reinicié el pi, parece que debe haber sido dañado por el inicio.

Tampoco he podido ejecutar i2cdetect en absoluto. Se queja de que los dispositivos / dev / i2c (algo) no existen, y de hecho no ...


Actualización provisional

OK, he establecido que:

  • la corrupción es solo de la información de hora / fecha. Si uso i2cset para llenar el nvram con un patrón, esa información no se modifica al reiniciar, pero el año va a 0x66
  • Si elimino el ,ds1307de la línea dtoverlay=i2c-rtc,ds1307en config.txt, ¡el sistema aparece sin dañar el RTC! Lo que respalda la idea de que el controlador está corrompiendo los datos. Observé el código del controlador, revisa el tiempo y cambia cosas que no le gustan (por ejemplo, cambia el formato de 12 horas a 24 horas). Entonces, quizás el problema es que el controlador está instalado en un momento en que el puerto I2C no está realmente listo para funcionar (¿tal vez debido a que los relojes no están listos?)
  • Si hago esto después del inicio: sudo sh -c 'echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device'hace que se cargue el controlador rtc_ds1307 y que aparezca / dev / rtc0. Y el tiempo aún está bien. Y eso puede usarse como base para modificar los scripts de inicio
  • Un detalle más divertido: si lo uso hwclock -sen un script justo después de escribir en /sys/..../new_device, falla. Tiene que haber un sleep 0.5o algo en medio.

Parece que ahora tengo un sistema que se puede apagar y encender, y que tendrá la hora correcta. Escribiré esto correctamente pronto.


La corrupción puede (o no) tener que ver con ntpdate ejecutándose ... raspberrypi.org/forums/viewtopic.php?p=690492#p690492
greggo

He añadido dtparam=i2c1=ona config.txt como trabajado para micksulley en enero raspberrypi.org/forums/viewtopic.php?f=28&t=97639 - Reinicio. Todavía no / dev / i2c *, aún no hay i2cdetect.
greggo


@goldilocks: gracias, una pieza importante del rompecabezas. i2cdetect ahora funciona y 1: 0x68 aparece como UU. Intentaré algunas otras cosas más tarde hoy.
greggo

1
nota sudo invoke-rc.d hwclock.sh startno hace nada, sale porque /run/udevexiste. Pero sudo invoke-rc.d hwclock.sh showlee el reloj y sudo invoke-rc.d hwclock.sh stopcopia el reloj del sistema en el reloj de hardware.
greggo

Respuestas:


6

Así es como lo hice funcionar.

Casi todo aquí debe hacerse como superusuario, así que use 'sudo bash' o coloque sudo delante de todo (si no se muestra).

Se necesitan los siguientes pasos básicos:

  • Haga los arreglos para que los controladores 'i2c' estén presentes si no es que ya lo están
  • hay un controlador adicional para rtc_ds1307
  • eliminar fake-hwclock. Este es un subsistema que normalmente se usará cuando no tenga una red para suministrar el tiempo; ahorra el tiempo del sistema en un archivo cuando el sistema se apaga y lo carga desde el mismo archivo al inicio. Por lo tanto, no es el momento adecuado, pero al menos no vuelve a cero (1 de enero de 1970) cada vez que reinicia. Con el RTC instalado, el tiempo comenzará razonablemente correcto incluso sin la red.
  • haga arreglos para que el sistema lea la hora del RTC al inicio.

Tenga en cuenta que esto es para la imagen 2015-05-05-raspian-wheezy, en una rev 2.0 'Pi 1', y un ds1307 rtc conectado al conector de expansión. Algo o gran parte de esto debería aplicarse a otras situaciones (pero probablemente no a los raspios más viejos). Es posible que el problema con la corrupción del RTC sea específico del controlador ds1307, por lo que podría ser más simple para otros chips. Y ese problema puede solucionarse en algún lanzamiento futuro.

Además, estas instrucciones están escritas para la PCB modelo 2, donde se usa el bus I2C # 1. Si tiene una PCB rev1 (que no tiene el conector 'P5' de 8 pines cerca de P1) conectará el RTC al bus I2C # 0. Entonces, cada vez que vea /i2c-1/en la parte inferior, use /i2c-0/en su lugar.

Primero, ejecute raspi-config, y en 'opciones avanzadas', encontrará una configuración para habilitar I2C y cargar los controladores I2C. Habilítalos.

Ahora, en principio, puede agregar una línea en la parte inferior de /boot/config.txt:, dtoverlay=i2c-rtc,ds1307que cargará la unidad ds1307; pero, como varios han encontrado, la carga del controlador corromperá el contenido del reloj, frustrando su propósito. No tengo idea de por qué, pero miré la fuente del controlador y descubrí que al inicio, lee el reloj y luego, si encuentra cosas que no le gustan (como un formato de 12 horas en lugar de 24), 'corrige' esas configuraciones con escrituras. Entonces, sospecho que lo que puede estar sucediendo es que el controlador se carga demasiado pronto después de que el I2C ha comenzado, y tal vez los relojes no están configurados correctamente o algo así, y las comunicaciones están dañadas. En cualquier caso, eso no funciona con la configuración que tengo, por lo que haremos que el controlador se cargue más tarde.

En este punto, puede reiniciar, y al usar lsmod | grep i2cdebería ver el i2c_bcm2708controlador cargado (como se solicitó en raspi-config).

A continuación, ejecute este comando:

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

o (si aún no es superusuario):

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

( sudo echono funcionará ya que >es lo que debe ser superusuario).

Esto debería rtc_ds1307cargar el controlador y creará un dispositivo /dev/rtc0. Ahora debería poder ejecutar hwclock:

sudo hwclock -r

... Esto muestra el tiempo desde el RTC. Es muy posible que genere un error porque su reloj aún no se ha inicializado correctamente. En cualquier caso, ahora lo configuraremos.

(1) asegúrese de que el reloj del sistema esté configurado con date. Si está en una red, ya debería estar configurada; si no, saca tu teléfono o tu reloj de bolsillo y prueba algo como

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

cuando tiene la hora del sistema configurada correctamente, teniendo cuidado de hacerlo correctamente para la zona horaria, puede hacerlo

sudo hwclock -w

que lo copia al RTC.

Y luego hwclock -rdebería funcionar, y mostrar la hora en el RTC, y debería verlo avanzar si lo lee más de una vez.

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

Nota: el valor del reloj se almacena en relación con la zona horaria UTC, pero se muestra en la hora local.

Siguiente paso: eliminar fake-hwclock. Primero deshabilítelo y asegúrese de que hwclock.sh esté habilitado:

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.shno hará nada en el inicio: detecta la presencia de udev y supone que udev ha hecho el trabajo de inicio, pero hace algo útil, que hace que la hora del sistema se escriba en el RTC en el encendido. Entonces, cuando te conectas a una red, el tiempo Pi se sincronizará con la red, y tu deriva RTC se corregirá cuando te apagues.

Queda una cosa: tenemos que hacer arreglos para leer el RTC en el encendido, por lo que se establecerá la hora del sistema. udev tiene una cosa que intenta hacer eso, pero que fallará o se omitirá, porque el controlador RTC no está cargado.

La forma en que configuré esto es agregar estas cuatro líneas en la parte superior de /etc/rc.local(justo en la parte superior, debajo de los comentarios):

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

Esto asegurará que el controlador esté cargado y que la hora del sistema se configure desde el reloj del hardware, cada vez que se inicie el sistema. El 'sleep 0.5' está allí porque descubrí que el hwclockcomando no funcionaría sin él; la acción activada al escribir en /sys/class/i2c-adapter/i2c-1/new_device(incluida la creación de / dev / rtc0 existe) aparentemente lleva un poco de tiempo (probablemente bastante por debajo de 0.5 segundos).

Y eso es. No estoy muy contento con este uso de /etc/rc.local- Prefiero tenerlo configurado mucho antes, ya que muchas cosas suceden antes de que rc.localse ejecute y sería mucho mejor tener el reloj configurado antes de que esas cosas funcionen. Pero me está funcionando. Actualizaré esta respuesta si encuentro una mejor manera.

Referencias 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/


Tenía un RTC en orden y había estado leyendo publicaciones de RTC. Este es uno de los pocos en este sitio que menciona RTC. Mi llegó RTC, añadí dtoverlay=i2c-rtc,ds3231a config.txten el último Raspbian (Jessie). Todo parece funcionar bien. No se requiere una configuración especial. Es cierto que este es un chip diferente (aunque la hoja de datos se ve muy similar, aparte del Xtal en el chip y funciona desde 3.3V). hwclockNecesidades de PSsudo
Milliways,

1
@Milliways se /etc/rc.localejecuta como root. No recuerdo si el ds3231 usa el mismo controlador, y no sé qué causa la corrupción de todos modos, solo que sucede cuando se carga el controlador. Además, como mencioné en un comentario anterior, sospecho que algunos de estos problemas pueden deberse a condiciones de carrera durante el inicio (por ejemplo, el controlador rtc puede cargarse antes de que el i2c esté configurado correctamente), y puede verse considerablemente afectado por la velocidad de la tarjeta SD Cuando ejecuté a Jessie por primera vez, estaba en una tarjeta de clase 4, y estaba seriamente rota; errores extraños, e ignorado shutdown. Estuvo bien en una clase 10
greggo

@Milliways pero sí, recomiendo encarecidamente ir con el ds3231, se ejecuta en 3.3v, es mucho más preciso. Si también te salva de estas molestias, es una gran ventaja.
greggo

2

Respuesta complementaria: solución de problemas con herramientas I2C

Mientras intentaba que funcionara, encontré útil usar las herramientas i2c para mirar el RTC, y encontrará muchas referencias a esto en otras discusiones. Agregué información a la pregunta sobre lo que encontré con ella; Lo he movido a esta respuesta en caso de que sea útil.

Necesitará I2C habilitado (raspi-config) y el módulo i2c-dev cargado; puede forzar esto con un sudo modprobe i2c-dev. i2c-devno es necesario para que el RTC funcione, pero sí para usar las herramientas i2c.

Puede instalar i2c-tools usando sudo apt-get install i2c-tools, si 'i2cdetect' no está presente.

Si tiene una PCB Rev. 1: cambie i2cdetect -y 1a i2cdetect -y 0y cambie todo 1 0x68a 0 0x68en los i2cdumpcomandos.

Tu puedes hacer 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: -- -- -- -- -- -- -- --

... el '68' muestra que un dispositivo respondió en la dirección 0x68 para ser direccionado en el bus I2C. Si ha cargado el controlador rtc_ds1307, aparecerá como 'UU' ya que está reservado por el controlador.

El comando i2cdump -y -f -r 0-6 1 0x68 cse puede usar para volcar los primeros 7 registros del ds1307 que contienen el tiempo (el '-f' solo es necesario si tiene instalado el controlador rtc; anula la reserva).

A continuación se muestra lo que sucede después del encendido, cuando el RTC está dañado debido a la carga del controlador dtoverlay=i2c-rtc,ds307.

hwclock -r Inicialmente informa que la configuración del reloj está corrupta, y de hecho el año es '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??????         

Los siete números de i2cdump son: [seg min hrs día de la semana día mes año], todos en bcd, por lo que la última vez es el 17 de noviembre de 2015, 01:09:46 UTC.

El tiempo 'corrupto' es el 1-ene-66, y he visto a otros que han informado que aparece el mismo valor.


2

Tuve un problema similar en dos Raspberry Pi 2 Modelo B con Arch Linux, uno con un TinyRTC (con el ds1307) y otro con un condensador RTC (con el ds3231).

Ejecutar NTPD como daemon corrompió la fecha de ambos RTC y la configuró en 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 puesta en marcha

Agregué en /boot/config.txt

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

o

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

Agregué en /etc/modules-load.d/raspberrypi.conf

i2c-bcm2708
i2c-dev

Deshabilité systemd-timesyncd

# timedatectl set-ntp false

Instalé NTP

# pacman -S ntp

Cómo lo resolvió

Descubrí que al iniciar una sola instancia del NTPD antes de iniciar el servicio, se actualiza la hora del sistema y no establece el RTC, pero si inicio el servicio NTPD después de eso, actualiza la fecha del RTC sin corromperlo.

Pensé que hay un problema de permiso. El grupo predeterminado es audio.

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

Creé /etc/udev/40-rtc-permissions.rules para probarlo

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

pero no ayudó, así que lo eliminé.

También tuve que actualizar la fecha del sistema al inicio ya que no se hace automáticamente.

Agregué al archivo /etc/ntpd.service

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

y habilitó el servicio NTPD

# systemctl enable ntpd

y la fecha se actualiza y no se corrompe durante el arranque.

No descubrí qué causa que el demonio NTPD corrompa el RTC si se inicia primero y agradecería que alguien mejore mi solución, pero esto funciona para mí.


Gracias por la publicacion. He estado luchando contra esto en Raspberry Pi 3 todo el día, y tu publicación finalmente reunió las últimas piezas faltantes. Estoy ejecutando Fedberry para el sistema operativo y estoy tratando de configurar la unidad como un servidor IPA (¿por qué? Debido a que IPA gratis a 10 vatios, ¡sabe muy bien, se llena menos!) Ahora tengo un servidor IPA en funcionamiento que puede sobrevivir a fallas de energía sin intervención manual. Estoy usando el ds1307 rtc, y me encontré con algunos de los mismos problemas al solucionar el reloj que había identificado. Lo peor fue la corrupción de la memoria RTC en el arranque. No estoy seguro si dtparam = i2c_arm = on fue el truco o
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.