Vai al precedente POST della serie
Il protocollo i2c (Inter Integrated Circuit), inventato da Philips nel lontano 1982, permette, con solo due connessioni (più la massa), la comunicazione bidirezionale tre due o più dispositivi.
In rete troviamo ovviamente ampia documentazione in merito ma non sempre troviamo chiare indicazioni per implementarlo con successo con i PIC.
In questo articolo vediamo come poter controllare il nostro PIC, via i2c, da qualsiasi altro dispositivo esterno che possa comportarsi da MASTER.
L'i2c infatti prevede, per i dispositivi connessi, due ruoli: il MASTER (padrone) e lo SLAVE (servo).
Entrambi possono ricevere e inviare i dati ma solo il MASTER inizia il dialogo e decide la frequenza di lavoro generando il segnale di sincronismo del BUS.
Il BUS è composto da soli due segnali o linee : la linea di clock (SCL) e quella di dati (SDA).
Sul BUS possono coesistere fino a 127 dispositivi SLAVE in quanto il protocollo prevede di poter assegnare ad ogni dispositivo SLAVE un proprio indirizzo (ADDR): sarà il MASTER a decidere con chi parlare ogni volta che vuole inviare o ricevere dei dati.
E' anche possibile che uno SLAVE possa diventare MASTER occupando il BUS in modo da poter a sua volta dialogare con un altro SLAVE: questa modalità però non è oggetto del presente articolo.
Quindi, riassumendo, il protocollo i2c:
- è di tipo sincrono (linea SCL)
- permette il colloquio bidirezionale su un'unica linea (linea SDA)
- permette il colloquio tra un MASTER e molti SLAVE (ma uno alla volta)
- la velocità di scambio dati si esprime indicando la frequenza degli impulsi di clock e può essere: 100KHZ/sec (standard), 400KHZ/sec (fast), 3,4MHZ/sec (high)
Come dispositivo MASTER andrò ad utilizzare il Raspberry Pi configurato come indicato in questo mio precedente post.
Il Raspberry Pi supporta l'i2c con clock a 100KHZ/sec.
Da notare che i resistori di pull-up, necessari per mantenere sempre a livello logico alto i segnali SCL e SDA (in assenza di traffico dati), sono già integrati dal Raspberry Pi e pertanto, e solo in questo caso, possono essere omessi nel circuito.
Il Raspberry Pi supporta l'i2c con clock a 100KHZ/sec.
Da notare che i resistori di pull-up, necessari per mantenere sempre a livello logico alto i segnali SCL e SDA (in assenza di traffico dati), sono già integrati dal Raspberry Pi e pertanto, e solo in questo caso, possono essere omessi nel circuito.
Implementazione i2c dei PIC 18F
I PIC 18F dispongono internamente di un modulo hardware dedicato ai protocolli seriali sincroni chiamato SSP: Synchronous Serial Port.Tale modulo consente di implementare, con estrema semplicità, sia l'i2c che lo SPI (che vedremo in futuro).
I registri di cui abbiamo bisogno per implementare uno SLAVE i2c sono:
- SSPCON: dove impostare la configurazione del modulo SSP e controllare il bit CKP
- SSPADD: dove impostare l'indirizzo i2c del nostro PIC SLAVE
- TRISC o TRISD: dove configurare i pin scelti come uscite digitali
- INTCON: dove abilitare gli interrupt settando i bit GIE e PEIE
- PIE1: dove abilitare gli interrupt della periferica SPP settando il bit SSPIE
- PIF1: dove verificare che la fonte dell'interrupt sia la eriferica SPP leggendo e azzerando il bit SSPIF
- SSPBUF; dove leggere e scrivere i byte da ricevere o da inviare sul BUS
- SSPSTAT: dove verificare lo stato del modulo SPP e intraprendere il corretto comportamento per portare a termine con successo il dialogo i2c con il MASTER
Ci sono alcuni punti di attenzione, da tenere presente, quanto utilizziamo il modulo SPP come SLAVE i2c:
- versione del PIC 18F
- configurazione dei pin i2c
- tempo limite operativo durante gli interrupt SSP (timing)
La prima trappola da evitare riguarda il fatto che l'implementazione del modulo SPP è leggermente diversa tra alcuni (più vecchi) 18F (tra cui il mio 4431 e famiglia) e i più recenti 18F..
Tali differenze, riportate nel documento Microchip AN734 (appendice C), riguardano gli stati dei bit del registro SSPSTAT in particolare per le operazioni RA (read address) e NACK.
Quindi è sempre bene verificare il datasheet del particolare modello di PIC che intendiamo utilizzare e leggere il documento AN734.
La seconda trappola riguarda il PIC 4431 che permette di scegliere, tra due porte diverse, i pin che vogliamo impegnare per l'i2c: questi posso essere o la coppia RC4(23) e RC5(24) o la coppia RD2(21) e RD3(22).
E' bene quindi non ignorare il settaggio di tale configurazione tramite il bit SSPMX del registro CONFIG3H: se 0 saranno i pin RD2-RD3; se 1 quelli RC4-RC5.
La terza trappola fa proprio la differenza tra successo e fallimento dato che ad un evento i2c dobbiamo rispondere entro un tempo limite altrimenti la comunicazione non va a buon fine.
E' importante quindi avere ben chiaro di quanti cicli operativi (istruzioni PIC) si dispone per gestire un evento i2c.
Operazioni i2c
L'i2c nasce per permettere di impostare o leggere i registri interni ad un dispositivo.
Tipicamente l'operazione di scrittura richiede prima di specificare quale registro scrivere (o da quale iniziare a scrivere) i byte che seguiranno.
Lo SLAVE deve disporre quindi di un registro indice il cui valore viene indicato dal primo byte ricevuto.
Ovviamente possiamo utilizzare l'i2c anche per trasferimenti seriali con una diversa struttura dei dati; ad esempio questo display OLED si controlla via i2c inviando dei comandi e non specificando dei registri interni.
Ogni byte trasferito richiede nove impulsi di clock: 8 per i bit del dato + 1 per il bit di ACK/NACK.
Il bit di ACK/NACK è impostato dalla controparte: MASTER scrive SLAVE risponde ACK/NACK e viceversa SLAVE scrive e MASTER risponde ACK/NACK.
Lo scopo del nono bit di ACK/NACK è quello di indicare di procedere (ACK) o meno (NACK) con l'invio di altri dati.
Ovviamente possiamo utilizzare l'i2c anche per trasferimenti seriali con una diversa struttura dei dati; ad esempio questo display OLED si controlla via i2c inviando dei comandi e non specificando dei registri interni.
Ogni byte trasferito richiede nove impulsi di clock: 8 per i bit del dato + 1 per il bit di ACK/NACK.
Il bit di ACK/NACK è impostato dalla controparte: MASTER scrive SLAVE risponde ACK/NACK e viceversa SLAVE scrive e MASTER risponde ACK/NACK.
Lo scopo del nono bit di ACK/NACK è quello di indicare di procedere (ACK) o meno (NACK) con l'invio di altri dati.
La sequenza di WRITE, inviata dal MASTER, è composta dai seguenti comandi:
La prima riga in azzurro mostra i livelli della linea dati (SDA), la seconda in giallo quelli della linea di clock (SCL) e l'ultima in verde gli eventi di interrupt generati dal modulo SSP del PIC.
Il timing, indicato in basso, ha lo scopo di mostrare di quanto tempo (micro secondi) si dispone prima che venga generato da SSP l'interrupt successivo.
Il primo byte inviato è l'indirizzo dello SLAVE, nel mio caso 0x20, spostato però a sinistra di un bit (0x40) in quanto il bit 0 indica se il MASTER vuole inviare dati allo SLAVE (0=WRITE) o riceverne (1 = READ): quindi 0x40 sta per "scrivo sul dispositivo 0x20", mentre 0x41 sta per "leggo dal dispositivo 0x20".
Il secondo byte indica allo SLAVE il valore da impostare nel registro puntatore: è in pratica l'indce del primo registro delle SLAVE che il MASTER vuole impostare.
I restanti byte sono i valori da impostare nel corrente registro che lo SLAVE determina incrementando il suo registro puntatore per ogni byte ricevuto.
In questo caso il MASTER non vuole scrivere in altri registri oltre al primo e chiude il colloquio con un segnale di STOP.
L'operazione di lettura richiede prima una scrittura in modo che lo SLAVE imposti il registro puntatore al registro dal quale iniziare a leggere
.
La sequenza di READ, inviata dal MASTER, è quindi preceduta da una sequenza di WRITE:
Come visto sopra il MASTER invia una sequenza di scrittura verso lo slave 0x20 di un solo byte dati:l'indice del primo registro da leggere.
Dopo lo STOP il MASTER invia una seconda sequenza stavolta di lettura dello SLAVE 0x20.
Sarà adesso lo SLAVE a scrivere sulla linea dati (SDA) i bit corrispondenti al valore da trasmettere al MASTER.
Lo SLAVE è sempre vincolato dal segnale di clock (SCL) generato dal MASTER che legge lo stato della SDA nei punti indicati dalla freccetta in su.
Come sa lo SLAVE se il MASTER vuole ricevere il valore del successivo registro?
Il MASTER, dopo aver letto tutti gli otto bit dal dato al nono impulso setta SDA a 0 (ACK) se vuole ricevere il successivo valore/registro, a 1 (NACK) se non vuole ricevere ulteriori dati.
Stati del modulo SPP
Di seguito il dettaglio di tutti i possibili stati gestiti dal modulo SPP:- S: start
SPP monitora il BUS e genera questo evento non appena un MASTER impegna il BUS per iniziare una sequenza W o R (anche se destinata ad altro SLAVE) - WA: write address
SPP colleziona i bit indirizzo inviati sul BUS per controllare se destinati a lui; il valore ricevuto è quindi l'indirizzo i2c che verrà comparato da SPP con quanto scritto in SSPADD; solo se uguali SPP genera l'evento WA e tutti i successivi fino allo stop. - WD: write data
SPP genera questo evento per ogni byte ricevuto successivamente all'indirizzo i2c - P: stop
SPP genera questo evento quando un MASTER libera il BUS avendo terminato la sequenza di invio o ricezione - RA: read address
Come per WA solo che il MASTER vuole leggere il valore del corrente registro - RW: read data
Come per WD solo che il MASTER vuole leggere il valore del successivo registro
ACK e NACK
In ricezione dati SSP genera per noi i segnali di ACK, al nono impulso di clock, ogni volta che riesce a caricare il registro SPPBUF con gli 8 bit dati ricevuti.E' importante far sempre trovare il buffer SPPBUF scarico/libero leggendo il precedente valore ricevuto prima che arrivi del successivo: in caso contrario SPP andrà in errore di "write collision":
- generando un segnale di NACK sul BUS
- impostando il bit WCOL in SSPCON (che va poi azzerato manualmente per ripristinare il funzionamento di SPP)
In invio dati invece siamo noi che dobbiamo verificare che il MASTER abbia segnalato un ACK o un NACK e questo verificando il bit CKP di SSPCON: se 0 ACK, se 1 NACK.
Mano al codice
Il codice di prova, ben commentato, lo trovate qui.Si tratta di un esempio d'implementazione i2c slave dove il PIC espone 3 registri:
- add1 (indirizzo 0x00)
- add2 (indirizzo 0x01)
- sum (indirizzo(0x02)
Scrivendo in 'add1' e in 'add2' due valori si potrà leggere la loro somma tramite il registro 'sum'.
Circuito elettrico
Da notare che il quarzo del PIC è, in questo caso, da 16 MHZ.
VDD deve essere 3.3 volt per garantire la compatibilità con i livelli logici del RaspberryPi.
VDD deve essere 3.3 volt per garantire la compatibilità con i livelli logici del RaspberryPi.
Attenzione: non interfacciate mai dispositivi a 3.3 volt con altri a 5.0 volt senza adattare i livelli tramite appositi circuiti.
Non prelevate mai la VDD a 3.3 volt direttamente dal Raspberry: rischiate di danneggiarlo seriamente.
Non prelevate mai la VDD a 3.3 volt direttamente dal Raspberry: rischiate di danneggiarlo seriamente.
Utilizzo
Dalla console del Raspberry Pi:
- digitare il comando "sudo i2cset -y 1 0x20 0x00 0x0A 0x0B i"
questo imposta entrambi i registri add1=0x0b (10) e add2=0x0B (11) - digitare il comando "sudo i2cget -y 1 0x20 0x00"
questo ci ritorna il valore di add1 cioè 0x0A (10) - digitare il comando "sudo i2cget -y 1 0x20 0x01"
questo ci ritorna il valore di add2 cioè 0x0B (11) - digitare il comando "sudo i2cget -y 1 0x20 0x02"
questo ci ritorna la somma di add1 e add2 ciaoè 0x15 (21)
In un prossimo articolo andrò a realizzare, con il PIC 18F, un controller per servomotori basato su i2c.
Stay tuned!
ap
NB: l'autore non risponde di eventuali danni causati da omissioni, inesattezze o errori eventualmente presenti nell'articolo pubblicato.
Prego, segnalare suggerimenti e migliorie commentando questo post o inviando una email a padnest@gmail.com.
