accellerometro ST & I2c

[MSchiepp]

Originalmente inviato da faustog_2

attenzione mettendo ad (uno) il bit di posto SCL (zero) di I2CPORT non stai settando la porta come input, ma stai mettendo semplicemente valore alto..

Infatti SCL è la linea di clock e non deve essere messa in ingresso, è il dato (SDA) che viene dichiarato come uscita durante l'operazione di scrittura e in ingresso durante la lettura del dato e la lettura del bit di ack.

Michele

[faustog_2]

allora c'è qualcosa che mi sfugge.. dunque.... supponendo che ci sia il master (per esempio un Pic16F84 ) ..che decide di comunicare con lo slave il sensore LIS302DL ...dopo aver concordato l'indirizzo SAD e dopo aver preso l'ack ...inizia la vera e propria comunicazione ..che si avvale di due linee.... in cui il Mastrer deve ascoltare x entrambe.. quindi per entrambe deve avere una modalità di lettura Input, quindi mi aspetto anche

BSF TRISB, 0
oltre che
BSF TRISB,1

invece non c'è! ..non esiste nel codice sorgente!

In teoria il master dovrebbe ascoltare su entrambe le linee, quindi modalità Input per entrambe. Appena arriva un fronte di salita sulla SCL ...allora prende per buono il valore :alto, basso che legge nella SDA.

..dalla tua risposta intuisco ...di non aver capito qualcosa da questo protocollo!

Originalmente inviato da MSchiepp

Infatti SCL è la linea di clock e non deve essere messa in ingresso, è il dato (SDA) che viene dichiarato come uscita durante l'operazione di scrittura e in ingresso durante la lettura del dato e la lettura del bit di ack.

Michele

[faustog_2]

rileggendo il sorgete in ASM e la tua risposta ho dedotto il funzionamento corretto.. dunque Il master legge dalla SDA solo dopo aver scritto sulla SCL un bit Alto (uno) .. come dire.... DAMMI UN BIT DEL BYTE DA RICEVEREEEE !

per cui è essenziale che SCL sia di uscita per il master , mentre l'SDA di ingresso.. in questo modo si spiega il perchè..

spero d'aver centrato il concetto ..purtroppo usando le classi pronte di Arduino queste cose non si imparano, rimangono concetti inesplorati...

a dopo
fausto

Originalmente inviato da faustog_2

allora c'è qualcosa che mi sfugge.. dunque.... supponendo che ci sia il master (per esempio un Pic16F84 ) ..che decide di comunicare con lo slave il sensore LIS302DL ...dopo aver concordato l'indirizzo SAD e dopo aver preso l'ack ...inizia la vera e propria comunicazione ..che si avvale di due linee.... in cui il Mastrer deve ascoltare x entrambe.. quindi per entrambe deve avere una modalità di lettura Input, quindi mi aspetto anche

BSF TRISB, 0
oltre che
BSF TRISB,1

invece non c'è! ..non esiste nel codice sorgente!

In teoria il master dovrebbe ascoltare su entrambe le linee, quindi modalità Input per entrambe. Appena arriva un fronte di salita sulla SCL ...allora prende per buono il valore :alto, basso che legge nella SDA.

..dalla tua risposta intuisco ...di non aver capito qualcosa da questo protocollo!

[faustog_2]

di seguito c'è la codifica per far comunicare un Pic16F88 con il LIS302DL, ovviamente tale sorgente può essere trasportato su qualunque Pic equivalente. Comuque dal sorgente si possono conoscere i dettagli per la comunicazione con il sensore http://www.sparkfun.com/datasheets/S...2DL-Tester.zip


qui c'è il link della sparkfun per LIS302DL:
https://www.sparkfun.com/products/8658?

[MSchiepp]

Originalmente inviato da faustog_2

rileggendo il sorgete in ASM e la tua risposta ho dedotto il funzionamento corretto..
...spero d'aver centrato il concetto ..purtroppo usando le classi pronte di Arduino queste cose non si imparano, rimangono concetti inesplorati...

Fausto, invece di dedurre e supporre c'è un altro sistema per imparare le cose: studiarle! Sul sito NXP trovi tutta la documentazione sul bus I2C, ma un minimo di base su cosa sono una comunicazione sincrona ed una asincrona ci vuole!!!!

Michele

[faustog_2]

