Como instalar o Real Time Clock (RTC) no Raspbian?

Eu tenho:

• Raspberry Pi com 05-05-2015-raspbian-wheezy
• DS1307 conectado (é uma placa Adafruit, resistores pullup não instalados).

Como é que eu:

• configurar drivers
• verifique se o Pi realmente usa o tempo do RTC na inicialização?

Na verdade, eu fiz a primeira parte, até onde sei, mas não tive sorte com a segunda. Muitas das informações disponíveis, incluindo as instruções da Adafruit, estão obsoletas devido a isso: https://www.raspberrypi.org/forums/viewtopic.php?t=97314

Então, primeiro passo: você habilita o I2c e os drivers no raspi-config, adiciona dtoverlay=i2c-rtc,ds1307no final do /boot/config.txt e hwclockpossui drivers e funciona para mim agora, aparentemente (não pode executar o i2cdetect, mais nisso depois).

Agora você precisa remover o fake-hwclock e configurá-lo para que ele realmente leia o rtc na inicialização. Eu tenho tentado seguir este conselho - que está amplamente de acordo com outras coisas que vi e é muito recente - https://www.raspberrypi.org/forums/viewtopic.php?p=842661#p842661

(isso é para um RTC diferente, mas estou apenas seguindo a segunda parte sobre a remoção de fake-hwclock e assim por diante).

Mas sem sorte, e as 'linhas a serem comentadas' não existem no meu pi. Meu pi aparece com 1 de janeiro de 1970 00:00 e hwclock -rdiz que o RTC está corrompido. Mesmo que eu não desliguei desde a configuração do RTC e a reinicialização do pi, parece que ele deve ter sido corrompido pela inicialização.

Também não consegui executar o i2cdetect. Ele reclama que os dispositivos / dev / i2c (algo) não existem - e de fato não existem ...

Atualização provisória

OK, eu estabeleci que:

• a corrupção é apenas da informação de hora / data. Se eu usar o i2cset para preencher o nvram com um padrão, essas informações não serão modificadas na reinicialização, mas o ano será 0x66
• Se eu remover o ,ds1307da linha dtoverlay=i2c-rtc,ds1307em config.txt, o sistema será instalado sem danificar o RTC! O que apóia a idéia de que o próprio driver está corrompendo os dados. Eu olhei para o código do driver, e ele percorre o tempo e muda as coisas de que não gosta (por exemplo, altera o formato de 12 horas para 24 horas). Portanto, talvez o problema seja que o driver esteja instalado em um momento em que a porta I2C não esteja pronta para funcionar (talvez porque os relógios não estejam prontos?)
• Se eu fizer isso após a inicialização: sudo sh -c 'echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device'ele fará com que o driver rtc_ds1307 seja carregado e o / dev / rtc0 seja exibido. E o tempo ainda está bom. E assim isso pode ser usado como base de como modificar os scripts init
• Mais um detalhe divertido: se eu usar hwclock -sum script logo após escrever em /sys/..../new_device, ele falhará. Precisa haver um sleep 0.5ou algo entre.

Parece que agora tenho um sistema que pode ser desligado e iniciado, e terá a hora correta - escreverei isso corretamente em breve.

Aqui está como eu fiz funcionar.

Quase tudo aqui precisa ser feito como superusuário, então use 'sudo bash' ou coloque o sudo na frente de tudo (se ainda não estiver mostrado).

São necessárias as seguintes etapas básicas:

• Organize a presença dos drivers 'i2c', se ainda não estiverem;
• existe um driver adicional para rtc_ds1307
• remover fake-hwclock. Este é um subsistema que normalmente será usado quando você não tiver uma rede para fornecer o tempo; ele economiza o tempo do sistema em um arquivo quando o sistema é desligado e o carrega do mesmo arquivo na inicialização. Portanto, a hora não está certa, mas pelo menos ela não volta a zero (1 de janeiro de 1970) toda vez que você reinicia. Com o RTC instalado, o horário começará razoavelmente correto, mesmo sem a rede.
• providenciar para que o sistema leia a hora no RTC na inicialização.

