In base alla mia esperienza, quasi tutte le apparecchiature e i sistemi con cui ho mai lavorato con la parità di salto e utilizzano semplicemente i checksum dei messaggi o CRC per rilevare gli errori.

Se hai la capacità di interrompere un messaggio, un errore di parità può essere usato per terminare una cattiva trasmissione più velocemente di un controllo CRC, specialmente per pacchetti di grandi dimensioni. Altrimenti, un controllo CRC prenderà tutto ciò che un controllo di parità farà e altro ancora. Se sei veramente preoccupato, puoi utilizzare metodi di rilevamento software aggiuntivi, come il controllo del contesto e il mirroring dei messaggi. I timeout possono essere utilizzati per impedire che l'OSD cada permanentemente in uno stato errato.

Parità pari e dispari

Questo dipenderà leggermente dalla comunicazione che stai utilizzando. So che hai detto che stai usando UART, ma risponderò in modo un po 'più ampio. Se decidi di utilizzare la parità, seleziona l'opzione che farà sì che il tuo stato "inattivo" richieda la commutazione del bit di parità.

Se hai un sistema alto attivo, tutti gli 0 sono inattivi. Quindi rendi la parità dispari in modo che il bit di parità debba cambiare stato da inattivo.

In un sistema basso attivo dovresti guardare a quanti bit la parità sarà finita. Se è di 8 bit, la parità pari risulterà in un bit di parità 0, che segue l'idea di forzare un cambiamento di stato per la parità.

Dovresti usare Parity?

Questa è una domanda un po 'difficile. In generale ci piace modellare il rumore come rumore gaussiano, il che significa che gli errori di bit saranno completamente casuali. In realtà il rumore che ha un effetto sul nostro sistema non è sempre casuale. La ragione di ciò è che le cose che possono causare errori su un PCB sono i radiatori di qualcos'altro. Se ci pensate, affinché una traccia così breve avesse abbastanza rumore da causare un errore di bit, doveva essere qualcosa di piuttosto estremo. Quando hai una fonte di rumore come questa, c'è una buona probabilità che tu capovolga più di un bit. La parità è inutile contro un numero pari di errori di bit. Senza immergersi nella matematica, la parità aiuterà, ma non aiuta tonnellate. Se non puoi permetterti di eseguire molte elaborazioni, la parità potrebbe essere la migliore che puoi fare ..

Perché utilizzare un CRC?

Prima di tutto, dici di avere un generatore CRC integrato, questo significa che dovrebbe essere molto facile per te calcolarlo. I CRC sono molto più bravi a rilevare più errori di bit. In un ambiente in cui si desidera una probabilità molto bassa di ricevere errori, si desidera utilizzare un CRC. In effetti, scegli il CRC più grande che puoi permetterti nel tuo sistema. Un piccolo trucco che so funziona per almeno crc16 se non altri è se CRC il messaggio che hai ricevuto con il CRC su di esso dovresti ottenere 0 come risposta. Se disponi di hardware per calcolare il CRC, questo è un modo molto efficiente sia per generare CRC che per controllare CRC.

Lavorerei prima di tutto sulla schermatura di questo filo.

Metti i piani di terra attorno ad esso (e / o) seppelliscilo negli strati interni tra i piani di terra. Allora affidati a CRC. Usa la parità se è gratuita.

Se usi la parità pensa a come gestirai l'errore nel tuo codice. Se non si dispone di un modo grazioso per gestire l'errore, il rilevamento non sarà di grande aiuto.

La parità è inutile, secondo me.

Con brevi connessioni chip-to-chip su una singola scheda come questa, finché si guidano correttamente le linee, dovrebbe essere praticamente priva di rumore - - almeno rispetto, ad esempio, alla tua DRAM.Alcune persone si aspettano un errore di soft bit, al giorno, per gigabyte di DRAM.Come fai a sapere che l'errore che hai visto non è stato causato da un errore di bit così debole, piuttosto che da rumore i cavi di comunicazione? Se hai indotto un rumore abbastanza grande da capovolgere un po 'su una traccia PCB guidata correttamente, probabilmente hai altri problemi più grandi di cui preoccuparti. (Con "guidato correttamente", intendo guidare attivamente ogni linea tutto o utilizzare un resistore pull-up o un resistore pull-down per impostare lo stato tra i messaggi).

Con connessioni esterne a lungo raggio, è spesso inevitabile avere occasionalmente fili fluttuanti che presentano un pin di ingresso con rumore casuale più o meno continuo, e anche quando si trasmette un messaggio si ottengono spesso errori di bit, in questo caso la parità è meglio di niente. bt2 menzionato, ti consigliamo di utilizzare CRC in modo da poter rilevare molti errori che la parità manca completamente e, una volta che hai CRC, aggiungervi la parità non aiuta in modo significativo.

Se è possibile inserire il tuo sistema in "cattivo stato", prova a progettare cose in modo tale che ritorni a uno stato buono in un ragionevole lasso di tempo.Usa timeout di comunicazione e timer watchdog come markrage e bt2 menzionati.Periodicamente ritrasmetti i comandi di inizializzazione in modo che non importa in quale strano stato si trova il ricevitore, viene ripristinato allo stato corretto.

"La statica nel satellite ha influenzato il suo computer che legge il rumore come un comando di spegnimento. Per superare il problema, i controller hanno inviato un flusso continuo di comandi ON al satellite per mantenerlo acceso. "- Amateur Radio Satellites: OSCAR-6

Non vuoi la parità. Vuoi una comunicazione più affidabile.

