protocollo I2C

Si Law....molto sudore

Ho sistemato un po' la routine. é ampiamente commentata. L'errore di lettura detto un po' alla buona era che io andavo a testare la linea sda (quella che "contiene" il bit)
dopo aver fatto il clock, pensando che rimanesse in quello stato...invece no, va testata all'interno del ciclo di clock.

é un po' un casino da spiegare, ma chi ha letto un po' sull'i2c, sa a cosa mi riferisco.

Poi, per quanto riguarda la lettura dei bit entranti, cioè dalla eprom al pic ho fatto in un modo un po' diverso da quello che ho visto in giro.

Se la eprom deve inviare il numero B'11000001', spedirà così:

1 primo bit (cioè il più significativo del numero finale che ricevera il master)
1 secondo bit
0 terzo
0 quarto
0 quinto
0 sesto
0 settimo
1 ottavo

man mano che il registro adibito a buffer del pic li riceve, li shifta verso sinistra per poi avere il numero finale.

Di solito mi pare che la procedura sia questa, io l'ho usata per inviare dati, slave address ecc.
Ma in fase di lettura, faccio in modo diverso.

Mi precarico in un registro il numero 255 B'11111111', ma potrei fare anche B'00000000', basterebbe solo cambiare la logiga del test
Poi, andando a vedere se la linea sda è alta (cioè bit 1 entrante) o bassa (bit zero entrante) faccio:

TESTA SDA: ALTA? SI LASCIA IMMUTATO BIT 0 del registro precaricato
bassa? azzera relativo bit

ecc...
Logicamente al primo test, cioè quando lo slave manda il bit più significativo, io dovrò azzerare o meno il settimo bit del registro... non il primo.


é comunque una bozza...per esempio le varie rotines read andrebbero eliminate e fatta una sola valida per tutti gli otto bit. Funziona bene anche così, ma occupa più memoria di una sola richiamabile
con una CALL

Bhè ragazzi io ci ho provato a farmi capire....ma sono un po' una zappa a spiegarmi

quindi allego il listato

Allego anche la versione del programma di scrittura, con la temporizzazione di 5ms via interrupt al posto di ritardi software che rendono "sordo" il microprocessore/controllore per 5ms.

Molti commenti sono all'interno del programma. L'ho testato fisicamente sulla scheda, e i dati vengono scritt/letti correttamente. Al solito quando andrà integrato in un altro programma
si presenteranno mille gatte da pelare, però per il momento sembra ok

Adesso, aspetto solo di ordinare l'accelerometro...quello che avevo, adesso che l'i2c funziona, l'ho testato ed è davvero andato. Ho provato col programma che trova da solo
lo slave address, che avevo scritto tempo fa, ma nessuna risposta.

Ora, che ho passato un anno a studiarmi l'i2c per l'accelerometro (ma non solo per quello ovviamente), mi accorgo che sul catalogo, c'è anche una versione analogica....
Pazzesco!!!

Mi è arrivato l'accelerometro, e finalmente, mi riconosce lo slave address...ora c'è da studiare per bene l'immenso datasheet... e provare. Speriamo...

peggio!! Ma nel frattempo sono insorte grane inaspettate. Con la eprom, il protocollo i2c mi funziona alla grande, ma con l'accelerometro...la conferma dell'ack, da problemi.

Facendo uno stratagemma, mi sono accorto che da la conferma, ma non subito all'accensione come nel caso della eprom. Non so bene, ma credo sia legato al fatto
che il pic lavora a 5 volts, mentre l'accelerometro a 3.3, anche se 3.3 volts, sarebbero compatibili come livello alto di una porta TTL, come è quella del pic.

Non so, il fatto che riconosca l'ack, è un buon segno, ma ci sarà da sudare. Bisognerebbe alimentare tutto 3.3 volts e vedere se lo fa ancora....mannaggia...sempre grane trovo!

Si Law...devo davvero provare ad alimentare tutto a 3.3 volts, e per fare questo, devo rimuovere il pic dalla scheda...o meglio, programmarlo nella easy pic, e poi montarlo
su una bread board. Ho dei dubbi che riesca a farlo andare. Leggendo sul web, in molti hanno trovato difficoltà. Io non demordo, ma inizio a scoraggiarmi

Ho provato Law...anzi, ho fatto una duplice prova: ho verificato se la eprom alimentandola a 3.3 volts e il pic a 5 v, comunicava correttamente, e il risultato è si, l'i2c comunica bene
quindi i livelli logici sono compatibili. Con l'accelerometro no invece, ma non per una questione di tensioni, ma proprio per come è stato fatto, sul manuale è scritto...ma tralasciamo.

Programmando invece il pic, poi smontandolo dalla scheda e alimentando pic più accelerometro tutto a 3.3 volts, tutto funziona (almeno sembrerebbe). Dovrei trovare il modo di farli comunicare lo stesso
pic a 5 v e acc a 3v, in modo da poter programmare e fare prove tutto sulla scheda di sviluppo, mentre così sono costretto a rimuovere ogni volta il micro dallo zoccolo e montarlo su una bread board...
Da SUICIDIO direi!!!! Bho...se non riesco, non lo so che fare...magari con pazienza e moooolto tempo gliela fò....ma non so

é un po' complessa la cosa da spiegare, se non si ha sottomano tutto. In poche parole, ho appurato che alimentando il pic a 5 volts e la eprom a 3.3 volts e pull-uppando le line scl e sda (comuni a pic ed eprom) alla linea dei 3.3 volts, non si hanno probelmi. Da qui si può capire allora che per i TTL alimentati a 5 volts, un segnale a 3.3 volts, risulta come livello logico 1.
Il problema dell'accelerometro è un altro. Praticamente il modulo MMA7455L che ho preso io, sarebbe un componente smd, ma Futura Elettronica, l'ha cablato su un piccolo pezzo di circuito stampato
con già i pin. Probabilmente hanno fatto dei cablaggi che non mi consentono di far funzionare tutto, tenendo il pic a 5 volts. Danni fisici, non ne arrechi perchè comunque dal pic, i 5 volts non escono mai
proprio per come è configurato il protocollo i2c.
Adesso, smontando tutto, e mettendo pic e accelerometro su bread board, e programmando non più con la easy pic6, ma con l'icd3, l'ack, lo slave address e quant'altro, è riconosciuto perfettamente.
Allego il datasheet di Futura Elettronica, li parla di un ponticello, per me è quello che da rogne:

www.futuraelettronica.net/pdf_ita/5300-M-ACC.pdf

evviva!!! L'accelerometro ha dato il suo primo vagito agitando la scheda (bread board) su cui è montato, vedo la traccia sull'oscilloscopio modificarsi. C'è ancora una montagna di roba da studiare...ma funziona....e doppia gioia: l'accelerometro precedente, non era affatto bruciato, così ora ne ho due.

Certo però che il datasheet, non è affatto chiaro sullo slave address...è la prima volta che trovo un data un po' ambiguo...almeno secondo me: dice che l'indirizzo e $1D cioè 11101 e che in scrittura l'ultimo bit è zero mentre il lettura è 1....verrebbe naturale dire....ma come, se mi dici che è 11101... l'ultimo bit è già 1.
Invece, bisogna intuire di aggiungere 1 o 0 (scrittura o lettura) all'ultimo bit (LSB)

quindi diventerebbe :
LETTURA= 111011
SCRITTURA =111010

ma allora non facevano prima a dire:
111011= $3B (lettura)

e
111010=$ 3A (scrittura)
Direi che sarebbe stato molto più chiaro, no?

Edited by GILA75 - 28/2/2012, 21:55