protocollo I2C

Dunque.....
Il bus I²C è dotato di 2 linee: SCL (clock) e SDA (data).
Nell'architettura più semplice (un master, 1 o più slave) SCL viene generato dal master e sincronizza la scrittura verso gli slave e la lettura da essi.
SDA può essere generato alternativamente dal master o dallo slave in quel momento attivo (da master a slave durante la scrittura e da slave a master durante la lettura).

Le linee sono entrambe open-drain (o open collector), quindi possono lavorare fra livello logico 0 (quando il transistor/mosfet che pilota la linea SCL/SDA è chiuso/on) oppure in tristate (quindi ad alta impedenza, quando il transistor/mosfet è aperto/off).
Nel bus I²C non c'è quindi nessun chip in grado di fornire un livello logico 1, che è invece garantito da 2 resistenze di pull-up collegate fra SCL e positivo d'alimentazione e SDA e positivo d'alimentazione.

E qui sta il trucco che ti permetterà di gestire l'accelerometro.
-Innanzi tutto dovrai alimentare l'accelerometro a 3/3,6V, prelevando tale tensione o da un apposito alimentatore a parte oppure ricavandola dai 5V della scheda Easy-pic.
-Collegherai poi le resistenze di pull-up al +3/3,6V che alimenta anche l'accelerometro.
-Dovrai infine collegare le masse della scheda Easy-pic con quella dell'alimentazione dell'accelerometro (sempre che tu non abbia ricavato tale tensione dai +5V della Easy-pic, in questo caso il collegamento fra le 2 masse c'è già).

In questo modo avrai che SCL e SDA varieranno fra 0V (livello logico 0) e +3/3,6V (livello logico 1 fornito dalle resistenze di pull-up).
Il pic montato sulla Easy-pic vedrà la tensione di 3-3,6V come livello logico 1 anche se è alimentato a 5V (i 2 livelli sono compatibili), mentre quando piloterà la linea non creerà danni perché lavorerà appunto fra 0 e tristate (che porterà la tensione della corrispondente linea SCL e/o SDA a salire fino ai 3/3,6V che alimentano le resistenze di pull-up).

Se hai bisogno di qualche chiarimento sai dove trovarmi (non garantisco però una risposta lampo, visto che sono decisamente tempo-libero-carente).

Se vuoi fare le cose comode e sbrigative.........beh, vai al mare e lascia stare tutto,altrimenti perdi tempo e poi rischi seriamente di fare dei danni.
La tensione per l'accelerometro falla con un regolatore degno di tal nome e lascia stare le pile che magari non ti fanno funzionare nulla solo perché sono mezze scariche.
Se fai un alimentatore partendo dalla tensione di 5V (o anche di più, così sei più sicuro di avere una stabilizzazione degna di tal nome,come ad esempio la tensione che alimenta la Easy-pic) non correrai il rischio di rincorrere i "fantasmi", domandandoti come mai quello che hai fatto non funziona, cercando bug nel software per giorni, per poi accorgerti magari che l'hardware è sottoalimentato.
Come mai stai consigliando a giovi27 di ricorrere ad un programmatore già fatto invece di autocostruirselo, raffazzonando a destra e a sinistra?
Semplicemente perché se le cose le fai bene e parti con qualche certezza puoi sperare di ottenere qualcosa, altrimenti rischi di brancolare nel buio.


Se non so quale data sheet stai guardando potrei dirti "No, le resistenze di pull-up non sono R1 e R2, ma R127 e R159²
A parte gli scherzi le resistenze sono quelle che collegano SDA e SCL al positivo di alimentazione del/dei chip che pilotano la linea I²C.
Alla fine il positivo che deve essere utilizzato è quello più basso fra tutti quelli che alimentano i chip collegati al bus. Nel tuo caso hai un pic alimentato a 5V e l'accelerometro a 3V, quindi devi "pulluppare" a 3V, altrimenti l'accelerometro, quando la linea SCL e/o SDA si porta a 5V, rischia seriamente di ....


Consiglio: inizia con un dispositivo più semplice di un accelerometro, ad esempio con un PCF8574 su cui puoi collegare 8 led (attenzione che il PCF8574 può fornire una corrente decente sul livello logico 0, mentre il livello logico 1 fa ....... e quindi non riuscirebbe ad accendere i led i modo decente se li pilotassi tramite l'anodo invece che il catodo).

Praticamente se tu riuscirai ad accendere i led del PCF8574 tramite il bus I²C saprai che le routine di lettura/scrittura funzionano bene e potrai passare a qualcosa di più complesso (accelerometro compreso).

Se proverai a fare funzionare direttamente l'accelerometro farai probabilmente un buco nell'acqua.
Sei così sicuro di riuscire a fornire un'accelerazione costante all'accelerometro mentre provi a leggerlo col pic e verifichi che tutto funzioni regolarmente?

L'accelerazione è un parametro fisico non proprio banale da riprodurre in modo controllato, quindi sviluppare un software su un qualcosa di già concettualmente difficoltoso da usare (e da simulare) porta facilmente ad una sconfitta.
ma questo è solo un mio parere, non la legge (non per niente faccio parte dei noobs).

Il modulo accelerometro ha già R1 e R2 come pull-up, quindi i 2 pin del pic che userai come SCL e SDA dovranno essere flottanti.
Quando scriverai il software dovrai fare in modo che i 2 pin passino da una condizione di tristate (=pin flottante =pin settato come ingresso ) ad una di livello logico 0. Il livello logico 1 non dovrà mai uscire dal pin del PIC, altrimenti l'accelerometro rischierà di guastarsi a causa dei 5V forniti dal PIC stesso.
Quando il PIC dovrà fornire uno 0 su una delle 2 linee il corrispondente pin dovrà essere settato come uscita. Quando invece il PIC dovrà fornire uno 1 su una delle 2 linee il corrispondente pin dovrà essere settato come ingresso, in modo tale da avere l'1 logico assicurato dalla resistenza di pull-up.
Ammettendo di volere usare RB0 come SCL e RB1 come SDA dovrai quindi settare il PIC come segue:
- Porti a 0 i bit 0 e 1 del registro PORTB (corrispondente a RB0 e RB1).
- Porti a 1 i bit 0 e 1 del registro TRISB: a questo punto SCL e SDA si porteranno entrambe a 1 grazie al pull-up
Quando dovrai portare SCL o SDA a 0 dovrai portare a 1 il bit corrispondente di TRISB: in questo modo il PIC piloterà la linea col valore impostato nel corrispondente bit del PORTB, quindi uno 0 (dato che precedentemente era stato posto a 0).


Far fare ad un pic una cosa banale tramite l'I²C non è banale (scusa il gioco di parole): quando hai capito come funziona il tutto banale lo diventa (o quasi), ma quando stai provando è decisamente indigesto, anche perchè se la comunicazione non dovesse funzionare a chi daresti la colpa, al master o allo slave?

Inizialmente sì, ma è quello che ti fa capire meglio come funziona il bus I²C, con in più il vantaggio di potere usare qualsiasi pin invece di doverti limitare all'impiego di RB3 e RB4 dell'MSSPI.
Certo, la gestione software ti consuma memoria e risorse del PIC, ma se è ottimizzata decentemente il discorso non è per nulla drammatico.
In qualche applicazione ho anche gestito 2 bus ²C con un unico PIC (non sto a spiegarti come mai me ne servissero 2 perché è un discorso lungo).


Proprio così


giusto anche questo


Non sembra, è interessante, tant'è che, pur non essendo velocissimo come bus, è usatissimo ed esistono tantissimi chip che hanno questo tipo di bus, sia digitali che mixed (bus digitale + sezione analogica); tanto per dire esistono anche integrati audio (controlli di volume, di tono e mi sembra anche equalizzatori) pilotati tramite l'I²C (pare che esistano anche degli accelerometri ).


Se voglio fare qualcosa di semplice preferisco optare per un circuito come led+resistenza

------------------------------------------------------------------------------------------------------------

Il circuito che hai disegnato (con paint voto:0 per lo strumento utilizzato, 6-- per il risultato, 10 per l'impegno, 10++ per la pazienza ) è quello giusto, quindi puoi procedere con gli esperimenti.

Hai capito perfettamente come stanno le cose: chip come il PCF8574 sono già pronti per comunicare col primo master che li chiama in causa con lo slave address giusto, senza dovere fare altro.

Il PIC no. Come qualsiasi cosa che vuoi far fare a lui o a qualsiasi altro microprocessore/microcontrollore bisogna scrivere il programma relativo, altrimenti...........nulla.
Che tu faccia accendere un led, fare un calcolo complesso o usare una periferica hardware, tutto passa da un programma più o meno lungo.
Per farti un esempio, quando tu hai scritto il programma del metro a ultrasuoni hai dovuto scrivere anche la parte per inviare i dati su porta seriale oppure no?
Tu l'hai dovuta scrivere, anche se il PIC ha già la UART a bordo che gli permette di comunicare in seriale, perchè occorre settare N parametri per inizializzare la porta e leggere/scrivere nei registri per gestire i dati ricevuti/da inviare.
Il MSSPI è molto simile alla UART, anche se è dedicata a comunicazione sincrona (con clock e dato separati), quindi richiede N linee di programma per funzionare correttamente.


No, Gila, devi portare SCL a 0, infatti in quel modo avrai che la corrispondente linea passare da ingresso a uscita (ti ricordo che SCL e SDA agiscono sul registro TRIS, dove un bit a 1 corrispondente all'ingresso, e quindi ad una linea pulluppata a 1, e un bit a 0 corrispondente all'uscita, e quindi ad una linea pilotata con uno 0).


Se usi il MSSPI l'ACK e un po' di altri dati li puoi trovare sotto forma di byte o flag nei registri SSPSTAT, SSPCON ecc. Se invece usi routine I²C software puoi sempre effettuare la lettura del pin della linea SDA tramite un BTFSC o BTFSS.