
Alcuni di noi, con ottima probabilità, ne siamo sicuri, già conoscono oppure hanno utilizzato il protocollo di comunicazione I2C. Tanti, però, probabilmente, ne ignorano il funzionamento e le potenzialità, soprattutto se utilizzato in maniera avanzata. Ecco allora un articolo in cui ci occupiamo di questo versatile e validissimo protocollo dandone uno sguardo approfondito ad aspetti, funzioni ma soprattutto applicazioni. Parleremo diffusamente di start bit, I2C boost ed I/O expander: siete pronti?
ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 4005 parole ed è riservato agli ABBONATI. Con l'Abbonamento avrai anche accesso a tutti gli altri Articoli Tecnici che potrai leggere in formato PDF per un anno. ABBONATI ORA, è semplice e sicuro.

Un sola parola, grazie, questo articolo mi casca proprio a fagiolo. Come probabilmnte hai già avuto modo di intuire, ho un problema e mi serve un I/O expander. Per chi non avesse seguito il tread, sul forum mi sto occupando della realizzazione di un dirigibile drone per le riprese televisive, utilizzando come board di controllo la scheda Intel Galileo. Senza nemmeno prendere in considerazione gli ingressi, il numero di uscite disponibili è largamente inferiore al necessario. L’hardware ha infatti l’Arduino 1.0 pinout, quindi 14 I/O, 6 analog input, l’I2C. In tutto piloterò 5 motori passo passo bipolari, 4 linee ciascuno, siamo già a 20 uscite, e 2 brushless per i motori di spinta 2 linee nella migliore delle ipotesi. Devo necessariamente sfruttare l’I2C con le board giuste, nella speranza di trovarne, altrimenti andrò sul sito della Texas o della Maxim e mi realizzerò qualcosa ad hoc
Con Piero abbiamo lavorato proprio in questa direzione: trattare l’argomento I2C senza essere banali!
Ormai le basi del protocollo sono note a tutti e facilmente reperibili online, ma una trattazione approfondita delle funzionalità era necessaria!
L’I2C può essere utilizzata come I/O expander ma anche coem protocollo per coprire lunghe distanze, quasi a far concorrenza all’RS485 ma con tutti i vantaggi di compatibilità con i vari dispositivi.
Ciao Piero //Include the Wire library
Come sempre i tuoi articoli sono impeccabili :D, non parliamo poi del numero sfornato, senza ridurne la qualità.
Effettivamente sapere come funziona un protocollo di trasmissione dati è utile, anche se poi la stragrande maggioranza delle persone si limita a utilizzare le librerie già pronte per i vari tipi di linguaggi.
Tipico esempio dei vari sensori per Arduino: temperatura STH11, sensore barometrico MPL115A2, accelerometro MMA7455 e tanti altri
In questi di solito ci si limita a includere la libreria:
#include
E magari la libreria specifica per il componente utilizzato, ed ecco che i dati sono già in bella vista.
Non per questo occorre criminalizzare quest’atteggiamento.
Quante volte un progetto resta per mesi nel cassetto per qualche errore nel listato.
Per questo un grazie per sapere cosa avviene nelle retrovie del funzionamento di questi componenti elettronici.
Un saluto
Adriano
Ciao a tutti
Ti devo correggere Emanuele: “le basi del protocollo sono note a tutti” tranne che a me 🙂 in pratica sono “sottozero” con l’I2C e questo 3d è per me il trampolino di lancio che mi permetterà di tuffarmi in quest’altra avventura, mi chiedo se riuscirò mai a trovare il tempo necessario che mi permetta di dedicarmi a tutte queste novità, è da agosto che tento di fare qualcosa con i PIC e l’unica cosa che sono riuscito a fare è stata quella di togliere dal suo imballo originale, il programmatore di PIC (stava chiuso nel suo cartone dal lontano 2000) che è ormai divenuto obsoleto, quindi mi toccherà iniziare con dei componenti non più in commercio per poi passare alle novità (sempre che riesca ad iniziare).
Quindi mi è doveroso un grazie oltre ai complimenti e, se riuscirò ad andare avanti condividerò anche questa esperienza.
Ciao
Mario
Che dire… sto ristudiando l’argomento e sto scoprendo cose nuove, ottimo articolo! 🙂
Adesso per un grande ed interessante progetto(almeno per me) devo solo decidere se utilizzare la comunicazione i2c o seriale, comprendendo bene i pregi e i difetti di ognuno…
Se devo darti una mia opinione rischio di farti un mezzo spoiler di quello che Emanuele ti dirà….
Diciamo solo che molto dipende dall’applicazione, dal tuo livello di competenza e preparazione ma soprattutto da quello che vuoi fare, quanto avrai bisogno di essere professionale piuttosto che dal tipo di interfaccia che riesci a trovare sui sensori oppure sulle schede sulle quali sei costretto a lavorare, per esempio (perché non sempre può scegliere tu!)…
Poi c’è il debug…
I parametri sono tanti…
Diciamo che per il momento ho messo un po’ di carne al fuoco (e emanuele ne avrà di certo da aggiungere…!)… 😀
Su questo Emanuele ha una sua convintissima opinione…
Che penso, riflettendoci un attimo, potrebbe anche essere espressa in un articolo dedicato… della serie: “confronto testa a testa”. 😉
Credo che possa essere interessante assistere ad un confronto 🙂
Magari potrebbero essere visti i casi in cui è possibile che coesistano più master…
Nel frattempo che viene pubblicato l’articolo però non mi dispiacerebbe avere un opinione a riguardo, così posso cominciare il progetto.
Piero, tu che dici?
Emanuele, tu che ne pensi?
A presto,
Ivan
Ti ringrazio davvero.
E’ sempre bello e gratificante che ci sia qualcuno che si rivolge in questi termini all’autore di un articolo. Mi fa piacere per tutti gli autori che scrivono su questo blog.
La mia speranza, per me, è sempre quella di riuscire a migliorare sia in qualità sia in competenza…
Per quanto riguarda il protocollo di trasmissione, io lo trovo estremamente comodo, molto semplice ed intuitivo.
Proprio per questo motivo, penso, è particolarmente diffuso specie tra gli utenti che imparano, quelli che usano i sensori più diffusi, quelli che si procurano le prime schede e così via dicendo.
Inoltre, da un utente che comincia non si può davvero pretendere che sviluppi una libreria in completa autonomia.
D’altronde, mettiamoci una mano la coscienza e siamo onesti: quando tutti noi abbiamo cominciato abbiamo, nella migliore delle ipotesi, abbiamo prima usato le librerie scritte da altri, poi cominciato a modificarle per renderle più simili a quello che volevamo fare, poi abbiamo cominciato a buttar giù delle righe di codice per creare delle nostre librerie e poi ci siamo riusciti (perchè di mezzo c’è stata di certo una lunga serie di errori… ;p).
Per forza così sono andate le cose perché a scrivere una libreria è difficile che si nasca imparati… 😀
D’altronde, in effetti, proprio in questo panorama Arduino si propone come la soluzione perfetta…!
È vero, succede. Ed è giusto non voler criminalizzare, come dici tu, questo atteggiamento.
Però il problema è che l’evoluzione della preparazione dell’individuo che vuole fare il tecnico, il progettista o quant’altro deve necessariamente seguire quell’iter lì perché se in qualcuno di questi passaggi si ferma, è perduto!
Anche la diffusione di questi protocolli attraverso un numero enorme di sensori fa la sua parte in questo senso.
Ecco per quale motivo mi affiderei proprio a voi che siete stati così attivi in questi mesi per fare qualche bell’articolo in cui analizzate il protocollo oscilloscopio alla mano… Qualcuno di voi ne ha vinto uno di recente? 😀
Non vedo l’ora di vedere questo progetto completo e pubblicato… 😀
Sono contento ti sia piaciuto e mi auguro ti sia utile 😀
Facci sapere appena scegli con cosa sperimentare 😀
La comunicazione I2C è una comunicazione seriale….
Mi sfugge qualcosa oppure puoi spiegare meglio questa frase:
“…..devo solo decidere se utilizzare la comunicazione i2c o seriale”
Si, ho sbagliato a scrivere, provo a definire meglio la frase.
Devo decidere se utilizzare il protocollo i2c, o il collegamento seriale con RX E TX.
RX e TX di cosa?
Stai parlando della UART? della SPI? e poi per che physical layer RS232, RS485…
Cerca di essere più esaustivo.
Sto parlando della UART, mentre sullo physical layer non sono sicuro…
Se per esempio utilizzassi un atmega328, che physical layer utilizza?
Grazie,
Ivan