Comunicazione tra più microcontrollori

Vorrei iniziare a implementare un sistema composto da N microcontrollori (N> = 2 MCU), ma vorrei conoscere le possibilità di farli comunicare tra loro.

Idealmente, i microcontrollori (N-1) sono collocati all'interno della casa fungendo da client, mentre l'ultimo (il "server") è collegato a un PC tramite USB. I problemi che ho ora sono come collegare questi microcontrollori (N-1) al "server". Le MCU dei client eseguono compiti molto semplici, quindi potrebbe non essere una buona soluzione utilizzare ARMs per svolgere tali semplici compiti solo perché forniscono CAN / PHY-MAC .

La comunicazione non avverrà più di una volta ogni pochi minuti per la maggior parte dei dispositivi e su richiesta per altri. La velocità non è molto critica (il messaggio è breve): 1 Mbit / s penso che sia eccessivo per i miei scopi.

Le MCU che intendo utilizzare sono le seguenti.

• Atmel AVR Tiny / Mega
• TI MSP430
• ARM Cortex M3 / M4
• (Forse Atmel AVR UC3 - 32-bit)

Mi piacerebbe evitare i PIC, se possibile (scelta personale), semplicemente perché ci sono meno possibilità di programmarli (tutto quanto sopra ha più o meno strumenti open source e alcuni strumenti ufficiali).

So che alcuni ARM forniscono funzionalità CAN e non sono così sicuro degli altri.

In questo momento ho trovato queste possibilità:

