I2c-bus - info

[dariozecchini]

Qualcuno mi puo' dare informazioni su questo standard,protocollo o sistema di comunicazione ??

Saluti e grazie

[ifachsoftware]

E' un protocollo sviluppato dalla Philips per colloquiare con soli 2 Fili in multidrop con chip che effettuano diverse funzioni (ce ne sono di In / Out/ Analog ecc..)

Su questo sito c'e' una spiegazione piu' dettagliata

http://www.caen.it/micro/getattach.php?mod=I2C&obj=mn

Ciao

[Luca Bettinelli]

http://www.embedded.com/97/feat9711.htm

http://www.semiconductors.philips.com/buses/i2c/

[bit]

Io lo uso abitualmente per far dialogare più PIC tra loro, nonchè con i vari periferici seriali esistenti sul mercato (EEPROM, RAM, ecc).

Se vuoi posso cercare di prepararti un riassuntino, fammi sapere.

[luciano]

scusami bit tu con i2c fai comunicare + pic tra di loro?

sto pensando a che tipo di strategia usi...

per caso fai puntare i tuoi pic alternativamente

sulla stessa ram (i2c) o eeprom?

sono curioso

e veramente anche interessato

ciao

luciano

[dlgcom]

Io uso un PIC come master e uno come slave .

Dai un indirizzo allo slave e puoi inviare e ricevere dati come da qualsiasi periferica I2C.

Saluti

Luca

[luciano]

come master e' semplice

ma usare un pic come slave ecco e' questo che non capisco...

l'ingresso del clock proveniente dal master si deve configurare

come ingresso del pic slave sda bidirezionale e le rourine???

bella domanda he'....

[bit]

Come master è effettivamente più semplice.

Come slave io utilizzo alcune piccole modifiche: praticamente ho creato alcune subroutine che servono per riconoscere i bit di start e di stop, leggono i byte, controllano la parola di indirizzo, ecc.

Ovviamente il PIC non può stare in ascolto continuamente, non potrebbe fare altro e pensare a un dialogo I2C in interrupt non è pensabile per l'eccessiva lentezza (si potrebbe controllare però solo i livelli sul bus e andare in interrupt quando cambiano, ma la cosa si complica un pochino).

Io uso ovviamente un PIC come master e gli altri come slave, ma in effetti sono gli slave che stabiliscono il collegamento.

Il master, oltre a eseguire il suo programma, interroga ciclicamente tutti gli slave, e se riceve risposta, stabilisce il collegamento, altrimenti passa oltre.

Lo slave, se ha bisogno di dialogare col master, si pone in ascolto e aspetta di essere interrogato, quando è chiamato risponde con un byte che specifica anche il tipo di dati che sono richiesti, se lo slave vuole ricevere o inviare, ecc.

Il fatto che un PIC debba inviare o ricevere è fisso e è stabilito dal byte di risposta dello slave. Ovviamente la linea dati viene programmata come ingresso e come uscita a seconda delle esigenze.

Per quanto riguarda i dati io trasferisco una parte della RAM (il numero di byte trasferiti è stabilito a priori) quindi, dopo la trasmissione, è come se i PIC condividessero la stessa memoria.

E' necessario stare attenti a non sovrascrivere i dati che il PIC ricevente può nel frattempo aver modificato per esigenze proprie.

Si può anche dividere la Ram in due blocchi uguali e utilizzarme uno per ricevere e uno per trasmettere, in questo modo ogni PIC ha sott'occhio la sua metà RAM, dove lui scrive e che viene periodicamente trasmessa e la metà RAM dell'altro PIC, che viene solo letta e periodicamente aggiormata con una ricezione.

Funziona no?

[dlgcom]

Funziona sicuramente.

Io ho fatto la stessa cosa , e poi come un collegamento con 485 esterno .

Un master + slave .

nel mio caso il master interroga gli slave e comanda o una lettura o una scrittura sugli slave.

Naturalmente se , come nel caso di Bit , gli slave possono chiedere di trasmettere userai un byte di stato .

Nello stato il master avra tutte le informazioni che servono per sapere che operazione lo slave vuole fare.

se pero' devi fare una rete piu' complessa , allora la microchip dispone anche dei controller CAN.

Fantastica rete che permette lnche il multimaster ... ma questa e' un altra storia....

Saluti

Luca