DVK512

Anche se non si tratta di un HAT in senso stretto, rimane una schedina utile per aggiungere al Raspberry Pi 2 un RTC, una console USB, qualche LED, qualche tasto ed un display 2x16. Ma presenta un grave problema.

Dico che non si tratta di un HAT in senso stretto perché non offre la EEPROM sul bus i2c #0, quindi niente autoconfigurazione del device tree, purtroppo.
Si tratta comunque di una buona scheda di prototipazione poiché offre il set minimale necessario per realizzare semplici interfacce utente, ed in più porta sul bordo le connessioni i2c, spi e seriale (oltre ad 8 GPIO) per renderle più facilmente disponibili.

L'RTC i2c PCF8563 (che richiede una batteria CR1220 di buona qualità, non fornita!) supplisce alla mancanza dell'orologio sul Raspberry. Purtroppo è anche la parte che presenta il problema più serio: la batteria si scarica ad una velocità assurda (poche ore) se si lascia il Raspberry spento col modulo collegato!

Per evitarlo, è necessario togliere le due resistenze di pullup (R1 e R2 nella documentazione, errata: R26 ed R27 non ci sono, tra la batteria ed il catodo di VD1 c'è un altro diodo, l'anodo di VD1 va ai 3.3V invece che ai 5V). Per comodità le ho evidenziate col tratto rosso nella foto:

La spiegazione del problema è evidente, una volta individuato: il Raspberry ha anche lui due weak-pullup (10K) verso la sua linea dei 3.3v. Quindi, mettendo i due pullup da 1K tra le linee dati e la batteria, la corrente poteva scorrere attraverso il diodo, le resistenze da 1k e le resistenze da 10k verso i +3.3V del Raspberry. In pratica era come avere in serie alla batteria un diodo ed una resistenza da 5.5K! Ovvio che si scaricasse velocemente!

La configurazione dell'RTC non è proprio banale ed ho dovuto fare il collage di informazioni provenienti da vari siti per arrivarci in fondo... o quasi. E per questo le raduno qui, così non le perdo.

Prima di tutto, in /etc/firmware/cmdline.txt va aggiunto:
dtparam=i2c dtoverlay=i2c-rtc,pcf8563

Vanno poi caricati i moduli perché hwclock possa accedere all'RTC:
modprobe rtc-pcf8563
(carica automaticamente i2c-dev).
Va poi spiegato al modulo su quale indirizzo è l'RTC, con:
echo pcf8563 0x51 > /sys/class/i2c-dev/i2c-1/device/new_device
A questo punto è possibile impostare la data e l'ora correnti (con date -s, se non avete installato ntpdate) e salvarla nell'RTC con hwclock --systohc.

Da notare che hwclock richiede che si carichino i moduli i2c-dev e rtc-pcf8563, oltre a reimpostarne con echo l'indirizzo i2c. Se non lo si fa, l'orario dell'RTC non potrà mai venire corretto ed il drift aumenterà sempre più...
Per forzare il caricamento dei moduli si possono aggiungere ad /etc/modules le righe

i2c-dev
rtc-pcf8563

Per automatizzare il setup dell'indirizzo, va creato /etc/modprobe.d/rtc.conf contenente:
install rtc-pcf8563 /sbin/modprobe --ignore-install rtc-pcf8563; /bin/echo pcf8563 0x51 > /sys/class/i2c-dev/i2c-1/device/new_device
(da notare /bin/echo invece di echo...). Purtroppo pare che venga ignorato al boot... Ma sto ancora cercando di capire il perché...
Per fare recuperare automaticamente l'ora corrente durante il boot, basterà poi editare /etc/defaults/hwclock .

Il convertitore USB-seriale non ha bisogno di impostazioni particolari, basta controllare che i ponticelli per RX e TX siano chiusi (per raggiungere ttyAMA0) e viene riconosciuto. Non trattandosi di un chip FTDI ma di un CP2102, anche da Windows non si corrono rischi (per chi non lo sapesse, FTDI ha rilasciato un aggiornamento che rendeva inutilizzabili i cloni dei suoi chip... poi lo ha abbastanza prontamente ritirato e ha fornito un fix per riparare i danni).