accellerometro ST & I2c

[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.).

[faustog_2]

o.. che piacere ..son contento che sei entrato in questa discussione... ..dunque.. ad un mio ex-collega gli avanzava un ACCELEROMETRO A TRE ASSI.. me lo ha regalato.. ...il dispositivo ha dentro un LIS302DL

http://www.st.com/internet/com/TECHN...CD00135460.pdf

Mi son detto vediamo un pò se riesco a prelevare i dati... ..qualche giorno fa, ho letto questo tutorial.. che sebbene lavora su un 16F84... permette di capire chiaramente passo passo le fasi della comunicazione I2C

Il protocollo seriale I2C con un PIC16F84 - Davide Bucci

Oggi pomeriggio ho letto da questo link, piu completo soprattutto la parte che riguarda gli indirizzi degli Slave.

Gioblu robotics | Il protocollo I2C | Bit, Master, Slave, Bus, Dati

lo trovo completo, inoltre spiega cose che altrove non avevo ancora letto ovvero la gestione degli indirizzi degli Slave come possono essere gestiti ecc..

Adesso cerchero di incrociare le informazioni della documentazione, con quelle del software per arduino.. .in modo da capire..

Arduino & LIS302DL

in attach una foto del device

Originalmente inviato da 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.).

[faustog_2]

ok... Elnonio ..seguo il tuo consiglio... ...credo che ascoltare i tuoi consigli sia una cosa molto saggia... ..per cui cambio strategia ..provo a studiare qui:

L'interfaccia SPI

a dopo
fausto

[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

[faustog_2]

ok fatto, ci son riuscito.. con la scusa ho studiato bene il protocollo I2C e l' SPI ...anzi adesso voglio vedere se riesco anche con l ' SPI... credo di essere vicino alla soluzione... ... l'SPI sembra piu semplice da gestire... ..però mai sbottonarsi prima di aver raggiunto la soluzione.... ...poichè siamo a sabato.. adesso stacco continuerò a partire da lunedì... adesso prendo la mia MountainByke e vado in montagna.. un abbraccio a tutti.

[faustog_2]

facendo una semplice stampa dei dati su porta seriale, e facendo roteare il device ...scopro che i valori letti oscillano tra 0 e 55, oppure tra 255 e 194 ..insomma non sfruttano la profondità del byte...

COMUQUE FUNZIONA

[faustog_2]

ciao in merito a SPI credo d 'aver trovato un ottimo riferimento qui, una guida completa che parte dalla teoria e finisce con la pratica :

Using Serial Peripheral Interface (SPI) Master and Slave with Atmel AVR Microcontroller | ermicroblog

In merito al LIS302DL e la lettura dell'accelerometro:

I pin da usare :

SS pin 10 PWM
SDI pin 11 PWM
SDO pin 12 digital pin
SCK pin 13 digital pin


QUINDI PER RICEVERE I DATI DAL DEVICE OCCORRE

digitalWrite(slaveSelectPin,LOW); abbassa l' SS quindi start SCK
byte value_X = SPI.transfer(address); riceve il valore registrato all'indirizzo
digitalWrite(slaveSelectPin,HIGH);



adress [X,X,X,X,X,X,0,0]
byte [0,0,0,0,0,0, 0,1]

adress |= (2 << 0x01);


A

Originalmente inviato da 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.).

[faustog_2]

dunque a distanza di tempo
ho ripreso l'argomento, in pratica sto usando un pic 12F629, uno dei piu piccoli micro , giusto per dare un valore didattico, al momento sono riuscito ad ottenere l' ack dal dispositivo..

il dialogo è il seguente

- invio Condizione di START
- invio BYTE di ID dispositivo con modalità W
- condizione di ascolto per ricevere l'Ack

(fin qui ok ricevo l'ack dal device)

-adesso dovrei inviare nuovamente l'indirizzo di prima con il bit più singnificativo posto a UNO, se desidero l'auto incremento altrimenti ZERO
-dovrei aspettare nuovamente l'Akc
- invio Condizione di START
- invio BYTE di indirizzo dato a 7 bit con in più il bit per dire Read (ho intenzione di leggere)


a voi eventuali consideraazioni