Comunicazione tra più microcontrollori

[mdc93]

Ciao a tutti,

ho una domanda relativa alla comunicazione tra più microcontrollori.

Ho da leggere un’infinità di sensori per cui ho deciso di clusterizzarli facendo sì che N sensori fossero letti da un micro, altri N da un altro micro e cosi via. I valori devono essere visualizzati su un live plot su pc. Quindi pensavo a più micro slave che inviano dati ad un master ed il master via UART invia tutto il pacchetto al pc. Ho provato la comunicazione in I2C tra i vari micro slave ed il master e funziona, ma mi chiedo se ci sia un modo ancor più veloce rispetto a I2C. Il CAN per esempio (mai provato) potrebbe essere più efficiente e veloce? Oppure altri protocolli CABLATI.

[Livio Orsini]

10 ore fa, mdc93 ha scritto:

Il CAN per esempio (mai provato) potrebbe essere più efficiente e veloce?

 

CAN bus, oltre ad essere complesso da gestire, non è molto veloce. Se i micro  sono fisicamente vicini tra loro, la comunicazione più efficiente è ancora o I2C o SPI.

[Ctec]

SPI usa più piedini, ma è decisamente più veloce. E non devi "protocollare" nulla, invii pacchetti di byte, magari con un checksum finale

[mdc93]

Allora per quanto riguarda il CAN (non ancora provato ma sono in arrivo le schedine che montano il CAN controller MCP2515 ed il transcriver) non dovrei implementare il protocollo da zero visto che fortunatamente ci sono le librerie del mondo Arduino anche per ESP32. Per quanto riguarda la velocità il CAN però teoricamente può arrivare anche a 1Mbit/s, o sbaglio? Ciò chiaramente dipende anche da come sono scritte le librerie CAN per Arduino. Per quali distanze massime sono usabili I2C o SPI? Il CAN forse ha la solidità di essere differenziale a differenza dei due, però ecco non so quanto questo possa essere impattante per distanze inferiori al metro.

[Livio Orsini]

I2C e SPI non sono fatti per lunghe distanze; se vai avelocità elevata la distanza è limitata <1m circa (cito a memoria, per dati precisi bisogna consultare le specifiche ufficiali dei 2 bus).

CAN è sicuramente più robusto perchè è il bus di campo del settore automotive. Prorpio per questo motivo vengono fatti numerosi controlli durante la negoziazione dei emssaggi.

 

La tua applicazione in quale ambiente è inserita? Domotica? Industriale? Altro?

[Ctec]

Dunque, il CAN è differenziale (lavora su bus RS485 a 2 fili), ed è più sicuro per connessioni lunghe (parecchi metri). Ma per comunicare tra processori non ce lo vedo.

Te dovresti avere un master che interroga a polling (ciclicamente) i vari slave che leggono i sensori. Sostanzialmente, avrai sempre un numero noto di bytes da ricevere da ciascuno slave.

Fino a un metro, ho usato in passato anche l'I2C a velocità 400kbps e 1Mbps, anche usando filacci brutti senza problemi, principalmente per periferiche I/O.

Se dovevo fare scambi tra micro (o andare su display TFT), ho sempre preferito la SPI, mandata anche a 10Mbps, per letture da periferiche un po' tipo il tuo caso. Sempre con distanze intorno a 1, max 2m. Oltre non ho mai provato.

Lo I2C può essere multimaster, lo SPI è singlemaster, ma per la tua applicazione mi pare adeguato.

Tieni presente che I2C e SPI non sono veri e propri protocolli, non definiscono frame di trasmissione particolari, eccetto i bit di start/stop. Il numero di byte scambiati dipende da te. E per applicazioni simili (io penso a monoscheda o schede separate ma in apparecchi compatti), non ci vedo problemi. La I2C va calcolata bene per le resistenze di pull-up secondo le capacità dei cavi/piste. SPI, essendo push-pull, deve rispettare le capacità di specifica.

Ah, non l'ho mai fatto, ma lo SPI è anche full-duplex, quindi può trasmettere e ricevere contemporaneamente.

[mdc93]

7 ore fa, Ctec ha scritto:

Dunque, il CAN è differenziale (lavora su bus RS485 a 2 fili), ed è più sicuro per connessioni lunghe (parecchi metri). Ma per comunicare tra processori non ce lo vedo.

Te dovresti avere un master che interroga a polling (ciclicamente) i vari slave che leggono i sensori. Sostanzialmente, avrai sempre un numero noto di bytes da ricevere da ciascuno slave.

Fino a un metro, ho usato in passato anche l'I2C a velocità 400kbps e 1Mbps, anche usando filacci brutti senza problemi, principalmente per periferiche I/O.

Se dovevo fare scambi tra micro (o andare su display TFT), ho sempre preferito la SPI, mandata anche a 10Mbps, per letture da periferiche un po' tipo il tuo caso. Sempre con distanze intorno a 1, max 2m. Oltre non ho mai provato.

Lo I2C può essere multimaster, lo SPI è singlemaster, ma per la tua applicazione mi pare adeguato.

