Perché preoccuparsi di pari parità?

Sto usando una periferica SPI nella mia applicazione. La periferica restituisce pacchetti contenenti 15 bit di dati, oltre a un bit di parità pari per il rilevamento degli errori.

Pertanto, tutti gli zeri e tutti e due superano il controllo di parità.

Ciò significa che il mio microcontrollore non è in grado di rilevare il tipo più comune di errore: la periferica è disconnessa! In questo caso, i bit ricevuti sono tutti zero, che supera il controllo di parità.

Presumendo che sarebbe stato altrettanto facile per il produttore della periferica implementare la parità dispari, la mia domanda è: perché avrebbero scelto di utilizzare la parità pari in questo caso ? Esiste un altro vantaggio di Even Parity in questo caso per compensare il fatto che non è in grado di rilevare il tipo più comune di errore?

Un singolo bit di parità può solo verificare la presenza di numeri singoli o dispari di bit negli errori, quindi aspettarsi che rilevi quando una periferica è disconnessa probabilmente si aspetta troppo.

Tuttavia, molti sistemi produrranno una serie continua di 1 quando non è presente una periferica e ciò può essere ottenuto con un semplice resistore pull-up sulla linea di dati di ritorno. Se i dati a 8 bit effettivi fossero restituiti da una periferica collegata, il bit di parità sarebbe zero per il 255 decimale trasmesso. Quindi anche la parità può rilevare quando una periferica viene disconnessa in queste circostanze.

Se si usasse la parità dispari, 8 bit alti (255 decimali) comporterebbero un bit di parità elevato, rendendo inutile la parità dispari come mezzo per rilevare la perdita del chip periferico.

Cavalli per i corsi.

La parità, o qualsiasi rilevamento di errori di blocco, ha lo scopo di rilevare errori all'interno di una stessa trasmissione di dati. La parità non è progettata per rilevare se la trasmissione dei dati è in corso o meno.

Data una linea di trasmissione, ci sono diversi tipi di preoccupazioni. I due che sono rilevanti qui sono: 1) totale fallimento della linea stessa e, 2) bloccare errori di dati all'interno di una trasmissione particolare. Altri meno rilevanti sono, ad esempio, tensioni di linea errate, errori di protocollo o errori di sicurezza. La parità aiuta con 2 ma non 1. Per un sottosistema su entrambe le estremità di una linea di trasmissione per far fronte a 1 (fallimento totale di una connessione), è necessaria un'altra funzione di protocollo.

Il tasso di rilevamento degli errori di un singolo bit di parità è spesso superiore al 50%. Che cos'è esattamente tale tasso dipende dall'euristica del segmento di dati nel protocollo. Supponiamo che tu abbia un pacchetto (MSB) 1011010111011110 e che vi sia un errore a bit singolo nell'ultimo bit trasmesso, il controllo di parità fallirebbe e lo respingerebbe correttamente. Allo stesso modo, se si verifica un errore di dati nel primo bit (il bit di parità), il pacchetto verrebbe rifiutato.

L'esecuzione di questo controllo nell'hardware è estremamente semplice e non richiede elaborazioni complicate. È utile in applicazioni con tassi di errore relativamente bassi per eliminare elementi come l'inclinazione o i segnali di clock generati dai processori che eseguono stack di software raccolti in modo inutile.

SPI è un protocollo di collegamento fisico progettato per brevi linee connesse elettricamente in cui il tasso di errore a bit singolo non dipende in gran parte dalla perdita della linea. Se stai eseguendo qualcosa su una linea che perde, avrai bisogno di qualcosa di molto più robusto della parità. Questo non è proprio ciò che fa SPI.

Per verificare se un dispositivo è ancora collegato, provare qualcosa in più nello stack. In confronto, TCP / IP (in particolare IP) non specifica i bit di parità mentre molte delle specifiche Ethernet 802.x lo fanno. IP, d'altra parte, ha un complicato, "ci sei?" protocollo. Cosa stai eseguendo su SPI? La risposta alla gestione del collegamento dati è probabilmente lì.

Non c'è ovvio vantaggio di parità pari su dispari. Negli schemi di comunicazione e archiviazione, la polarità di parità (pari o dispari) deve essere selezionata per intercettare le modalità di guasto più probabili o più frequenti.

Come dici tu, un bersaglio non rispondente o un filo di ricezione dati rotto potrebbe causare una linea MISO bloccata in alto o in basso.

Quando si comunicano numeri pari di bit, come byte su SPI, un bit di parità dispari rileverà un errore nei dati di questo all-1 o di tutti-0, ma nemmeno la parità.

Tuttavia, non esiste un vincitore così chiaro quando si comunica un numero dispari di bit, come nell'applicazione con 15 bit su SPI. Perfino la parità rileverebbe un errore nel caso di all-1 ma perderebbe il caso di all-0. Viceversa, la parità dispari rileverebbe un errore nel caso di tutti-0 ma mancerebbe il caso di tutti-1.

C'è poca differenza nel beneficio con parità pari o dispari. Uno può essere convertito nell'altro con una singola porta di inversione. Lo scopo principale del bit di parità è controllare solo i 15 bit in quel valore. Non è suo scopo fare qualsiasi altra cosa. L'uno o l'altro potrebbe rilevare un chip mancante, difettoso o disconnesso non è una considerazione. Dici che essere disconnesso è il tipo più comune di errore nel tuo caso. Non importa. Il bit di parità non è presente per rilevare quel tipo di errore.

Hai ragione a metterlo in discussione, ho le stesse critiche anche alla parità. Con un numero dispari di bit di dati prima dell'aggiunta del bit di parità, come nel tuo esempio, e come è comune, la parità pari consente a tutti gli 0 e tutti gli 1 come parole trasmesse valide, il che è inutile nel rilevare un collegamento morto o un chip morto. La risposta precedente di Tony M è errata in questo senso. Vedere la tabella di esempio dei dati a 7 bit qui per la prova: - https://en.wikipedia.org/wiki/Parity_bit

La parità dispari tuttavia inserisce un bit di stato opposto nel caso di tutti gli 0 o di tutti gli 1, dimostrando così che il collegamento e il chip sono vivi e sarebbe una scelta molto migliore in questo caso.