BaroneRosso.it - Forum Modellismo

BaroneRosso.it - Forum Modellismo (https://www.baronerosso.it/forum/)
-   Circuiti Elettronici (https://www.baronerosso.it/forum/circuiti-elettronici/)
-   -   accellerometro ST & I2c (https://www.baronerosso.it/forum/circuiti-elettronici/267092-accellerometro-st-i2c.html)

faustog_2 09 novembre 12 23:39

accellerometro ST & I2c
 
salve ho preso un Accelerometro della STMicroelctronics, utilizza un LIS302DL, comunica con un protocollo I2C

ecco il datasheet:
http://www.st.com/internet/com/TECHN...CD00135460.pdf

Con Arduino c'è la libreria Wire che ci permette di leggere comodamente.. mi volgio spingere un po piu a fondo anche per capire meglio questo protocollo e avere le idee piu chiare...

Il protocollo seriale I2C con un PIC16F84 - Davide Bucci

MI PERMETTO DI COMMENTARE IL CUORE DELLA TRASMISSIONE:

LOOP
BCF PORTB,0 ; ASSICURA UNO 0 ALLA LINEA CLOCK
RLF DATO,F ;PONE IN C DI STATUS IL BIT + SIGNIFICATIVO
BCF PORTB,1 ; ASSICURA 0 ALLA LINEA DATI
BTFSC STATUS,C ; LEGGE IL BIT + SIGNIFICATIVO
BSF PORTB,1 ; se == 1 allora scrive 1 nella SDA
CALL DELAY ; altrimenti attesa lascia a zero la SDA
BSF PORTB,SCK ; pone a 1 la SCK
CALL DELAY

DECFSZ TMP,F ; esegui 8 volte dopo di che esci
GOTO LOOP
return

faustog_2 12 novembre 12 21:12

c'è qualcosa che non mi convince
 
salve a tutti,

mi rivolgo a chi ha maggiore pazienza !!

leggendo il documento seguente:

Il protocollo seriale I2C con un PIC16F84 - Davide Bucci

trovo qualcosa che nn mi convince, per quando concerne la parte della ricezione, da nessuna parte leggo BSF I2CTRIS, SCL
ovvero da nessuna parte pone SCL come input.... chiedo se la mia osservazione è corretta?

a presto fausto

MSchiepp 12 novembre 12 23:46

Citazione:

Originalmente inviato da faustog_2 (Messaggio 3483741)
...ovvero da nessuna parte pone SCL come input.... chiedo se la mia osservazione è corretta?

a presto fausto

Se guardi nel codice originale (quello postato nel link) vedrai che l'assegnazione di I/O è giusto qualche riga sopra la parte che hai estratto tu...

Michele

faustog_2 13 novembre 12 07:04

okkio
 
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..

bsf I2CPORT, SCL (pone valore alto !)

Quindi il dubbio rimane!

Adesso sposto l'attenzione all'accelerometro... ..perchè In questo link c'è un esempio di come usare l'accelerometro on Arduino, per il momento ho solo dato una lettura, ancora nn ho provato a metterci le mani.

Arduino & LIS302DL


dove I2C_ADDRESS dovrebbe essere 28 ..anche se nel codice non c'è la #define, l'autore spiega sopra che l'indirizzo per I2C è proprio 28

qui spiega alcune cose utili specie per la velocità 100 oppure 400 Hz

Tripple Axis Accelerometer - LIS302DL - bildr

a dopo

Citazione:

Originalmente inviato da MSchiepp (Messaggio 3484037)
Se guardi nel codice originale (quello postato nel link) vedrai che l'assegnazione di I/O è giusto qualche riga sopra la parte che hai estratto tu...

Michele


MSchiepp 13 novembre 12 08:05

Citazione:

Originalmente inviato da faustog_2 (Messaggio 3484170)
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 13 novembre 12 11:48

???
 
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!


Citazione:

Originalmente inviato da MSchiepp (Messaggio 3484208)
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 13 novembre 12 12:03

OKkio
 
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


Citazione:

Originalmente inviato da faustog_2 (Messaggio 3484486)
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 13 novembre 12 12:20

LIS302DL & Pic
 
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 13 novembre 12 13:52

Citazione:

Originalmente inviato da faustog_2 (Messaggio 3484499)
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 13 novembre 12 15:11

sok
 
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

Citazione:

Originalmente inviato da MSchiepp (Messaggio 3484707)
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 14 novembre 12 17:46

un po aggressivo
 
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


Citazione:

Originalmente inviato da MSchiepp (Messaggio 3484707)
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 14 novembre 12 18:04

-- ?? --
 
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

Citazione:

Originalmente inviato da faustog_2 (Messaggio 3486765)
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 14 novembre 12 20:25

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

:yeah:

faustog_2 14 novembre 12 23:39

okkio
 
1 Allegato/i
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



Citazione:

Originalmente inviato da ElNonino (Messaggio 3487042)
@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.).

:yeah:


faustog_2 15 novembre 12 10:35

OK faccio un passo indietro
 
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 15 novembre 12 14:11

Citazione:

Originalmente inviato da faustog_2 (Messaggio 3486765)
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 17 novembre 12 11:14

Ok ci sono riuscito!
 
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 20 novembre 12 19:26

ok ci sono riuscito!
 
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 21 novembre 12 10:10

Spi
 
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


Citazione:

Originalmente inviato da ElNonino (Messaggio 3487042)
@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.).

:yeah:


faustog_2 08 dicembre 15 11:54

qualcosa si muove!
 
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


Tutti gli orari sono GMT +2. Adesso sono le 02:57.

Basato su: vBulletin versione 3.8.11
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
E' vietata la riproduzione, anche solo in parte, di contenuti e grafica. Copyright 1998/2019 - K-Bits P.I. 09395831002