protocollo I2C

Il bus I2C, come hai detto tu, è un bus di comunicazione seriale.
A differenza di quanto hai scritto l'I2C è molto diverso dal bus seriale RS232, dato che è un bus sincrono e non asincrono come la RS232 (e tutte le derivazioni, come RS422, RS485, ecc.).

Cosa significano asincrono e sincrono?
Nel bus asincrono il clock viene generato localmente sia dal trasmettitore che dal ricevitore, che devono quindi avere lo stesso baud-rate, ovvero le stesse temporizzazioni per decidere quando leggere il bit.

Praticamente quando il trasmettitore inizia a trasmettere, sulla linea il livello del segnale cambia di stato e questa variazione viene considerata come bit di start che sincronizza la ricezione con la trasmissione.
Da quel momento ogni tot tempo (dove tot è dipendente dal baud-rate impostato) il ricevitore legge lo stato del bit inviato dal trasmettitore e lo inserisce nel buffer di ricezione.
Quindi nelle porte seriali asincrone il clock viene generato localmente non solo dal "master" (trasmettitore), ma anche dallo "slave" (ricevitore).

Nei bus sincroni (come l'I2C) clock e dato vengono generati entrambi dal master e lo slave li riceve, usando il clock per sapere in quale momento deve leggere (campionare) il dato.
A parte casi molto particolari (che non interessano il bus I2C) la velocità di trasmissione (equivalente al baud-rate delle linee asincrone) non è importante: un dispositivo slave può lavorare anche a velocità inferiori a quella nominale, dato che il dato viene letto solo in concomitanza del fronte del clock, senza che intervengano temporizzazioni particolari.
Il limite semmai é nella velocità massima del bus, oltre la quale si rischia che i dati scambiati non siano interpretati correttamente.

Nell'I2C è il fronte di salita del segnale di clock ad essere usato per campionare il bit di dato.
Il bus I2C ha quindi bisogno di 2 segnali riferiti a massa, il clock (chiamato SCL) e il dato (chiamato SDA). Ogni dispositivo, sia master o slave, può generare solo un livello logico 0, chiudendo a massa (0V che nei chip è chiamato anche GND o Vss) la corrispondente linea, con la differenza che il master può agire sia su SCL che su SDA, mentre lo slave agisce solo su SDA, dato che il clock è sempre gestito dal master.
Come dicevo ogni dispositivo fornisce solo il livello logico 0, mentre il livello logico 1 è assicurato da una resistenza di pull-up su ognuna delle 2 linee del bus.
La resistenza di pull-up deve avere un valore non troppo basso per non sovraccaricare le uscite di master e slave (in questo caso il livello logico 0 potrebbe non essere riconosciuto correttamente) e neppure troppo alto, perché altrimenti i segnali impiegano troppo tempo a salire dallo 0 all'1, arrotondando i fronti e rischiando errori di comunicazione.
Generalmente il valore è compreso fra 1K e 10K.


Ogni slave ha un suo indirizzo dipendente sia dalla configurazione interna (base address), ricavabile dal data-sheet, sia da quella esterna, modificabile generalmente col livello logico di uno o più piedini di selezione indirizzo.
Prendendo ad esempio l'EEPROM 24C01 si nota che nella versione a 8 pin esistono 3 ingressi di selezione indirizzo (A0-A2) che, abbinati al base address interno (A0hex), permettono di avere indirizzi che variano da A0hex a AEhex con salti di 2 (A0, A2, A4,....AE).
Il bit 0 del byte di indirizzamento é invece quello che decide la direzione dei dati (se 0 l'operazione é una scrittura, se 1 l'operazione è una lettura).

Lo slave address non ha nulla a che vedere con l'indirizzo interno del dispositivo slave, quello, tanto per intenderci, dove si vuole scrivere o che si vuole leggere. Lo slave address serve solo per "svegliare" uno dei dispositivi slave collegati al bus (tutti i dispositivi sono collegati in parallelo).

La velocità massima di comunicazione può essere di 100Kbit/s, 400Kbit/s oppure 3,4Mbit/s, fermo restando che questa é appunto la velocità massima a cui i dati possono essere scambiati correttamente, mentre, come ho già detto, la velocità può essere rallentata a piacimento, col vantaggio di aumentare l'immunità del sistema ai disturbi elettrici.
Per decidere la posizione di scrittura/lettura del dispositivo slave occorre inviare, dopo il bit di start e lo slave address, 1 o 2 byte di indirizzamento (il numero dipende dallo slave collegato che può avere la necessità di indirizzare più di 256 byte come nel caso di eeprom dalla 24C04 in su).
Sullo stesso bus I2C possono essere collegati slave con indirizzamento sia a 7 che a 10bit, dato che in caso di mancato riconoscimento dello slave address un dispositivo slave ignora il resto dei dati inviati dal master, perché li considera diretti ad un altro slave.

<segue>

Edited by robo67 - 5/1/2011, 22:49

...segue


L'indirizzamento é insito nel protocollo I2C e deve essere comunque gestito, anche se esiste un solo slave.


Grosso modo é così. In realtà l'ACK è una conferma che lo slave manda al master per indicare "ho capito, procedi pure col resto".
Normalmente è il master a dettare legge, gestendo sia il clock che il dato come uscite. Durante l'acknoledge il master continua a gestire il clock, mentre è lo slave a gestire il dato (il master, in questa fase, si mette in condizioni di "ascolto").

Il bus I2C, per come è fatto, è anche in grado di gestire la modalità multimaster, in cui uno qualsiasi degli slave può diventare master appena la linea viene lasciata libera dal dispositivo che fino a quel momento ha fatto da master.
Questo modo di funzionamento deriva dal fatto che uno qualsiasi dei dispositivi collegati al bus può vedere se la linea è già impegnata (in questo caso il clock SCL è a livello logico 0) oppure se è libera (SCL a livello logico 1) e in quest'ultimo caso può agire da master ed impegnare la linea.


Il 16F84 non aveva nessuna periferica dedicata alla porta seriale (UART) e al bus I2C e tutto doveva effettivamente essere gestito a software.
Nei pic più nuovi, come i 16F87x, esiste la MSSP per gestire i protocolli di comunicazione seriale sincrona I2C e SPI (o microwire che è molto simile).
In realtà gestire l'I2C in modalità master tramite software non é poi così drammatico, anche se all'inizio è un po' macchinoso creare alcune routine base come quelle necessarie a serializzare lo slave address, l'indirizzo o i dati da scrivere e quelle per ricevere i byte provenienti dallo slave.
Io a suo tempo ci persi 2-3 giorni, ma ora che ho tutte le routine a disposizione continuo ad usarle anche con i micro che sono dotati della MSSP.
La gestione dell'I2C in modalità slave è invece preferibile che venga fatta tramite l'MSSP, perché altrimenti c'è da piangere, inoltre il micro può fare quasi solo quello, perché deve sempre stare in attesa dei dati per evitare di perdere qualche prezioso bit.
Usando l'MSSP si ha invece un interrupt ogni volta che viene terminata la ricezione di un byte, agevolando il tutto.
Se tu devi gestire degli slave ti consiglio di studiarti a fondo il protocollo e implementarlo via software, così ti fai le ossa e te lo "digerisci" bene.

Per il DS1820 un protocollo I2C master software é adeguato, così come praticamente qualsiasi altra periferica normalmente usata (tranne quelle realmente veloci che però sono usate solo in casi decisamente particolari).
Quando l'I2C l'hai digerito bene lo puoi usare per un'infinità di casi: eeprom, orologi (es. PCF8573), espansione dei pin di ingresso/uscita (PCF8574), driver per display LCD e a LED, ADC, DAC, potenziometri digitali, chip di modifica del segnale audio (equalizzatori, regolatori di tono, volume e bilanciamento) e per televideo, ecc.

Pur essendo stato ideato da Philips, il bus I2C è da qualche anno diventato uno standard usato da tantissimi costruttori di componenti, quindi si trovano chip per tantissima applicazioni diverse.
In caso di funzioni non implementate da qualche chip commerciale c'è poi sempre la possibilità di usare un secondo micro con I2C slave come supporto a quello principale con I2C master.
In questo caso al micro slave si faranno svolgere tutte le funzioni non trovabili nei chip commerciali e il master, tramite il bus I2C, comunicherà col micro slave per gestire tutte queste funzioni.
Io circa 10 anni fa realizzai un'apparecchiatura modulare in cui la scheda principale comunicava con quelle secondarie tramite bus I2C, su cui transitavano le informazioni dal master allo slave e viceversa.

Resta quindi solo da rimboccarsi le maniche per studiare qualcosa che comunque é veramente utilissimo.

Se avrai bisogno di una mano fatti pure avanti.

Innanzi tutto il bus I²C lavora con resistenze di pull-up e uscite open-drain.
Cosa significa?
Le normali uscite del PIC (ad eccezione di RA4) sono formate da 2 transistor MOS: uno con canale P che chiude il pin al positivo (VDD) e uno a canale N che lo chiude al negativo (VSS).
Queste uscite sono praticamente dei push-pull a MOS.
Non sono adatte a pilotare il bus I²C, soprattutto la linea SDA che deve essere bidirezionale in ogni caso (SCL, normalmente settata sempre come uscita del master, diventa bidirezionale solo in sistemi multimaster), perché quando forniscono un livello logico 1 chiudono a VDD il piedino di uscita, quindi quando uno degli slave connessi al bus vuole portare SDA a livello 0 mentre il master (pic) lo tiene già a 1 si crea una condizione anomala, che non è detto che possa creare guasti ai chip, ma che sicuramente porta ad anomalie.

Questo non significa che il pic non possa gestire l'I²C, ma che occorre usare un trucco.

Un'uscita open drain è formata da un MOS a canale N (o transistor BJT NPN) che si chiude quando occorre uno 0 e che resta aperto quando deve restare in condizioni di tristate (alta impedenza=disconnesso dalla linea), in modo da permettere alla resistenza di pull-up di portare la linea a 1.

Nel pic questa condizione la si ottiene facendo in modo che un pic passi da una condizione di uscita con livello logico 0 (per ottenere il livello 0) ad una condizione di ingresso (dato che un ingresso è un pin ad alta impedenza analoga ad un'uscita disconnessa dalla linea, quindi tristate).

Praticamente per usare RA0 come SCL e RA1 come SDA dovresti usare le seguenti istruzioni.
L'esempio è riferito a una EEPROM 24LC01 che ha una velocità di bus massima di 400KHz, mentre per dispositivi con velocità di bus più basse é sufficiente aumentare la durata delle pause, che comunque non è critica, dato che dispositivi veloci possono funzionare anche a velocità basse.

#DEFINE SCL TRISA,0
#DEFINE SDA TRISA,1
#DEFINE SCL_PIN PORTA,0
#DEFINE SDA_PIN PORTA,1

BCF SCL_PIN ;RA0 = livello logico 0
BCF SDA_PIN ;RA1 = livello logico 0
BSF SCL ;SCL=ingresso=open-drain
BSF SDA ;SDA=ingresso=open-drain

Quando tu devi generare il bit di start (che implica che SDA passi da 1 a 0 mentre SCL è a 1) dovrai scrivere:

BSF SDA ;SDA = open-drain = linea a livello logico 1 dato che SCL e SDA hanno le resistenze di pull-up
pausa 10uS ;La durata è poco importante.Dipende dalla velocità del dispositivo,ma se non si ha bisogno di velocità elevate si possono usare 10uS
BCF SCL ;SCL = 0
pausa >0,6uS
BCF SDA ;SDA = 0
pausa >0,6uS
BSF SCL ;SCL = 1
pausa >1,3uS

Segue poi l'invio del byte relativo allo slave address.
Come vedi non c'è nessun generatore di baud rate,perchè le pause possono essere realizzate con ritardi a loop di programma (dato che le pause servono ad eliminare le criticità date da una comunicazione troppo veloce possono tranquillamente avere durata molto maggiore di quella indicata da me, quindi anche eventuali allungamenti introdotti da interrupt caduti durante la gestione delle pause non alterano il funzionamento delle routine I²C ).

Quello a cui fa riferimento il data sheet é l'utilizzo del modulo MSSP (modulo per comunicazione sincrona) in modalità master, situazione in cui occorre dire al pic a quale velocità vuole comunicare (settaggio della frequenza di SCL).

Io l'MSSP l'ho sempre usato in modo slave, mentre il master lo gestisco tramite software.
Questo perché avevo già le routine di comunicazione I²C implementate per pic senza MSSP.

Solo nei pic più recenti (serie 18F e 24F), quando hi iniziato ad usare il C per il quale non avevo nessun software già fatto, ho iniziato a sfruttare l'MSSP in modalità master.

Nel caso d'implementazione software la velocità é data proprio da ritardi a loop di programma (i NOP si possono usare. ma ce ne vorrebbero molti, se usi dispositivi con bus funzionante a 100KHz, quindi è meglio creare i soliti cicli DECFSZ timer,F e GOTO loop che danno una maggiore flessibilità).

No,l'indirizzo slave del dispositivo è semplicemente la combinazione di un settaggio all'interno del chip unito alla configurazione (stato logico) di 1 o più piedini d'indirizzamento.
Il master teoricamente potrebbe andarsi ad analizzare tutti gli indirizzi possibili (da 00 a FF con passi di 2 unità), e vedere chi gli risponde, ma in realtà chi fa il software del microcontrollore master sa probabilmente anche quanti e quali slave sono collegati, quindi non ha bisogno di chiedere "chi sei?". Saprai, ad esempio che la tale EEPROM risponde all'indirizzo 0A0, che l'altro chip ha indirizzo 0F0, ecc.


Il discorso è sensato, anche se in realtà, avendo a disposizione un oscilloscopio a 2 canali (meglio se digitale) e ripetendo il ciclo Start bit, Slave Address e Stop bit potresti controllare il bit di ACK senza dovere agire su un led, dato che al 9° impulso di clock su SCL (clock di ACK) SDA deve trovarsi a 0 se lo slave ha "capito" il master.

Proprio così: la tua scheda non è predisposta per il funzionamento I²C hardware (tramite la porta MSSP), che richiederebbe l'uso dei pin RC3 e RC4, ma solo software.

Proprio ora ho guardato il data sheet del DS1820 e mi sono accorto che non usa assolutamente il bus I²C, ma un bus messo a punto da Dallas/Maxim, chiamato 1Wire, che sfrutta un solo filo come dato e clock.
Il protocollo 1Wire non lo conosco (non ho mai avuto occasione di lavorarci), quindi non so aiutarti più di quanto non possa fare il data sheet.
Se vuoi sperimentare col bus 1Wire per comunicare col DS1820 é un discorso, se invece vuoi imparare ad usare l'I²C é un altro.


........forse é proprio per quello che non riuscivi a capire il discorso dello slave address: nel protocollo 1Wire i dati viaggiano in altro modo.