Comunicazione tra più microcontrollori


20

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.


2
Esistono PIC con funzionalità CAN e strumenti ufficiali gratuiti per programmarli con la documentazione.
AndrejaKo

@AndrejaKo PIC non ha davvero un compilatore open source come AVR o almeno MSP430. È vero che spesso offrono più funzionalità rispetto alle MCU che ho elencato sopra allo stesso prezzo. Non mi piacciono molto queste grandi differenze tra le famiglie del 16/12/18/24/32 e che alcune di queste non hanno affatto un compilatore gratuito (penso che sia PIC18).
user51166,

2
In realtà PIC18 ha un compilatore gratuito e così anche altri. Il vantaggio principale di altre famiglie è che lavorano con GCC. Nel campo open source, c'è il compilatore C per dispositivo piccolo che dovrebbe supportare i dispositivi PIC 16 e PIC 18.
Andreja,

2
Se non hai esperienza con nessuno degli UC di cui hai già parlato, tieni presente che ARM è molto più difficile da iniziare rispetto ad esempio ai PIC o all'AVR, soprattutto se vuoi passare all'open source. Con ARM i fornitori non progettano il core, e generalmente non forniscono un IDE, il che può rendere il tutto un po 'più complesso. È bello avere ad es. Microchip fornire e supportare tutto nel caso di PIC.
Oli Glaser,

@OliGlaser Bene ... mentre è vero che gli strumenti open source per ARM possono essere un po 'difficili da usare (ho provato una scheda di rilevamento STM32 e non ha funzionato molto bene), molti fornitori offrono un IDE che è - con i suoi pro e contro - basati su eclipse e gratuiti: LPCXpresso (NXP) e Code Composer Studio (TI) per esempio (non open-source, ma almeno supportati). D'altra parte, gli AVR sono supportati abbastanza bene sul lato open source, così come in ATMEL STUDIO 6. Nessuna esperienza con PIC. Solo codice AVR (assemblatore) e ARM (C, su NDS).
user51166,

Risposte:


22

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.


costruire la mia scheda personalizzata è utile quando si integra l'MCU con l'hardware che ha attorno. Ai fini dello sviluppo, sono d'accordo che un kit di sviluppo sia un modo migliore. La mia ragione per evitare PIC è la loro mancanza di compilatori open source (ce ne sono alcuni gratuiti, ma non per PIC18 per esempio) piuttosto che una mancanza di schemi pubblici disponibili, sebbene forniscano alcune funzionalità aggiuntive che potresti non trovare in altri MCU (Ethernet, PUÒ, ...). E I2C è un autobus AFAIK.
user51166,

@ user51166 - Esistono compilatori PIC18 gratuiti forniti da microchip. Vedi la pagina del prodotto Compilatori MPLAB XC . Elenca anche i compilatori per uC a 16 bit e 32 bit.
PetPaulsen,

@ user51166 C'è anche anche il compilatore C18 gratuito .
AndrejaKo

@PetPaulsen Strange. Sono abbastanza sicuro di aver visto un mese fa una pagina in cui erano elencati tutti i compilatori liberamente disponibili per il download (PIC16 / 24/32), ad eccezione del PIC18 che non era dovuto a qualche problema di licenza che avevano. Probabilmente questo è stato risolto con il compilatore MPLAB C di transizione -> Compilatore MPLAB XC anche se non ne sono sicuro. Inoltre offrono "solo" un'edizione freeware che non ottimizza il tuo codice, non un compilatore completamente open source. Comunque è meglio di niente;)
user51166

@utente: credo che tutti i compilatori Microchip abbiano versioni gratuite che differiscono solo da quelle complete in quanto alcune delle ottimizzazioni sono disabilitate. L'assemblatore, il bibliotecario, il linker e il simulatore sono tutti inclusi nel pacchetto MPLAB gratuito. Non c'è davvero nessun problema qui.
Olin Lathrop,

6

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.


Quali sono i vantaggi di CAN over Ethernet, ad esempio? Più economico probabilmente, ma a parte questo, cos'altro?
user51166,

@ user51166 - CAN non è solo più economico ma molto più economico. Non è solo più semplice, ma molto più semplice.
Rocketmagnet,

@Rocketmagnet: per favore, spiega un po 'di più. Nella maggior parte dei casi è comunque necessario un IC integrato (anche se PIC, ARM e altri? Spesso integrano la funzione CAN, sono un po 'costosi). Da un punto di vista hardware non vedo come questo possa essere molto più economico poiché i circuiti integrati possono essere trovati per 0,5-1,0 $ al pezzo. Suppongo che intendi più facile dal punto di vista del software, giusto? CAN ha una distanza massima di ~ 500 metri che è sicuramente abbastanza nel mio caso, ma - solo per informazione - ci sarebbero alternative simili per distanze più lunghe (forse la fibra ottica)?
user51166,

4

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.


Non preoccuparti di lunghe distanze, al momento non ho intenzione di superare i 100 metri.
user51166,

Perché oggi BTW stackexchange non accetta @ <nomeutente>? Ogni volta che ne inserisco uno, viene completamente eliminato (non solo il simbolo @) ...
user51166

@ user51166 - Il creatore della risposta viene automaticamente avvisato, quindi "\ @ - noise" viene rimosso automaticamente. (Il mio \ @ user51166 non è stato rimosso, perché non sei il creatore di questa risposta)
PetPaulsen,

La cosa interessante è che non ho ricevuto notifiche per nessuno dei commenti qui.
AndrejaKo

4

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:

Esempio di messaggio


Qualche suggerimento per ricetrasmettitori così buoni, forse economici?
user51166,

Inoltre, come suggerito da @AndrejaKo, RS-485 non sembra offrire un protocollo di risoluzione dei conflitti.
user51166,

La scelta dei ricetrasmettitori dipende dalla tensione che si intende utilizzare. La risoluzione dei conflitti deve essere effettuata in software con controllo CRC, monitoraggio della linea o entrambi.
Bruno Ferreira,

Se disponi di un master, puoi anche implementare un tipo di indirizzamento o una trasmissione basata su turni.
Bruno Ferreira,

Non proprio un maestro. Solo il "server" che funge da interfaccia per il PC tramite USB. I clienti devono comunque inviargli automaticamente dei messaggi ...
user51166

3

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.


0

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 :-)


0

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

inserisci qui la descrizione dell'immagine

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.


-3

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.


3
OK, ma come risolve il problema del PO? IIC è un autobus, ma in realtà non è adatto a lunghe distanze come attraverso una casa. È a terminazione singola e impedenza relativamente elevata. SPI è un bus, ma controllato da un singolo master con una linea di selezione slave separata per ciascun dispositivo. È possibile implementare ogni linea come coppia differenziale con driver di linea e ricevitore, ma si ha ancora il problema da punto a punto master a selezione slave. UART è strettamente punto a punto. Non è chiaro come intendi utilizzarli nella situazione del PO.
Olin Lathrop,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.