Observe que isso é para a imagem 2015-05-05-raspian-wheezy, em uma versão 2.0 'Pi 1' e em um ds1307 rtc conectado ao conector de expansão. Parte ou muito disso deve se aplicar a outras situações (mas provavelmente não ao raspian mais antigo). É possível que o problema com o RTC corrompido seja específico do driver ds1307, portanto, poderia ser mais simples para outros chips. E esse problema pode ser corrigido em algum lançamento futuro.

Além disso, estas instruções foram escritas para a PCB modelo 2, em que o barramento I2C nº 1 está em uso. Se você possui uma placa de circuito impresso rev1 (que não possui o conector 'P5' de 8 pinos próximo a P1), estará conectando o RTC ao barramento I2C # 0. Portanto, sempre que vir /i2c-1/abaixo, use em seu /i2c-0/lugar.

Primeiro, execute raspi-config e, em 'opções avançadas', você encontrará uma configuração para ativar o I2C e o carregamento dos drivers I2C. Habilite-os.

Agora, você pode, em princípio, adicionar uma linha para o fundo do /boot/config.txt: dtoverlay=i2c-rtc,ds1307, que irá carregar a unidade DS1307; mas - como vários descobriram - o carregamento do driver corromperá o conteúdo do relógio, anulando sua finalidade. Não sei por que, mas observei a fonte do driver e descobri que, na inicialização, ele lê o relógio e, se encontrar coisas que não gosta (como um formato de 12 horas em vez de 24), ele 'corrige' essas configurações com gravações. Portanto, desconfio que o que possa estar acontecendo é que o driver seja carregado logo após o início do I2C, e talvez os relógios não estejam configurados corretamente ou algo assim, e as comunicações estejam corrompidas. De qualquer forma, isso não funciona com a configuração que tenho e, portanto, faremos com que o driver seja carregado mais tarde.

Nesse ponto, você pode reiniciar e, ao usar lsmod | grep i2c, o i2c_bcm2708driver deverá ser carregado (conforme solicitado em raspi-config).

Em seguida, execute este comando:

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

ou (se ainda não for superusuário):

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

( sudo echonão funcionará, pois >é isso que precisa ser superusuário).

Isso deve fazer com que o rtc_ds1307driver seja carregado e criará um dispositivo /dev/rtc0. Agora você deve poder executar hwclock:

sudo hwclock -r

... Isso exibe a hora do RTC. Pode muito bem gerar um erro porque seu relógio ainda não foi inicializado corretamente. De qualquer forma, agora o definiremos.

(1) verifique se o relógio do sistema está ajustado usando date. Se você estiver em uma rede, ela já deve estar configurada; caso contrário, pegue seu telefone ou seu relógio de bolso e tente algo como

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

quando a hora do sistema estiver definida corretamente - tome cuidado para acertar o fuso horário - você poderá

sudo hwclock -w

que copia para o RTC.

E então o hwclock -rdeve funcionar, e mostra o horário no RTC, e você deve vê-lo avançando se o ler mais de uma vez.

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

Nota: o valor do relógio é armazenado em relação ao fuso horário UTC, mas é exibido no horário local.

Próximo passo: remova o fake-hwclock. Primeiro desative-o e verifique se o hwclock.sh está ativado:

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.shnão fará nada na inicialização - ele detecta a presença do udev e assume que o udev fez o trabalho de inicialização - mas faz algo útil, que faz com que a hora do sistema seja gravada no RTC na inicialização. Portanto, quando você se conectar a uma rede, o horário do Pi será sincronizado com a rede e o desvio do RTC será corrigido quando você desligar.

Só resta uma coisa - precisamos organizar a leitura do RTC na inicialização, para que a hora do sistema seja definida. O udev tem algo que tenta fazer isso, mas que falhará ou será ignorado, porque o driver RTC não está carregado.

A maneira como configurei isso é adicionar essas quatro linhas na parte superior /etc/rc.local(à direita na parte superior, abaixo dos comentários):

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

