ElectroYou

Buonasera a tutti.
Volevo sottoporvi questo quesito in modo da potermi regolare nello sviluppo / progettazione hardware dei miei dispositivi.

Ho un arduino MEGA 2560 (A) che comunica con altri due moduli arduino (B e C sempre Mega 2560) tramite I2C. i moduli B e C hanno come indirizzo 10 e 12 rispettivamente. La comunicazione è unidirezionale. I moduli B e C ricevono dati ma non trasmettono nulla. Ora sul modulo C ho la necessità di dover collegare un display OLED pilotato tramite I2C tramite la libreria Adafruit_SSD1306-master. l'indirizzo di questo modulo OLED è 60.
Ora il dubbio che mi viene è che collegando questo modulo OLED sulla linea I2C esistente potrebbe darmi problemi sulla attuale comunicazione tra i vari moduli (visto che il modulo C si troverebbe anche a trasmettere....)

Nel caso in cui il problema potrebbe sussistere, volevo sapere se era possibile impostare sul modulo C che la comunicazione I2C oltre che sui pin 20 (SDA) e 21 (SCL) possa avvenire anche su altri pin. Volevo fare questo in modo da mettere il modulo C in ascolto di dati provenienti da A sui pin 30 e 31 mentre la comunicazione con il display OLED continua su 20 e 21.

Grazie

buonasera a te,per la comunicazione i2c è sufficiente rispettare i pin sda e scl(dati e clock),in parallelo e alimentare con negativo comune i singoli dispositivi.I dispositivi hanno un indirizzo che permette di connettere 128 dispositivi per un master e prevedono in base alcune applicazione delle resistenze di pullup,nella tua credo che ne puoi fare a meno..

Il modulo C può anche trasmettere, su interrogazione del master. Oppure può mandare i dati al master, e poi questo ritrasmetterli al display.

No a gianzap e no a EcoTan.

Lo standard ufficiale I2C prevede la funzione multi-master.

Cambia poco rispetto ad un bus I2C normale, ma i master devono implementare due funzioni supplementari:
arbitrazione e detezione di bus occupato.

La prima è realizzata grazie al fatto che il driver è un open-drain (può solo tirare a zero). Se due (o piú) master cominciano a trasmettere contemporaneamente, il primo che trasmette un 1 quando l'altro trasmette 0 perde l'arbitrazione. Trasmettendo un 1 rilascia il bus, se questo non torna a livello logico alto, c'è un altro master attivo, che ha la precedenta e quindi vince.

La seconda è semplice: il master resta in ascolto e aspetta uno STOP prima di iniziare la sua comunicazione.

Boiler

Non ho letto bene,credevo che modulo si riferisse ad Arduino stesso

Beh, in effetti la situazione non è chiarissima...

Boiler

Grazie a tutti per le risposte e scusate per la poca chiarezza. Di seguito spiego meglio cosa vorrei realizzare (e cosa ho già realizzato). E' un po lunga la cosa ....

Il tutto riguarda il campo del modellismo. In pratica sto realizzando un plastico ferroviario per mio figlio (e in primis per me...). Siccome a me non piace tanto l'idea del "compra qualcosa di già fatto e monta" volevo realizzarmi la parte del controllo del traffico con Arduino (in modo da imparare anche cose nuove).

Per ora ho realizzato un modulo master con un arduino mega 2560 (A) a cui ho collegato un display Nextion capacitivo da 7'' sul quale imposto le operazioni di stazione (partenze, arrivi, transiti e movimentazione generale degli scambi). Il Nextion invia al modulo (A) messaggi con le operazioni da eseguire e il modulo (A) provvede direttamente ad concretizzare tramite relè a stato solido il movimento degli scambi. Inoltre tramite la I2C manda le informazioni al modulo B (arduino Nano) che provvede ad impostare lo stato dei segnali.

Attualmente al modulo A è connesso tramite seriale un modulo mp3 con cui eseguo anche i messaggi audio di stazione relativi agli arrivi, partenze e transiti, utilizzando un timer interno che simula lo scorrere del tempo di una giornata ideale (i messaggi audio hanno infatti riferimento "all'orario" della giornata).

Questo è quanto realizzato fino ad ora. la modifica che vorrei fare (e da cui nasce in origine questo post) è la seguente: siccome quando compilo il codice per il modulo (A) mi dice che sono al limite della memoria per le variabili, avevo pensato di spostare la gestione della "giornata ideale" (messaggi audio e gestione del "tempo") all'interno di un altro modulo arduino mega 2560 (C).

Su questo modulo C avevo intenzione di collegare un display OLED piccolino con cui visualizzare l'orario della giornata ideale all'interno del plastico. Quindi questo modulo C trasmette con cadenza di 1 secondo le informazioni al display OLED.

