Protocollo generale per il trasferimento di dati da un sistema a un altro?

18

Qual è il protocollo generale per inviare informazioni da un sistema a un altro? Ad esempio, supponiamo di aver raccolto alcune informazioni dal microcontrollore per un periodo di tempo che vogliamo inviare a un altro microcontrollore. Ho sentito parlare di interfacce SPI e I2C, ma non sono chiaro quando si utilizza un metodo su un altro e su come lo si implementa. Esistono altri metodi oltre a SPI e I2C che sono comuni? Il processo di implementazione è simile per diversi microcontrollori? Fondamentalmente sta analizzando byte di dati che sto facendo sul microcontrollore ricevente?

i2c spi data

— O_O
fonte

4

Qual è la cosa concreta che vuoi fare?

— Starblue,

Sto solo pensando a come ottenere diversi pezzi di un sistema per passare i dati l'un l'altro in una piccola scatola, quindi la distanza può essere considerata molto breve. Il motivo per avere diversi pezzi in una scatola è semplificare le funzioni in modo che ogni pezzo abbia una sua funzione (si spera che abbia un senso ..)

— O_O

2

non è quello che la gente normalmente chiama un sistema. Questi sono più ciò che definirei sottosistemi. Fanno parte di ciò che potresti considerare un singolo sistema che compie un singolo set di attività. È una semantica, ma penso che molte delle tue risposte siano molto ampie perché non hanno un'idea perfetta di ciò che stai cercando dalla domanda.

— Kortuk,

1

sulla falsariga di quanto affermato da Kortuk, aiuta a definire il problema. Una domanda importante da porsi è se si potrebbe intendere sostituire singoli sottosistemi con diverse implementazioni della stessa funzione o se si tratta di un progetto unico. Se usi un bus reale ed esponi i dettagli di implementazione dei sottosistemi alla tua cpu, una modifica del sottosistema richiede la modifica di / w per il tuo controller, mentre se usi un'interfaccia di comunicazione, non importa come implementi una (sostituzione ) sottosistema, purché soddisfi lo stesso protocollo di messaggio.

— JustJeff,

