Master I2C con MCC (MSSP)

Tutorial → PIC18 in C → I2C → Master I2C con MCC (MSSP)

In questa pagina è mostrato come utilizzare MPLAB Code Configurator per realizzare un master I2C con il PIC18. Non verrà qui spiegato cosa è e come si usa il bus I2C. Semplicemente verranno presentati alcuni esempi che permettono di comprendere come usare un dispositivo I2C collegato ad un PIC. Qui qualche informazione.

Gli esempi utilizzano due slave piuttosto diffusi (il sensore di temperatura TC74 ed il sensore di luminosità TSL2561), ma possono essere considerati sufficientemente generali per qualunque tipo di dispositivo. Analogamente il processore utilizzato (un PIC18F25K50) è sostituibile con altri, purché supportati dal MCC e dotato di modulo MSSP. Il circuito stampato PIC-USB, parzialmente visibile nella fotografia di apertura, è facilmente sostituibile con altri oppure può essere realizzato direttamente su breadboard.

Se invece il vostro processore utilizza un modulo I2C dedicato, come ad esempio il PIC18(L)F2xK42, fate riferimento alla pagina Master I2C con MCC.

MCC gestisce il bus I2C tramite interruzioni e permette di trasmettere frame anche complessi.

La configurazione del sistema e del modulo MSSP

La creazione del progetto non presenta particolati difficoltà.

Pur non essendo strettamente necessario conviene impostare il clock ad una frequenza elevata al fine di ridurre la latenza delle interruzioni:

MCC: configurazione del clock

La scelta di quali interrupt utilizzare e delle relative modalità dipende ovviamente dal complesso del progetto:

MCC: cofigurazione delle interruzioni

Anche la configurazione dei pin dipende dal complesso del progetto. Nell'esempio viene utilizzato solo RA1 (MyLED). Da osservare che è necessario configurare esplicitamente i due pin SDA e SCL (RB0 e RB1) come ingressi digitali, richiesta presente nei manuali tecnici, ma non evidenziata nella documentazione del MCC.

MCC: configurazione dei pin

Infine occorre impostare il modulo MSSP come master I2C. I parametri da impostare:

La frequenza del clock I2C (SCL), strettamente dipendente alla frequenza del clock delle periferiche e della CPU. Per fare ciò occorre impostare il valore del registro SSPADD (Baud Rate Generator, se in modalità I2C master). La frequenza di SCL è automaticamente calcolata e mostrata dopo aver manualmente inserito il valore del registro (nell'esempio mostrato, rispettivamente, 100 kHz e 0x77)
La dimensione dell'indirizzo degli slave. (nota 1)
Lo Slew Rate adeguato alla velocità scelta e all'entità di emissioni elettromagnetiche accettabili. In genere è consigliabile la velocità standard per clock I2C fino a 100 kHz
La tensione di soglia da utilizzare. Se si selezione l'opzione SMBus verranno utilizzate per VIL e VIH le tensioni fisse di 0,8 V e 2,1 V, altrimenti il 30% ed il 70% della tensione di alimentazione. In molti casi la scelta è indifferente, soprattutto se anche le periferiche sono alimentate con la stessa VDD
La scelta di un tempo di hold per SDA relativamente elevato aiuta nel caso di bus con capacità elevata, come quella che potrebbe essere presente se si usa una breadboard

MCC: configurazione di MSSP

Esempio 1: lettura di un byte

Questo esempio (nota 2) mostra la semplice lettura di un byte. Lo slave utilizzato è il sensore di temperatura TC74 che, ad una richiesta di lettura, semplicemente risponde con un byte indicante la temperatura.

Il frame "teorico" scambiato tra master e slave è mostrato nello schema seguente dove il significato di lettere e simboli è il seguente:

S identifica il bit di Start; Sr, qui non rappresentato, identifica lo Start ripetuto; P è il bit di Stop
slave address è l'indirizzo dello slave a sette bit. In questo caso è 0x4D
R è il bit di Read; W, in questo primo schema non rappresentato, è il bit di scrittura
A è l'Acknowledgement (riscontro) e Ā il riscontro negativo
data è il dato trasmesso (8 bit)

Inoltre in blu sono i segnali generati dal PIC18 (master), in giallo quelli generati dal TC74 (slave)

I2C: semplice lettura di un byte

Si notino in particolare il valore del bit di lettura / scrittura (freccia rossa) ed il riscontro negativo al termine della comunicazione (freccia verde).

Il codice è particolarmente semplice e l'avvio del processo di lettura consiste praticamente di una singola funzione:

I2C1_MasterRead(readBuffer, 1, TC74_ADDR, &status);

Gli argomenti di questa funzione sono piuttosto intuitivi e descritti all'interno del file i2c1.h, automaticamente generato da MCC:

Il primo argomento readBuffer indica il buffer in cui verranno salvati i byte letti. In genere è un array di byte di dimensioni adeguate, passato ovviamente per indirizzo
Il secondo argomento indica il numero di byte da leggere. Nell'esempio è un solo byte
Il terzo argomento indica l'indirizzo fisico dello slave I2C. Nell'esempio è TC74_ADDR, pari a 0x4D
L'ultimo argomento &status è l'indirizzo della variabile di tipo I2C1_MESSAGE_STATUS in cui le funzioni generate da MCC salvano (e mantengono aggiornato) lo stato della trasmissione. I valori possibili per tale variabile sono descritti più avanti

Ovviamente prima dell'inizio del superloop del main() è necessario configurare le periferiche (operazione svolta automaticamente da MCC) ed attivare le interruzioni (codice da scrivere manualmente, decommentando le righe opportune)

Il seguente diagramma temporale mostra i segnali presenti. Dall'altro:

SDA (in rosso) indica in dato trasmesso, nell'esempio l'indirizzo 0x4D (trasmesso dal master) e il byte 0x15 (trasmesso dallo slave, 21 in decimale). La temperatura è effettivamente di 21 °C
SCL (in verde) + il clock I2C, con frequenza 100 kHz
L'ultimo segnale (blu) non ha nulla a che fare con il bus I2C: è un semplice LED che viene acceso e spento continuamente all'interno del main() durante la trasmissione:
for (int i = 0; i < 100; i++) MyLED_Toggle();
La trasmissione del singolo byte è infatti gestita in hardware dal modulo MSSP e la ISR interviene solo tra un byte e l'altro e durante le fasi di inizio e fine del frame, interrompendo l'esecuzione del programma principale che in altri momenti prosegue.

Diagrammi temporali

status

L'ultimo valore ritornato dalla funzione I2C1_MasterRead() indica lo stato della trasmissione I2C, che come abbiamo visto evolve in modo asincrono rispetto al programma principale.

I valori significativi di tale variabile sono:

I2C1_MESSAGE_COMPLETE significa che il frame I2C è stato completamente inviato e che quindi è possibile iniziare l'invio di un altro frame. Potrebbe essere utile (nota 2) modificare il codice di esempio inserendo:
if (status == I2C1_MESSAGE_COMPLETE)
I2C1_MasterRead(readBuffer, 1, TC74_ADDR, &status);
I2C1_MESSAGE_FAIL indica un errore nella trasmissione
I2C1_MESSAGE_PENDING indica la trasmissione in corso (escluso l'ultimo AKC ed il bit di stop)
I2C1_MESSAGE_ADDRESS_NO_ACK e I2C1_DATA_NO_ACK indicano l'assenza di riscontro di un indirizzo o di un byte

Nel codice è inserito qualche esempio, sotto forma di commento

Esempio 2: lettura di un byte da un registro

Questo esempio mostra la comunicazione più diffusa tra master e slave: quella in cui il master scrive un comando oppure un registro e lo slave risponde.

Come esempio viene utilizzato sempre il TC74. Il master invia prima l'indirizzo del registro che vuole leggere (nell'esempio: 0x00) e lo slave risponde con il suo contenuto (nell'esempio: 0x15).

Di seguito lo schema del frame scambiato tra master e slave ed il relativo diagramma temporale.

Lettura di un byte da un registro - Schema

Lettura di un byte da un registro - Diagramma temporale

Nel linguaggio usato nella descrizione di MCC, tale frame viene definito come costituito da due Transaction Request Blocks (TRB), il primo di scrittura, il secondo di lettura.

Le funzioni utilizzate sono suddivise in due gruppi:

Due funzioni servono per costruire i TRB di scrittura o i TRB di lettura:
I2C1_MasterWriteTRBBuild();
I2C1_MasterReadTRBBuild();
Si noti che tali funzioni non inviano nulla, ma si limitano a creare i vari comandi da inviare, nell'ordine richiesto dallo slave
Una funzione permette l'inserimento dei TRB nella coda di trasmissione per l'effettivo invio:
I2C1_MasterTRBInsert();

Gli argomenti delle due funzioni di *TRBBuild():

L'elemento della lista di tipo I2C1_TRANSACTION_REQUEST_BLOCK in cui associare il blocco, in ordine progressivo. Ovviamente tale array deve essere sufficientemente grande per ospitare tutti blocchi tra trasmettere (in genere però sono solo due)
Il buffer con i dati da trasmettere oppure in cui memorizzare i byte ricevuti
Il numero di byte da leggere oppure scrivere
L'indirizzo dello slave

Nel codice di esempio:

Il primo elemento memorizzato in TRB è costituito da un blocco di scrittura di dimensioni pari ad un byte, contenente l'indirizzo del registro 0x00 dello slave TC74 da cui il master vuole leggere:
I2C1_MasterWriteTRBBuild(&TRB[0], writeBuffer, 1, TC74_ADDR);
Il secondo è costituito dalla lettura di un solo byte:
I2C1_MasterReadTRBBuild(&TRB[1], readBuffer, 1, TC74_ADDR);

La funzione I2C1_MasterTRBInsert(2, TRB, &status); inserisce nella coda di trasmissione i due elementi presenti nell'array TRB, iniziando l'effettiva trasmissione. Il significato di &status è già stato descritto

Esempio 3: lettura e scrittura di un blocchi di dati

Il protocollo I2C prevede la lettura e la scrittura anche di blocchi di dati. Nel terzo esempio viene utilizzato un sensore di luminosità TSL2561 che permette di leggere un blocco di 4 byte dopo aver specificato gli opportuni valori nei registri interni.

Il codice è oggetto del primo esercizio, da fare consultando i fogli tecnici del componente.

Codice

Il codice mostrato è relativo al solo main() ed è richiesta la generazione del progetto utilizzando MPLAB(c) Code Configurator, come descritto in questa pagina

I2C_MCC_TC74_simple.c - Lettura di un byte dal sensore TC74
I2C_MCC_TC74_TRB.c - Lettura di un byte dal sensore TC74 usando Transaction Request Blocks
I2C-MCC_TSL2561.c - Uso del sensore, sono utilizzate le funzioni I2C1_MasterWrite() e I2C1_MasterTRBInsert()

Esercizi

Analizzare il codice del terzo esempio
Scrivere il codice per utilizzare altri dispositivi I2C, in base alla effettiva disponibilità dei componenti

Note

Non è stata verificata l'opzione "10 bit" in quanto non si dispone al momento di alcuno slave compatibile con tale modalità
Nell'esempio non è strettamente richiesto perché il ritardo inserito è in genere sufficiente per l'intera trasmissione del frame

Data di creazione di questa pagina: aprile 2016
Ultima modifica: 25 aprile 2016