Isso garantirá que o driver esteja carregado e a hora do sistema definida no relógio do hardware, sempre que o sistema for iniciado. O 'sleep 0.5' está lá porque descobri que o hwclockcomando não funcionará sem ele - a ação acionada ao escrever /sys/class/i2c-adapter/i2c-1/new_device(incluindo fazer / dev / rtc0 existir) aparentemente leva um pouco de tempo (provavelmente bem abaixo de 0,5 s).

E é isso. Eu não estou realmente feliz com esse uso de /etc/rc.local- prefiro configurá-lo muito mais cedo, pois muitas coisas acontecem antes de rc.localserem executadas e seria muito melhor ter o relógio definido antes que essas coisas funcionem. Mas está funcionando para mim. Atualizarei esta resposta se encontrar uma maneira melhor.

Referências 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/

Resposta complementar - Solução de problemas com ferramentas I2C

Ao tentar fazê-lo funcionar, achei útil usar o i2c-tools para examinar o RTC, e você encontrará muitas referências a isso em outras discussões. Eu adicionei algumas informações à pergunta sobre o que encontrei; Eu mudei para esta resposta, caso seja útil.

Você precisará do I2C ativado (raspi-config) e o módulo i2c-dev carregado - você pode forçar isso com a sudo modprobe i2c-dev. i2c-devnão é necessário para fazer o RTC funcionar, mas é necessário usar o i2c-tools.

Você pode instalar o i2c-tools usando sudo apt-get install i2c-tools, se 'i2cdetect' não estiver presente.

Se você possui uma PCB Rev. 1: Mude i2cdetect -y 1para i2cdetect -y 0e mude tudo isso 1 0x68para 0 0x68os i2cdumpcomandos.

Você pode fazer 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: -- -- -- -- -- -- -- --

... o '68' mostra que um dispositivo respondeu no endereço 0x68 para ser endereçado no barramento I2C. Se você carregou o driver rtc_ds1307, ele aparecerá como 'UU', pois é reservado pelo driver.

O comando i2cdump -y -f -r 0-6 1 0x68 cpode ser usado para despejar os 7 primeiros registros do ds1307 que contêm o tempo (o '-f' é necessário apenas se você tiver o driver rtc instalado; ele substitui a reserva).

Abaixo está o que acontece após a inicialização, quando o RTC está corrompido devido ao carregamento do driver por dtoverlay=i2c-rtc,ds307.

hwclock -r relata inicialmente que a configuração do relógio está corrompida e, na verdade, o ano é '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??????         

Os sete números do i2cdump são: [seg min hrs dia da semana dia mês ano], todos em bcd, portanto, a última vez é 17 de novembro de 2015, 01:09:46 UTC.

O tempo 'corrompido' é 1 de janeiro de 66, e vi outros que relataram o mesmo valor aparecer.

Eu tive um problema semelhante em dois Raspberry Pi 2 Modelo B com Arch Linux, um com um TinyRTC (com o ds1307) e outro com um capacitor RTC (com o ds3231).

A execução do NTPD como daemon corrompeu a data do RTC e configurou-o para 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).

A configuração

Eu adicionei no /boot/config.txt

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

ou

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

Eu adicionei no /etc/modules-load.d/raspberrypi.conf

i2c-bcm2708
i2c-dev

Desativei systemd-timesyncd

# timedatectl set-ntp false

Eu instalei o NTP

# pacman -S ntp

Como isso resolveu

Descobri que iniciar uma única instância do NTPD antes de iniciar o serviço atualiza a hora do sistema e não define o RTC, mas se eu iniciar o serviço NTPD depois disso, ele atualiza a data do RTC sem corrompê-lo.

Eu pensei que há um problema de permissão. O grupo padrão é áudio.

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

Criei /etc/udev/40-rtc-permissions.rules para testá-lo

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

mas não ajudou, então eu a apaguei.

Eu também tive que atualizar a data do sistema na inicialização, pois isso não é feito automaticamente.

Eu adicionei ao arquivo /etc/ntpd.service

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

e habilitou o serviço NTPD

# systemctl enable ntpd

e a data é atualizada e não corrompe durante a inicialização.

Não descobri o que faz com que o daemon NTPD corrompa o RTC se iniciado primeiro e agradeceria se alguém melhorasse minha solução, mas isso funciona para mim.