Non è più semplice dividere la funzionalità su più dispositivi per nessun altro motivo che separare le attività. Le comunicazioni e la sincronizzazione sono più complesse che avere due processi nella stessa micro. Ora, se questi processi hanno profili di latenza particolarmente incompatibili (uno deve aggiornarsi rapidamente mentre l'altro può richiedere del tempo per completare un blocco), allora ci può essere un motivo valido per dividerli. Anche in questo caso, la soluzione più comune è utilizzare gli interrupt o trovare un modo per interrompere ulteriormente l'attività più lunga. Con quello che hai descritto, sono propenso a pensare che dovresti ripensarci.

— darron,

10

SPI e I2C sono in qualche modo simili, in quanto sono usati molto di più per collegare periferiche a un controller o CPU, piuttosto che per trasferire effettivamente dati tra sistemi. L'USB è un'altra interfaccia che le persone sembrano voler trattare come un sistema di comunicazione, che in realtà è un bus di collegamento periferico.

La comunicazione tra sistemi non è esattamente come collegare un dispositivo a un bus. L'allegato bus consente al processore di battere direttamente sui registri di un dispositivo, mentre un'interfaccia di comunicazione consente di inviare / ricevere flussi di dati. Un dispositivo collegato su un bus in genere necessita di un driver di dispositivo, mentre con le comunicazioni, in realtà non importa ciò che è collegato all'altra estremità, per quanto riguarda il computer host.

Certo, questo sta diventando sempre più confuso. Cose come PCI e ISA sono indiscutibilmente bus; I2C, SPI, USB sono probabilmente bus; mentre RS232, RS485 e Ethernet sono sicuramente interfacce di comunicazione. Ma poi ci sono cose come CAN bus e 1553, che riguardano sicuramente lo spostamento dei dati, ma in un modo molto coinvolto.

— JustJeff
fonte

CANbus è molto coinvolto e Ethernet no? CAN è molto semplice da utilizzare per i semplici messaggi avanti e indietro. Sono chip dedicati e la maggior parte delle famiglie supporta internamente i loro micro controller.

— Kortuk,

@Kortuk - nella misura in cui qualcosa come 232 ha una sorta di simmetria peer-to-peer, mentre 1553 o CAN impongono una relazione master / slave, sì. Non credo di aver detto che Ethernet sia semplice, solo che non impone una distinzione controller / dispositivo bus sui punti finali.

— JustJeff

inoltre, divulgazione completa - la mia opinione su CAN deriva interamente dall'esposizione tangenziale; è stata una periferica opzionale inutilizzata su diversi sistemi su cui ho lavorato, ma dopo centinaia di passaggi nella documentazione, assorbi un po 'le opzioni inutilizzate solo per osmosi. Quindi sto lavorando sul presupposto che CAN è un tipo di architettura controller / dispositivo controllato.

— JustJeff,

Penso che il bus abbia significati diversi in contesti diversi. Da un livello schematico, qualsiasi interfaccia con più segnali può essere considerata un bus. Man mano che passi a livelli più alti con più astrazione, il bus cambia significato. Leggermente più alto, il bus di solito significa che ci sono o possono essere coinvolti più dispositivi. RS485 multipunto è sicuramente un bus, per esempio. Molto più in alto, dal punto di vista del dispositivo Linux, RS485 diventa di nuovo un'interfaccia di comunicazione e viene retrocesso dall'essere un bus ... fino a quando non si aggiunge il proprio livello di protocollo su di esso trasformandolo in un bus. Ad ogni livello ha significati diversi.

— darron,

11

Non esiste un modo per inviare dati, ci sono molti modi diversi di comunicare a seconda della distanza, della velocità dei dati, dell'ambiente, dell'applicazione ...

Il livello più basso è il livello fisico , che in realtà sposta i bit in giro.

SPI e I²C sono per brevi distanze all'interno di un dispositivo, dove non c'è molto rumore che potrebbe disturbare la trasmissione.
Per comunicazioni non troppo veloci su distanze fino a qualche decina di metri, la comunicazione seriale tramite RS-232 è una buona scelta.
Se è presente più rumore o vengono utilizzati segnali differenziali a distanza maggiore, ad esempio in RS-485. Per una trasmissione più veloce dei dati c'è Ethernet, che sta diventando sempre più popolare.
Quindi ci sono anche vari standard wireless.

Oltre al livello fisico ci sono più livelli che organizzano il modo in cui i dati vengono inviati, per rilevare e correggere errori di trasmissione, instradamento in una rete e molte altre cose. Ad esempio, il protocollo Internet è uno stack piuttosto complesso di più livelli, in genere sopra il protocollo Ethernet.

— starblue
fonte

7

È possibile utilizzare un semplice UART seriale (una linea Tx e una linea Rx senza clock discreto) e può essere facilmente adattato per attraversare diversi potenziali (anche circuiti primari e secondari) con optoisolatori o isolatori magnetici .

Per quanto riguarda i protocolli, qualsiasi cosa con byte di comando definiti e una sorta di schema di checksum funzionerà bene. Non esiste davvero un protocollo standard di copertura generale adatto a tutti i tipi di comunicazioni. I2C ha uno standard di segnalazione (definizione di indirizzamento, arresti, avviamenti, ecc.) Ma il protocollo di ciò che viene effettivamente comunicato dipende esclusivamente dallo sviluppatore.

PMBus , ad esempio, è un protocollo di comunicazione dell'alimentatore che utilizza I2C come mezzo fisico.

— Adam Lawrence
fonte

6

Non esiste davvero un protocollo "generale", ciò che si finisce per utilizzare dipende fortemente dall'applicazione. Per poterti dare una risposta migliore, dobbiamo capire un po 'meglio le tue esigenze. Dici che vorresti che microcontroller separati parlassero come sottosistemi.

Alcune domande su questa applicazione:

Ci saranno più di 2 micro-controller in questo progetto?
Quali sono i requisiti di velocità e velocità effettiva? Con quale velocità arrivano le informazioni e con che frequenza invii / ricevi i dati?

Se hai risposto NO alla domanda 1:

Se in questo progetto ci sono solo 2 microcontroller, puoi sicuramente usare UART tra di loro. Se entrambi hanno bisogno di avviare la comunicazione, utilizzare il controllo del flusso, altrimenti dovrebbe essere banale inviare i dati in una direzione. Per la maggior parte dovrebbe essere "abbastanza veloce" dato che si seleziona uno dei baud rate più alti. I2C e SPI sono in genere validi solo per l'architettura master / slave.

Se hai risposto SÌ (più di 2 controller) alla domanda 1:

Se ci sono più di 2 micro-controller nel tuo progetto, quale dei due avvia le comunicazioni? Sarà solo un controller master (ovvero architettura master-slave)? O qualcuno dei sottosistemi sarebbe in grado di parlare in qualsiasi momento?
C'è bisogno che qualcuno dei sottosistemi si dialoghi? ad es .: per i dispositivi A, B e C: A può inviare a B e C e B può inviare sia ad A che a C, ecc.

Quindi ora hai bisogno di qualcosa di più scalabile in cui puoi rilasciare i dispositivi indirizzabili su un bus comune. La risposta a queste domande di follow-up ti aiuterà a decidere tra I2C e SPI (master-slave) o qualcosa come CAN (multi-master).

Molto probabilmente il tuo microcontrollore ha una periferica UART, le altre (specialmente CAN) potrebbero essere disponibili solo su chip di fascia più alta. In entrambi i casi, dovrebbe esserci molta documentazione su come utilizzare queste periferiche per spostare i byte.

— Jon L
fonte

5

Come notato da @Jon, un problema nella scelta di un'interfaccia di comunicazione è se un'entità sarà sempre responsabile dell'avvio delle comunicazioni o se più di un'entità può esserlo. Una questione correlata è se un'entità sarà sempre pronta a ricevere comunicazioni indesiderate. SPI viene spesso utilizzato in applicazioni in cui un lato sarà sempre pronto a ricevere comunicazioni. Qualcosa come un registro a scorrimento 74HC595, ad esempio, non è mai "occupato". Mentre SPI è buono per la comunicazione tra un microcontrollore e hardware che il micro dovrebbe controllare, in realtà non è buono per la comunicazione tra due microcontrollori. Quando due processori con hardware I2C lo utilizzano per comunicare, il software può impiegare tutto il tempo che vuole (entro limiti molto generosi) per gestire ciò che sta accadendo, senza causare la perdita di dati. Se un processore impiegasse 100 microsecondi per elaborare ciascun byte in entrata, ciò limiterebbe notevolmente il throughput, ma il mittente rallenterebbe abbastanza da consentire al ricevitore di tenere il passo. L'unico modo che può generalmente accadere con SPI è se si ha un filo separato per l'handshaking.

I2C è davvero un protocollo meraviglioso. Le maggiori limitazioni che gli impediscono di essere il protocollo più perfetto che si possa immaginare

La sua velocità è piuttosto limitata; SPI può andare molto più veloce e persino gli UART a volte possono andare un po 'più veloci
(2) Sebbene sia molto conveniente che I2C abbia bisogno solo di due fili, entrambi i cavi devono essere in grado di comunicare bidirezionale a collettore aperto. Ciò rende difficile inviare I2C tramite ripetitori.

Personalmente, vorrei vedere i distributori di controller supportare una variante a tre fili di SPI che includeva l'handshaking. Tuttavia, non sono a conoscenza di alcun controller che lo faccia.

— Supercat
fonte

Divertente, dovresti menzionarlo ... Sto trasformando un'interfaccia SPI in un'interfaccia non bidirezionale di tipo I2C (il primo byte è un indirizzo) per consentire a molti più dispositivi di partecipare al bus di quanti ne abbia i chip per . Funziona se i tuoi dispositivi slave sono tutti FPGA. :) Anch'io avrei desiderato che ci fosse qualcosa tra quei due principali standard sincroni.