ciao ...ok ho fatto lo studio sul seriale asincrono ho fatto diverse applicazioni, con 14F84, 628, 876 ecc..

non mi sono mai cimentato con I2C.. tranne che su Arduino usando le librerie, avevo dato una lettura superficiale ed erroneamente credevo d'aver letto che x il master in fase di ricezione i due bus fossero di lettura entrambi ..invece ho interpretato male.. tutto qui..
Adesso leggendo il codice sorgente in assembler confrontandomi con te mi sono studiato nei dettagli sto protocollo sincrono .. mi fa piacere aver compreso il codice in assembler punto a punto ...da esso traggo il miglior insegnamento

a dopo
e grazie per la pazienza

Originalmente inviato da MSchiepp

Fausto, invece di dedurre e supporre c'è un altro sistema per imparare le cose: studiarle! Sul sito NXP trovi tutta la documentazione sul bus I2C, ma un minimo di base su cosa sono una comunicazione sincrona ed una asincrona ci vuole!!!!

Michele

[faustog_2]

comunque MSchiepp sei stato piuttosto aggressivo nei miei confronti, non credi? sul fatto di dove studiare io ti ringrazio, e ti ringrazio sul fatto che hai speso qualche minuto della tuta vita a leggere la mia discussione.. ..però un attimino ti invito ad essere un po piu calmo. Io ho trovato un link interessante magari gli dai una lettura potrai confermare...
Gioblu robotics | Il protocollo I2C | Bit, Master, Slave, Bus, Dati

a dopo

Originalmente inviato da MSchiepp

Fausto, invece di dedurre e supporre c'è un altro sistema per imparare le cose: studiarle! Sul sito NXP trovi tutta la documentazione sul bus I2C, ma un minimo di base su cosa sono una comunicazione sincrona ed una asincrona ci vuole!!!!

Michele

[faustog_2]

se ci rifletti una comunicazione seriale sincrona può avvenire anche nella modalità da me ipotizzata, ovvero uno dei due personaggi della comunicazione legge dalla SCL... se legge un segnale alto.. allora va a leggere sulla SDA, quindi uno dei due personaggi legge su entrambe le linee.. l'altro invece scrive su entrambe le linee. Ok non è nel caso della I2C, ok chiudo

fausto

Originalmente inviato da faustog_2

comunque MSchiepp sei stato piuttosto aggressivo nei miei confronti, non credi? sul fatto di dove studiare io ti ringrazio, e ti ringrazio sul fatto che hai speso qualche minuto della tuta vita a leggere la mia discussione.. ..però un attimino ti invito ad essere un po piu calmo. Io ho trovato un link interessante magari gli dai una lettura potrai confermare...
Gioblu robotics | Il protocollo I2C | Bit, Master, Slave, Bus, Dati

a dopo

[ElNonino]

@Fausto: il protocollo, sia hw che sw, del bus I2C è nato come single master multi slave, uno comanda gli altri ubbidiscono, in qualche modo è simile al Profi-BUS nativo.

In effetti è possibile connettere anche 2 master fra loro e farli cooperare/dialogare per gestire gli slave, è però una configurazione limite e piuttosto pericolosa come affidabilità, se a questo aggiungi una bassa velocità di comunicazione ed una scarsa efficienza (basso payload) tutto ciò rende il protocollo I2C adatto ad applicazioni con pochi slave, poco rischiose e con latenze lunghe.

Personalmente preferisco operare le comunicazioni in sistemi multi-master e multi slave utilizzando la SPI localmente e protocolli più sofisticati su distanze maggiori (Profi-BUS, CAN-BUS etc.).

[MSchiepp]

Originalmente inviato da faustog_2

comunque MSchiepp sei stato piuttosto aggressivo nei miei confronti, non credi? ...

No, non credo; mi spiace che te la sia presa così male, ma volevo solo esprimere il mio personalissimo punto di vista: su questi argomenti c'è tantissima letteratura che spiega sia i principi di base che le particolari implementazioni e credo che studiare questa letteratura sia il modo più diretto per imparare.
Analizzare del codice (che in rete spesso è anche scritto male, se non addirittura sbagliato!) e voler 'imparare' da questo come funziona una cosa a livello più generale mi sembra un approccio concettualmente sbagliato, ma ovviamente sei libero di fare come credi.

Michele