Che tipo di frame utilizzare nella comunicazione seriale

Question

In un collegamento di comunicazione seriale, qual è il metodo di framing/sincronizzazione preferito?

• framing con SOF e sequenze di escape, come in HDLC?
• basandosi sull'utilizzo di un'intestazione con informazioni sulla lunghezza e CRC?

È un sistema incorporato che utilizza i trasferimenti DMA di dati dalla UART alla memoria. Penso che il metodo di inquadratura con SOF sia molto attraente, ma forse l'altro è abbastanza buono?

Qualcuno ha pro e contro per questi due metodi?

Answer 1

Seguire in base all'esperienza seriale UART, non ricercare.

Ho riscontrato un minor numero di problemi di comunicazione quando sono inclusi - o, in altre parole, entrambi SOF/EOF e (lunghezza - forse)/checkcode. Telaio:

1. SOFrame
2. (lunghezza forse)
3. dati (indirizzo, a, da, il tipo, la sequenza #, codice operativo, byte, etc.)
4. checkcode
5. EOFrame

Invariabilmente, le ricevute "fames" comprendono:

1. quelli buoni - nessun problema.
2. Corrupt dovuto al mittente che non invia un messaggio completo (sospensione, spegnimento o trasmissione power-on) (il ricevitore deve sospendere i messaggi incompleti scaduti.)
3. Corrupt a causa di interferenze di rumore o di trasmissione. (errori di framing di byte, parità, dati errati)
4. Corrupt dovuto al ricevitore che si avvia nel mezzo di un messaggio inviato o manca alcuni byte a causa di sovraccarico del buffer di input.
5. collisioni bus condivise.
6. Break: questo è valido nel sistema?

Indipendentemente dal tipo di frame utilizzato, è sicuro che sia in grado di indirizzare questi tipi di messaggi, convalidare immediatamente il numero 1 e identificare rapidamente 2-5 e prepararsi per il frame successivo.

SOF ha l'enorme vantaggio di esso facile da ottenere di nuovo iniziare, se il ricevitore è perso a causa di una precedente struttura merda, ecc

Lunghezza è buono, ma secondo me la meno utile. Può limitare il through-put, se la lunghezza deve essere all'inizio di un messaggio. Alcune operazioni a bassa latenza non conoscono la lunghezza prima che siano pronte per iniziare la trasmissione.

CRC Consiglia più di 2 byte. Un breve codice di controllo non migliora abbastanza le cose per me. Preferirei non avere un codice di controllo di uno a 1 byte. Se gli errori si verificano di tanto in tanto, vengono catturati dal codice di controllo, voglio qualcosa di meglio di un 99 di 2 byte.999% delle volte, mi piace il 99.99999997% di 4 byte

EOF così utile!

BTW: Se il protocollo è ASCII (invece di binario), consiglia di non uso cr o lf come EOFrame. Forse li userai solo out-of-frame dove non fanno parte di un messaggio.

BTW2: se il ricevitore è in grado di rilevare automaticamente il baud, consente di risparmiare su molti problemi di configurazione.

BTW3: un mittente potrebbe prendere in considerazione l'invio di un byte "niente" (prima del SOF) per assicurare la corretta sincronizzazione SOF.