Dalle vostre risposte ho capito quindi che per ottenere quello che voglio con la I2C dovrei implementare una sorta di gestione "ora parlo io. ok ho finito, parla tu" (scusate per l'esempio) ma siccome il modulo (C) invierebbe dati ogni secondo, sarebbe difficile trovare per (A) il "tempo giusto per intromettersi nel discorso"

Ho pensato allora di fare in questo modo: il modulo (A) comunica:
- con il modulo (B) tramite la I2C
- con il modulo (C) tramite la seriale

Alla fine la comunicazione tra (A) e (C) non è tanto "frequente" come quella che (C) fa con il display OLED.

Ancora grazie a tutti per le risposte e per chi ha avuto coraggio di leggere fino a questo punto.

Agatino ha scritto:Dalle vostre risposte ho capito quindi che per ottenere quello che voglio con la I2C dovrei implementare una sorta di gestione "ora parlo io. ok ho finito, parla tu" (scusate per l'esempio) ma siccome il modulo (C) invierebbe dati ogni secondo, sarebbe difficile trovare per (A) il "tempo giusto per intromettersi nel discorso"

Scherzi?
Facciamo un esempio: usi I2C in standard mode a 100 kbit/s.
Il tuo messaggio contiene una ventina di bytes (stima spannometrica a caso) piú un po' di overhead... facciamo 200 bit.
La trasmissione dura 2 millesimi di secondo! Durante il 99.8% del tempo, il modulo C tace. E vuoi dirmi che il modulo A non trova tempo di intromettersi?

Una soluzione simile a quella che stavi addocchiando è però preferibile in ogni caso.
In un plastico ferroviario hai relés, hai la locomotiva che con le spazzole o il pantografo genera scintille, ecc.
L'I2C è un bus nato per essere usato in ambiente molto tranquillo (all'interno di elettronica consumer).
In queste condizioni viene facilmente disturbato (che non è bello) e gli slaves possono andare in crash. Se tirano il bus a zero e non lo rilasciano, bloccano la comunicazione di tutto il plastico (forse anche di cose critiche, come il relé che dovrebbe interromprere l'alimentazione di un treno prima che si schianti contro un altro treno).

Il mio consiglio è di usare l'I2C (se proprio necessario) solo su lunghezze molto brevi, per esempio per collegare un display.

Per la comunicazione tra i moduli usa qualcosa di piú robusto. Io prenderei la RS-485 per la sua economicità e facilità di integrazione. Elettricamente parlando ti servono tre fili: A, B e GND. Puoi collegare dozzine di utenti sullo stresso bus costituito da questi tre fili. È un'interfaccia molto robusta. In condizioni come le tue puoi lavorare senza nessuna fatica a 100 kbps. Se curi un po' il layout (diramazioni, terminazioni, riflessioni,...) arrivi senza problemi a 2 Mbps. In altre parole non avrai sicuramente limiti di capacità.
In software viene gestita come una seriale.

Avresti una topologia di questo tipo


Se in futuro vorrai aggiungere un altro modulo, non ci saranno problemi.
E anche la connessione ad un computer non sarebbe un problema.

Ti consiglio però di pensare ad un protocollo di trasmissione comune a tutti i moduli.
Se ti interessa si può andare avanti a parlarne.

Ciao, Boiler

Ciao Boiler e grazie per la risposta.
Non ho mai usato la RS-485 di cui mi parli. A livello pratico serve un driver esterno da collegare ad arduino per implementare il tutto, oppure può essere gestita direttamente da arduino tramite delle apposite librerie?

Riguardo ai "disturbi" di cui parlavi, fino ad ora ne ho dovuto risolvere solo uno ed era dato dai relè che comandano gli scambi. Avevo infatti utilizzato i comuni moduli a relè meccanici che si trovano in commenrcio un po da tutte le parti, ma quando il relè andava in funzione, mandava in tilt tutto. Ho risolto utilizzando i relè allo stato solido. (...giusto per informazione gli scambi lavorano a 16V c.a.)

Riguardo alla connessione al PC, già riesco a farla e resco a simulare i comandi inviati dal display Nextion in quanto questo comunica con arduino attraverso la seriale 0 e quindi basta collegare la USB ad arduino e resco a gestire tutto da PC.

L'idea di implementare la RS-485 non è che non mi attiri, però alla fine dovrei rivedere un poò tutto (dal punto di vista del protocollo di comunicazione) e questo mi porterebbe via tempo e soprattutto dovrei tenere in "lockdown" il plastico e con mio figlio di 4 anni che vuole passare ogni minuto possibile vicino al plastico insieme a me, sarebbe impossibile.
Alla fine il modulo arduino per la gestione degli MP3 e dell'orario è l'ultimo blocco da realizzare (forse se riesco e ho tempo ci volevo gestire anche una sorta di alba/tramonto ma è ancora in alto mare) quindi penso che alla fine gli invierò i comandi tramite la seriale.
Il discorso della RS-485 lo vorrei però iniziare a studiare e provare, magari solo su board, perché in futuro vorrei realizzare un piccolo plastico modulare e in quel caso potrebbe essermi di aiuto nella comunicazione.

Agatino ha scritto:A livello pratico serve un driver esterno da collegare ad arduino per implementare il tutto, oppure può essere gestita direttamente da arduino tramite delle apposite librerie?

Non saprei, non parlo arduino... ma se googoli "MAX485" vedi che ci sono dei modulini che costano praticamente niente. Come detto, dal punto di vista software sono delle porte seriali. L'unica differenza è che devi dire al modulino se vuoi trasmettere o ricevere. Di solito si usa il segnale RTS.

fino ad ora ne ho dovuto risolvere solo uno

Dovrebbe essere un campanello d'allarme.

Riguardo alla connessione al PC, già riesco a farla e resco a simulare i comandi inviati dal display Nextion in quanto questo comunica con arduino attraverso la seriale 0 e quindi basta collegare la USB ad arduino e resco a gestire tutto da PC.

È tutta un'altra cosa. Se c'è un bus principale, il computer può simulare qualsiasi master o qualsiasi slave. Può immettere comandi supplementari, può sniffare il traffico tra i moduli...

Il discorso della RS-485 lo vorrei però iniziare a studiare e provare, magari solo su board, perché in futuro vorrei realizzare un piccolo plastico modulare e in quel caso potrebbe essermi di aiuto nella comunicazione.

Buon lavoro

Boiler