1. GPIO semplice per inviare dati (diciamo> 16 bit in ALTO per indicare l'inizio del messaggio,> 16 bit in BASSO per indicare la fine del messaggio). Tuttavia, deve essere a una frequenza standard << (frequency_client, frequency_server) per poter rilevare tutti i bit. È necessario solo un cavo per MCU client.
2. RS-232 : Penso che questo sia di gran lunga il protocollo di comunicazione più comunemente usato, ma non so quanto si ridimensiona. Sto considerando fino a 64 MCU client in questo momento (probabilmente più avanti)
3. USB: AFAIK questo è principalmente come RS-232, ma in questo caso non penso che si ridimensioni molto bene (anche se USB supporta molti dispositivi - 255 se ricordo bene - potrebbe essere eccessivamente complicato per questa applicazione)
4. RJ45 / Ethernet: questo è ciò che mi piacerebbe davvero usare, perché consente la trasmissione su lunghe distanze senza problemi (almeno con cavo schermato> Cat 6 ). Il problema è il costo (PHY, MAC, trasformatore, ...). Non so se puoi davvero saldarlo bene a casa però. In questo modo non avrei bisogno di un MCU client
5. Wireless / ZigBee : i moduli sono molto costosi, anche se potrebbe essere la strada da percorrere per evitare "spaghetti" dietro la scrivania
6. Moduli / ricetrasmettitori RF: sto parlando di quelli nella banda 300 MHz - 1 GHz, quindi dovrebbero essere difficili da saldare a casa. I moduli sono tutti integrati, ma sono abbastanza costosi come lo ZigBee (almeno i moduli RF di Mouser, a Sparkfun sembrano essere più economici).
7. PUÒ? Sembra essere molto robusto. Anche se non ho intenzione di usarlo in applicazioni automobilistiche, potrebbe essere comunque una buona alternativa.
8. I²C / SPI / UART ? Ancora una volta - meglio evitare "spaghetti" con i cavi se possibile
9. I PLC non sono in realtà un'opzione. Le prestazioni si riducono piuttosto rapidamente all'aumentare della lunghezza e dipende dal carico di capacità della rete elettrica. Penso che il prezzo sia più o meno lo stesso di Ethernet.

Inoltre, quale protocollo sarebbe "migliore" in caso di trasmissioni simultanee (supponiamo il raro caso nello stesso istante in cui due dispositivi iniziano a trasmettere: quale protocollo fornisce il miglior "sistema di gestione dei conflitti" / "sistema di gestione delle collisioni"?

Riassumendo : mi piacerebbe sapere quale potrebbe essere la soluzione migliore per un sistema client distribuito che esegue comunicazioni di dati molto leggere, considerando sia la flessibilità (numero massimo di dispositivi, sistema di gestione di conflitti / collisioni, ...), prezzo , facile da realizzare a casa (saldatura), ... Vorrei evitare di spendere 20 $ solo per il modulo di comunicazione, ma allo stesso tempo avere 30 fili dietro la scrivania farebbe schifo.

La soluzione che sto immaginando in questo momento sarebbe quella di fare comunicazioni di base tra MCU vicine tramite GPIO o RS-232 (a buon mercato !) E usare Ethernet / ZigBee / Wi-Fi su un MCU per "zona" per comunicare con il server ( costoso , ma è ancora molto più economico di un modulo Ethernet per ogni MCU client).

Invece di cavi potrebbe anche essere possibile utilizzare fibre ottiche / fibre ottiche. Sebbene siano necessarie ulteriori conversioni, e non sono sicuro che sarebbe la soluzione migliore in questo caso. Mi piacerebbe sentire ulteriori dettagli su di loro.

CAN suona il più applicabile in questo caso. Le distanze all'interno di una casa possono essere gestite da CAN a 500 kbit / s, il che suona come una grande larghezza di banda per le tue esigenze. L'ultimo nodo può essere un'interfaccia da USB a CAN standardizzata. Ciò consente al software nel computer di inviare messaggi CAN e vedere tutti i messaggi sul bus. Il resto è software se si desidera presentare questo al mondo esterno come un server TCP o qualcosa del genere.

CAN è l'unico mezzo di comunicazione che hai menzionato che in realtà è un bus, ad eccezione del rotolamento tuo con linee I / O. Tutti gli altri sono punto a punto, incluso Ethernet. È possibile rendere Ethernet logicamente simile a un bus con switch, ma le singole connessioni sono ancora punto a punto e ottenere la topologia del bus logico sarà costoso. Anche l'overhead del firmware su ciascun processore è notevolmente superiore a CAN.

La parte bella di CAN è che i pochi livelli di protocollo più bassi sono gestiti nell'hardware. Ad esempio, più nodi possono tentare di trasmettere contemporaneamente, ma l'hardware si occupa di rilevare e gestire le collisioni. L'hardware si occupa dell'invio e della ricezione di interi pacchetti, compresa la generazione e la convalida del checksum CRC.

Le tue ragioni per evitare i PIC non hanno alcun senso. Ci sono molti progetti per i programmatori là fuori per costruire il tuo. Uno è il mio LProg , con lo schema disponibile dal fondo di quella pagina. Tuttavia, costruire il proprio non sarà conveniente a meno che non valuti il ​​tuo tempo in centesimi / ora. Si tratta anche di qualcosa di più del semplice programmatore. Avrai bisogno di qualcosa che aiuti con il debug. Microchip PicKit 2 o 3 sono programmatori e debugger a costi molto bassi. Anche se non ho esperienza personale con loro, sento parlare di altri che li usano abitualmente.

Inserito il:

Vedo alcuni consigli per RS-485, ma non è una buona idea rispetto a CAN. RS-485 è uno standard esclusivamente elettrico. È un bus differenziale, quindi consente più nodi e ha una buona immunità al rumore. Tuttavia, CAN ha anche tutto questo, e molto altro ancora. CAN è di solito implementato anche come bus differenziale. Alcuni sostengono che RS-485 sia semplice da interfacciare elettricamente. Questo è vero, ma lo è anche CAN. In ogni caso lo fa un singolo chip. Nel caso di CAN, l'MCP2551 è un buon esempio.

Quindi CAN e RS-485 hanno praticamente gli stessi vantaggi elettricamente. Il grande vantaggio di CAN è sopra quello strato. Con RS-485 non c'è nulla al di sopra di quel livello. Sei da solo. È possibile progettare un protocollo che si occupa dell'arbitraggio del bus, della verifica dei pacchetti, dei timeout, dei tentativi, ecc., Ma effettivamente ottenere questo risultato è molto più complicato di quanto la maggior parte della gente pensi.

Il protocollo CAN definisce pacchetti, checksum, gestione delle collisioni, tentativi, ecc. Non solo è già presente, pensato e testato, ma il grande vantaggio è che è implementato direttamente in silicio su molti microcontrollori. Il firmware si interfaccia alla periferica CAN a livello di invio e ricezione di pacchetti. Per l'invio, l'hardware esegue il rilevamento colllision, il backoff, i tentativi e la generazione di checksum CRC. Per la ricezione, esegue il rilevamento dei pacchetti, la regolazione dell'inclinazione dell'orologio e la convalida del checksum CRC. Sì, la periferica CAN richiederà più firmware per guidare rispetto a un UART come viene spesso utilizzato con RS-485, ma richiede molto meno codice in generale poiché il silicio gestisce così tanti dettagli del protocollo di basso livello.

In breve, RS-485 è di un'epoca passata e ha poco senso per i nuovi sistemi di oggi. Il problema principale sembra essere la gente che ha usato RS-485 in passato aggrappandosi ad esso e pensando che la CAN sia "complicata" in qualche modo. I bassi livelli di CAN sono complicati, ma lo è anche qualsiasi implementazione RS-485 competente. Si noti che diversi protocolli ben noti basati su RS-485 sono stati sostituiti da versioni più recenti basate su CAN. NMEA2000 è un esempio di tale nuovo standard basato su CAN. Esiste un altro standard automobilistico J-J1708 (basato su RS-485) che ora è praticamente obsoleto con OBD-II e J-1939 basati su CAN.

Consiglierei il controller con CAN poiché questa funzione è pensata esattamente per lo scopo della rete del controller.

RS232 può essere implementato facilmente ma diventerà molto impegnativo se si tenta di implementare la comunicazione più di 2 nodi (perché non è stato creato per questo scopo).

Anche Ethernet può essere una buona opzione poiché hai citato alcune interconnessioni di host e client, che è naturale per l'implementazione Ethernet.

RS-485 che utilizza più fili potrebbe funzionare bene qui, se esiste la possibilità di collegare la stessa linea a tutti i dispositivi.

Se ad esempio viene utilizzato con un cavo di rete di categoria 5e tradizionale, potresti avere due coppie per lavorare per la trasmissione dei dati in entrambe le direzioni (utilizzando un modulo full duplex), avere una coppia o forse anche un solo filo come terra comune e il resto da negoziare quale dispositivo trasmetterà in quale momento. È un po 'più complicato di RS-232, ma i moduli sono più economici di CAN ed Ethernet e il limite del cavo è di 1200 m. L'aspetto negativo è che dovrai creare il tuo protocollo di risoluzione dei conflitti. Forse hai il dispositivo che vuole trasmettere controlla un filo dedicato e vedi se è alto. In caso contrario, portalo in alto e inizia a comunicare e, in caso affermativo, attendi un periodo di tempo casuale. Non sono ancora sicuro di come funzionerebbe su lunghe distanze.

Sceglierei un bus RS-485 che funzioni con i dati di codifica Manchester .

RS-485 perché:

• É economico
• È facile da implementare
• Usa lo potere
• Permette lunghe distanze (fino a 1200 metri)
• Velocità dati elevate (fino a 10 Mbps)
• Elevata immunità alle interferenze
• Esistono transceiver che consentono fino a 256 dispositivi sullo stesso bus
• Conteggio parti basso

Codifica Manchester perché:

• È facile da implementare
• È auto-sincronizzabile

Per integrità dei dati, il messaggio può includere una lunghezza e un campo CRC.

Esempio di una funzione CRC:

unsigned char crc_calc(unsigned char buffer[], unsigned short size)
{
  unsigned long i;
  unsigned char crc;

  crc = CRC_INIT;

  for (i=0;i<size * 8;i++)
  {
    crc = (crc << 1) | (crc >> (7));

    if (buffer[i/8] & (0x80 >> (i%8)))
    {
      crc ^= CRC_POLY;
    }
  }

  return crc;
}

CRC_INITe CRC_POLYsono valori arbitrari utilizzati per calcolare il CRC.

Esempio di un messaggio con campi lunghezza e CRC:

Vorrei confrontare la tua scelta preferita, Ethernet, con la mia scelta preferita, CAN.

Componenti richiesti:

• Ethernet: connettore RJ45, magnetica, chip Phy (se non integrato nell'MCU). Inoltre, sono necessari switch e un cavo dallo switch a ciascun nodo. Ogni PCB ha bisogno di parecchi condensatori e resistenze di terminazione, possibilmente anche ferriti. Ha bisogno di un buon design PCB.
• CAN: chip ricetrasmettitore (economico), qualsiasi connettore, cavo economico può passare da un nodo all'altro in un circuito attorno al sito. È necessario un solo condensatore per il ricetrasmettitore e una resistenza di terminazione a ciascuna estremità del bus.

Stai parlando di microcontrollori da $ 1. C'è molto di più nel costo del bus rispetto alla MCU. Dovrai sommare il costo totale di ogni soluzione per sapere quale è effettivamente più economico. Sommare il costo di MCU, connettori, ricetrasmettitori, componenti passivi, PCB, cavi, ecc.

LPC11C24 di NXP ha anche il ricetrasmettitore CAN integrato e CANOpen supportato nella ROM (non mangia i tuoi dati Flash da 32 K). La scheda LPCXpresso 11c24 costa 20 EUR (ha fornito spazio per il connettore DB9), quindi è sufficiente aggiungere fili :-)

Ripubblicare da un'altra domanda simile. Comunicazione semplice a basso costo tra due microcontrollori

TLDR : non particolarmente economico ma affidabile in alcuni casi d'uso.

Guardando fuori dagli schemi, potrebbero esserci altre soluzioni qui come il seguente chip che ho incontrato di recente. Certo, tutto dipende da cosa vuoi fare. Qualcosa come UART viene in mente se hai entrambi gli MCU sulla stessa scheda o se stai pianificando di proteggerli ESD manualmente se separati.

Soluzione master e dispositivo per applicazioni IO-Link

L6360   Master
L6362A  Device

Quando considereresti una soluzione come questa:

1. I chip di frontiera sono completamente protetti, il che sarebbe importante se ogni MCU fosse su una scheda separata e si trattasse di pin esposti, ad esempio un terminale a vite.
   • Polarità inversa
   • Sovraccarico con funzione di interruzione
   • sovratemperatura
   • Sottotensione e sovratensione
   • Filo aperto GND e VCC
2. Interoperabilità. Se qualcun altro progetterà l'altra parte, tutto ciò che deve sapere è incanalare i dati tramite IO-Link.
3. Regolatore integrato Vcc(in) 7~30v, Vdd(out) 3.3/5v

Mi è sembrato interessante, quindi ho pensato di metterlo fuori.

Dipende dalle dimensioni dell'applicazione e dei microcontrollori. Hai menzionato Atmel tiny / mega, sono piuttosto piccoli. Nel loro caso I2C / SPI / UART hanno il vantaggio di essere implementati nell'hardware e quindi sono facili da usare.