Il motivo per cui la parità è poco utilizzata è che è costosa in termini di velocità effettiva dei dati. Inizia rendendo un frame più lungo di quasi il 10%: bit di inizio + 8 bit di dati + parità + bit di stop = 11 bit invece di 10. Ma è molto peggio di così. Se hai un modo per sapere se hai ricevuto i dati correttamente, hai il dovere di fare qualcosa con quello. Ignorare semplicemente la comunicazione errata non va bene; il trasmettitore deve inviarlo di nuovo. Quindi ha bisogno di sapere se è stato ricevuto bene. Dovrai inviare un riconoscimento ( ACK / NAK ) dopo ogni byte e il trasmettitore non può inviare il byte successivo prima di aver ricevuto ACK . Se utilizzi codici ASCII, sono 11 bit di ritorno. Quindi questo dimezza il rendimento e abbiamo già perso il 10%, quindi ora siamo a un 36% di efficienza del carico utile , dall'80%. E questo è il motivo per cui a nessuno piace davvero la parità.

Note:
1. Non è necessario confermare la ricezione di una ricevuta; la distanza di Hamming tra i codici ASCII per ACK e NAK è 3 (con parità anche 4), quindi un errore nella ricezione di ACK / NAK può essere non solo rilevato, ma anche corretto .
2. Molti UART possono lavorare con lunghezze di dati fino a 5 bit ed è possibile passare a 5 bit per l'invio di ACK , ma questa è una semplice vetrina e complica solo la comunicazione.

Una soluzione migliore può essere usare un CRC alla fine di ogni blocco. I CRC sono migliori dei bit di parità nell'acquisizione di più errori (ma non possono ancora correggerli). Una migliore efficienza può essere ottenuta solo per blocchi lunghi; se un blocco consiste di soli 2 byte non serve aggiungere un CRC a 8 bit.
Un altro svantaggio sarebbe che devi ancora riconoscere la corretta ricezione. Quindi probabilmente non è nemmeno questo.

Che ne dici dei codici di correzione automatica ? I codici di Hamming aggiungono un piccolo sovraccarico e ti consentono di correggere 1 bit errato da solo; non è più necessario riconoscere. Come i CRC, i codici di Hamming sono più efficienti su blocchi più lunghi; il numero di bit aggiuntivi è definito come

\ $ N + H < 2 ^ H \ $

dove N = numero di bit di dati e H = numero di bit di Hamming. Quindi per correggere 1 bit in una comunicazione a 8 bit è necessario aggiungere 4 bit di Hamming; un quinto bit di Hamming è richiesto solo da 12 bit di dati. Questo è il modo più efficiente per rilevare / correggere gli errori su messaggi brevi (pochi byte), sebbene richieda un po 'di giocoleria con i dati: i bit di Hamming devono essere inseriti in posizioni specifiche tra i bit di dati.

Ora, prima di aggiungere i codici di correzione degli errori di Hamming, vale la pena esaminare la configurazione. Puoi aspettarti errori su una linea di 100 m che corre tra macchinari pesanti, ma non dovresti avere errori su una linea di 2 cm. Se rileva rumore, potrebbe essere un'impedenza troppo alta. I driver spingono / tira? Se è così, dovrebbero essere in grado di darti bordi veloci, tranne se il tuo "cavo" è capacitivo, che non sarà a questa breve distanza. Ci sono tracce ad alta corrente che corrono parallele alle linee dati? Potrebbero indurre rumore. Hai davvero bisogno di questa alta velocità e gli orologi su entrambi i lati corrispondono abbastanza da vicino? Rallentare fino a 57600 bit al secondo potrebbe risolvere il problema.

Nonostante la pletora di risposte aggiungerò il mio pezzo. La parità funzionerà a livello di byte e un CRC funziona (generalmente) a livello di pacchetto. Gli schemi di pacchetti sono a mio parere superiori alle comunicazioni di tipo byte non elaborate. Se il tuo hardware rifiuta un singolo byte in base alla parità, è ottimo per un bytestream grezzo, ma non così buono per un pacchetto. All'improvviso, boom, ti sei perso un byte nel mezzo di un pacchetto - questo rovina la tua analisi. Nel migliore dei casi, l'intero pacchetto è andato, ma se il tuo algoritmo di ricerca dei pacchetti non è buono, potresti potenzialmente perderne di più (e ho visto alcuni algoritmi di rilevamento dei pacchetti cerebrali usati in prodotti reali). Usa pacchetti e CRC come è stato suggerito.

La parità è generalmente inutile con comunicazioni "normali" in stile asincrono, ma può essere utile in alcuni altri contesti. Ad esempio, alcuni schemi di codifica differenziale richiedono che ogni carattere abbia un numero pari di transizioni di riga in modo che lo stato finale della riga corrisponda allo stato iniziale. I codici a barre Code 39 utilizzano la parità, una sorta di (*), per convalidare i singoli caratteri e generalmente eliminano la necessità di un carattere di checksum.

Se gli errori a bit singolo fossero molto più comuni e gli errori a più bit o il framing errori, il controllo della parità per byte potrebbe essere un'utile aggiunta a un checksum o CRC, poiché l'individuazione di un byte con un errore consentirebbe di correggere l'errore. Nella maggior parte delle situazioni pratiche che coinvolgono gli UART, tuttavia, molti glitch di linea causano errori di framing, rendendo impossibile il recupero dei dati in molti casi con o senza parità per byte.

(*) Un carattere Code 39 valido deve avere un carattere dispari numero di spazi larghi (1 o 3) e un numero pari di barre larghe (0 o 2).