Tieni presente che I2C e SPI non sono veri e propri protocolli, non definiscono frame di trasmissione particolari, eccetto i bit di start/stop. Il numero di byte scambiati dipende da te. E per applicazioni simili (io penso a monoscheda o schede separate ma in apparecchi compatti), non ci vedo problemi. La I2C va calcolata bene per le resistenze di pull-up secondo le capacità dei cavi/piste. SPI, essendo push-pull, deve rispettare le capacità di specifica.

Ah, non l'ho mai fatto, ma lo SPI è anche full-duplex, quindi può trasmettere e ricevere contemporaneamente.

Io pensavo di avere i vari micro ( chiamiamoli slave) che acquisiscono in loop un numero elevato di sensori ed uno “centrale” che interroga i singoli slave che una volta interrogati inviano il pacchetto di byte.

Per adesso ho provato 1 master (ESP32) e 3 slave (2 ESP32 + 1 Particle Argon) ma non riesco a superare i 220kHz di velocità di clock utilizzando la libreria Wire.

Ho provato anche 4 slave (3 ESP32 + 1 Argon) e 1 master (Raspberry) ma il Raspi non ha un vero e proprio i2c ma ha SMBUS per cui è limitato a 32 byte di richiesta ogni volta (ogni micro ne invia 64) quindi devo richiedere 2 volte 2 pacchetti da 32 byte. I pull up che ho inserito sono i classici 4.7k (il raspberry ha già on board 1.8k). Possibile sia sbagliato il valore è che per andare più veloce debba abbassarla?

Considerando di inviare 64 byte andando a 220kHz di clock dovrei metterci 64*(1/22000) s circa 3 ms per micro (un po’ lento per la mia applicazione)

Proverò SPI ma in quel caso avrei bisogno di un CS per ogni slave, oppure posso fare daisy chain?

Modificato: 7 dicembre 2023 da mdc93

[Livio Orsini]

7 ore fa, mdc93 ha scritto:

Proverò SPI ma in quel caso avrei bisogno di un CS per ogni slave, oppure posso fare daisy chain?

 

No devi avere i CS per poter mandare in tree state il data out;questo perchè clock, data in e data out sono tutti in parallelo sullo stesso bus.

Te lo richiedo: quale è l'applicazione di questa raccolta dati da sensori?

[mdc93]

1 ora fa, Livio Orsini ha scritto:

 

No devi avere i CS per poter mandare in tree state il data out;questo perchè clock, data in e data out sono tutti in parallelo sullo stesso bus.

Te lo richiedo: quale è l'applicazione di questa raccolta dati da sensori?

Scusami Livio è medicale. 

[Livio Orsini]

1 ora fa, mdc93 ha scritto:

Scusami Livio è medicale.

 

Perbacco! Mi incuriosisce parecchio. Cosè una raccolta di parametri del corpo umano?

[Ctec]

Si, purtroppo con SPI ti ci vuole un CS per ciascuno. Ma è sempre possibile multiplexarli (che so, 4 pin per selezionare uno di 16 slave!!!).

E' possibile fare il daisy-chain, qui trovi un bel tutoria Texas. Personalmente non l'ho mai fatto.

Però mi pare strano che tu sia limitato a 220kHz con I2C. La velocità di 400kHz oramai è il minimo, e ti assicuro che i driver HAL o CMSIS per STM32 funzionano perfettamente almeno fino a 1MHz (tra l'altro sia SPI che I2C per STM32 lavorano in DMA è sono anche per questo velocissimi e puoi fare altro nel frattempo).

Anche con ESP32 dovresti andare bene.

Occhio alle librerie di Arduino, che spesso per essere troppo generiche finiscono per essere inefficienti. Per esempio io ho rifatto la libreria SPI per mandare un TFT con STM32 e come minimo ho raddoppiato la velocità.

[mdc93]

8 minuti fa, Ctec ha scritto:

Si, purtroppo con SPI ti ci vuole un CS per ciascuno. Ma è sempre possibile multiplexarli (che so, 4 pin per selezionare uno di 16 slave!!!).

E' possibile fare il daisy-chain, qui trovi un bel tutoria Texas. Personalmente non l'ho mai fatto.

Però mi pare strano che tu sia limitato a 220kHz con I2C. La velocità di 400kHz oramai è il minimo, e ti assicuro che i driver HAL o CMSIS per STM32 funzionano perfettamente almeno fino a 1MHz (tra l'altro sia SPI che I2C per STM32 lavorano in DMA è sono anche per questo velocissimi e puoi fare altro nel frattempo).

Anche con ESP32 dovresti andare bene.

Occhio alle librerie di Arduino, che spesso per essere troppo generiche finiscono per essere inefficienti. Per esempio io ho rifatto la libreria SPI per mandare un TFT con STM32 e come minimo ho raddoppiato la velocità.

Cercando un po’ in rete qualcun altro (https://github.com/espressif/esp-idf/issues/8290) ha avuto il mio stesso problema. Proverò a fare l’upgrade come indicano, bello il mondo Arduino che tutte le librerie che facilitano, ma quando vuoi “spingerti” un pochino sono estremamente inefficienti. La stessa cosa mi è successa anche con la funzione per leggere da un pin analogico che impiegava 150 us per una lettura :(.