— darron,

Oh, suppongo che dovrei chiarire che l'uscita abilitata sugli slave non viene affermata fino a quando non viene ricevuto il suo byte di indirizzo e rimangono attivi fino a quando la selezione del singolo chip non viene dichiarata ... quindi è ovviamente leggermente diverso dal normale SPI + alto livello protocollo. Tuttavia, è totalmente compatibile con SPI standard dal punto di vista del dispositivo master. (come un microprocessore)

— darron,

@darron: fantastico. Mi chiedo cosa dovrebbe succedere per l'industria per iniziare a utilizzare un bus di comunicazione a tre fili a standard aperto in cui i fili sono attivamente guidati su e giù? Immagino che ci sia un leggero conflitto tra evitare i pull-up passivi e consentire a qualsiasi dispositivo di segnalare un interrupt, anche se ciò potrebbe essere risolto aggiungendo un pin di interruzione che potrebbe essere collegato al master o non per comodità degli slave (la mia attuale implementazione di il protocollo ha solo uno slave, quindi può usare il filo di ritorno dati per segnalare in modo asincrono quando vuole essere revisionato).

— supercat,

@darron: per evitare di dover utilizzare un pin di selezione chip, il master segnala l'avvio del comando inviando due fronti di salita sul filo dati mentre l'orologio è basso; gli slave possono indicare se il loro ultimo byte di dati era valido emettendo un valore di stato quando clock e dati sono entrambi bassi (inattivi); altrimenti indicano che vogliono l'attenzione quando l'orologio è basso e i dati sono alti. Se stavo progettando un hardware master per questo protocollo, aggiungerei la possibilità di inviare 8 impulsi di clock in cui l'orologio con mirroring del filo dati e nell'hardware slave includono un conteggio asincrono del numero di fronti di salita durante ...

— supercat

@darron: ... un byte di dati. Se pari o superiore a cinque, il byte verrebbe ignorato (lo slave supponeva che il master fosse interessato a ricevere un byte di dati, ma non aveva nulla che effettivamente volesse dire). Ciò non sarebbe altrettanto significativo, come se lo slave segnalasse lo stato dell'ultimo byte quando il clock era basso (il che, se il dispositivo slave fosse un processore, consentirebbe al master di sapere che lo slave non era pronto e avevo perso l'ultima "opportunità di transazione"

— supercat

3

In nessun ordine particolare, le istanze di livello fisico più popolari per 2 CPU nella stessa scatola sembrano essere:

SPI daisy-chain (come utilizzato da JTAG)
seleziona SPI wire-per-slave
"RS-232 di livello TTL" aka "comunicazione seriale start-stop asincrona" (che collega direttamente il pin UART TX di una CPU al pin UART RX di un'altra CPU)
I2C
Dati a 8 bit + strobo (come la porta parallela della porta della stampante IEEE 1284)
memoria condivisa (solo una CPU guida l'indirizzo / dati / bus di controllo alla volta)

Queste istanze del livello fisico (così come altre istanze del livello fisico per 2 CPU in caselle separate) in genere forniscono un flusso di byte al software che implementa i livelli più alti del sistema di comunicazione.

I programmatori intelligenti scrivono il software in modo tale che quando l'hardware decide di strappare un'istanza di livello fisico e sostituirla con un'istanza di livello fisico completamente diversa, devono solo riscrivere alcune funzioni per alimentare il flusso di output di byte all'hardware e rileggere un flusso di byte dall'hardware e tutte le funzionalità del protocollo di livello superiore continuano a funzionare invariate.

Il protocollo per inviare informazioni da una CPU a un'altra CPU implica quasi sempre l'interpretazione del flusso di byte come una serie di pacchetti:

preambolo
intestazione
(eventualmente fuggito) dati serializzati
trailer

Ad alcune persone sembra piacere inventare protocolli completamente nuovi, personalizzati e incompatibili mescolando e abbinando (2) uno dei molti tipi di struttura di intestazione con (3a) uno dei molti tipi di dati di serializzazione con (3b) uno dei tanti tipi di sfuggire a quei dati serializzati con (4) uno dei molti tipi di trailer.

Alcuni dei protocolli più semplici per l'incapsulamento dei dati in un pacchetto includono:

Protocolli leggermente più complicati per l'incapsulamento dei dati in un pacchetto includono:

C'è un lungo elenco di protocolli su

Potresti leggere "Protocol Design Folklore" di Radia Perlman che descrive come il design del protocollo può andare storto.

— davidcary
fonte

3

Nessun singolo protocollo "generale". La scelta può (ad esempio) dipendere da:

distanza
rendimento richiesto
disponibilità di periferiche speciali
livello di rumore
necessità di isolamento ottico
criticità (tasso di fallimento tollerabile)
potenza della CPU disponibile ad entrambe le estremità
pin I / O disponibili su entrambe le estremità

In molti casi è necessario disabilitare il livello fisico (livelli di segnale) dal livello di collegamento dati (+/- il modo in cui i dati vengono codificati) (controllare il modello OSI, livelli inferiori 2,4). I possibili strati fitologici sono ad esempio:

semplice 5 V o 3,3 V o anche 1,8 V TTL
uno dei precedenti ma open-collector invece di push-pull
segnalazione di tensione amorosa bilanciata (spesso utilizzata con FPGA)
volatge higer bilanciato (RS485, RS432)
tensione più alta single end (RS232)
bilanciato trafo-accoppiato (varie versioni Ethernet, audio PDIF)
ottico (ethernet ottico, toslink)

È possibile utilizzare una riga per trasportare dati e informazioni sull'orologio oppure suddividerla in più righe. Quest'ultimo era popolare, ma oggigiorno la maggior parte dei protocolli nuovi / veloci tende a usare una linea (o una coppia di linee che agiscono come una).

Ci sono molti modi per codificare i dati e il clock su una linea. RS232 utilizza tradizionalmente NRZ, esiste la codifica Machester, e i vari formati utilizzati su hard disk con nomi curiosi linea 2.7 RLL.

Per riassumere: ci sono molti modi per fare comunicazione tra i sistemi. E non ho nemmeno menzionato connettori o aspetti di livello superiore come il rilevamento e il recupero degli errori, la codifica dei dati, la compressione e la crittografia ...

— Wouter van Ooijen
fonte