Devi presumere che certe cose funzionino, anche in un mondo con il controllo degli errori. Perché scegliere IIC o SPI quando di solito ci sono molti più segnali digitali su una scheda? Sembra che tu sia d'accordo con il presupposto che saranno tutti interpretati come previsto.

Un circuito progettato correttamente su una scheda progettata correttamente dovrebbe essere affidabile. Pensa a un'uscita CMOS che guida un ingresso CMOS su tutta la linea. Oltre al guasto definitivo dei componenti (che è un problema completamente diverso dalla corruzione occasionale dei dati), pensa a cosa può effettivamente andare storto. Alla fine della guida, hai un FET con una resistenza massima garantita che collega una linea a Vdd o terra. Cosa puoi immaginare esattamente che possa causare che non abbia il giusto livello all'estremità ricevente?

Inizialmente lo stato può essere indeterminato poiché qualsiasi capacità sulla linea viene caricata o scaricata. Quindi ci può essere squillo nella traccia breve. Tuttavia, possiamo calcolare i tempi massimi nel caso peggiore affinché tutto questo si stabilisca e la linea sia affidabile oltre una certa soglia all'altra estremità.

Una volta che questo tempo è stato raggiunto e abbiamo aspettato il peggio caso in cui il ritardo di propagazione della logica è, c'è poco per cambiare il segnale. Potresti pensare che il rumore proveniente da altre parti della scheda possa accoppiarsi al segnale. Sì, può succedere, ma possiamo anche progettare per quello. La quantità di rumore in un'altra parte della scheda è generalmente nota. In caso contrario, proviene da altrove e con una progettazione corretta sarebbe limitato per essere limitato a un dV / dt massimo e ad altre caratteristiche. Tutte queste cose possono essere progettate per.

Il rumore esterno può in teoria sconvolgere le tracce su una scheda, ma l'intensità del campo dovrebbe essere irragionevolmente grande per una scheda progettata correttamente. Esistono ambienti ad alto rumore, ma sono limitati a luoghi noti. Una scheda potrebbe non funzionare a 10 metri da un trasmettitore da 10 kW, ma anche quella può essere progettata.

Quindi la risposta è fondamentalmente che i segnali digitali sulla stessa scheda, se progettati correttamente, possono essere considerati assolutamente affidabili per la maggior parte degli usi ordinari. In casi speciali in cui il costo del guasto è molto alto, come lo spazio e alcune applicazioni militari, vengono utilizzate altre strategie. Questi di solito includono sottosistemi ridondanti. Considera comunque affidabili i singoli segnali su una scheda, ma presumi che schede o sottosistemi nel loro insieme possano occasionalmente errare. Si noti inoltre che questi sistemi costano molto di più e un tale onere di costi renderebbe inutili i sistemi più comuni, come i personal computer ad esempio, essendo troppo costosi.

Detto questo, ci sono casi in cui anche viene impiegato il rilevamento e la correzione degli errori dell'elettronica di consumo. Questo di solito è perché il processo stesso ha una certa probabilità di errore e perché i limiti vengono superati. La memoria principale ad alta velocità per computer spesso include bit extra per il rilevamento e / o la correzione degli errori. È più economico ottenere le prestazioni e il tasso di errore definitivo spingendo i limiti e aggiungendo risorse alla correzione degli errori piuttosto che rallentare e utilizzare più silicio per rendere tutto intrinsecamente più affidabile.

Soprattutto per i protocolli che non sono progettati per essere utilizzati su cavi, una scheda progettata correttamente non avrà errori e una scheda progettata male non funzionerà bene con o senza il controllo degli errori. Ad esempio, i glitch su un bus I2C con più slave possono bloccare permanentemente il bus (*) a meno che il master non abbia un driver che può portare SDA in alto anche quando gli slave stanno cercando di abbassarlo. Proteggersi da ciò renderebbe il protocollo più lento, ma se il bus è sufficientemente privo di anomalie da non considerare un rischio tale comportamento possibile, non ci sarebbe molto bisogno di una logica di controllo degli errori in generale.

(*) Se uno slave pensa di vedere una condizione di avvio nel mezzo di un byte di dati letto da un altro dispositivo e interpreta i dati letti come l'avvio di un comando che dovrebbe leggere una stringa di zeri, allora sarebbe possibile affinché ciascuno dei dispositivi slave confermi i byte di dati inviati all'altro in modo tale che in un dato momento almeno uno degli slave tenga premuto il bus.

Perché lo chiedi solo per quanto riguarda il controllo degli errori?

Come puoi essere sicuro che la condizione di avvio sia interpretata correttamente? Nelle comunicazioni cablate o wireless, l'inizio del frame è una combinazione molto complessa di bit, mentre su RS-232 è un semplice cambiamento da alto a basso e su I2C una semplice violazione del protocollo.

Il mio punto è che non solo il controllo degli errori è diverso, ma tutti gli elementi del protocollo sono molto, molto più semplici per i protocolli di bordo rispetto ai loro omologhi per le comunicazioni cablate e wireless. E il motivo è che la probabilità di errore è inferiore di diversi ordini rispetto alle comunicazioni cablate / wireless.

La risposta breve è che molti dispositivi a cui sono rivolti I2C e SPI sono dispositivi a bassa potenza con piccoli set di istruzioni e memoria di programma limitata. Le specifiche consentono loro di essere implementate nel firmware con un piccolo overhead. Se hai la potenza, puoi aggiungere tutti i livelli di cui hai bisogno, ma questi livelli eliminerebbero molte piccole applicazioni incorporate.

Non ho potuto fornire una risposta valida ma qualche confronto. I protocolli di rete richiedono livelli di meccanismi, eseguire tutti gli scopi contemporaneamente non è una buona idea, non hai packet crc in PHY finché il livello MAC non ha rilevato l'errore RF in 802.11.

SPI e i2c hanno tutti un clock sincronizzato, quindi il tasso di errore e i conflitti di comunicazione nei tempi saranno minimi e l'hardware per implementarli è considerato scarso.

questo è tutto ciò a cui riesco a pensare.

Trova una soluzione specifica per un problema specifico.

Se hai 3 relè che richiedono affidabilità assoluta: Quindi misura il loro output con 3 ingressi digitali, un sistema di conferma ridondante, su misura per la tua applicazione.

Se decidessi di progettare un protocollo di comunicazione personalizzato, per risolvere tutti i problemi di affidabilità una volta per tutte, commetteresti un errore di progettazione comune; Allontanarsi dai requisiti specifici per essere sviato nelle generalità.

Prima di tutto è importante ricordare che I2C sta per comunicazioni da circuito integrato a circuito integrato. È stato progettato per funzionare da chip a chip su una scheda PC. Tuttavia, con sistemi come il Raspberry Pi che pilotano la connessione I2C tramite cavi, lo standard non viene utilizzato per ciò per cui era stato progettato e la conseguente degradazione del segnale significa che la trasmissione sarà molto più soggetta a errori. Sto leggendo questo thread perché sto cercando indizi su come ridurre gli errori I2C nella mia configurazione Raspberry Pi.

Detto questo, ogni dispositivo compatibile con I2C sul mio bus convalida e genera CRC per verificare la presenza di errori del bus. Ciò che non controlla gli errori è il driver del dispositivo I2C in arrivo in Linux, ma puoi facilmente trovare le librerie online per C o Python per controllare i CRC che tornano. Quello che posso dirti è che controllarli è stato illuminante perché una parte allarmante dei dati che tornavano era pessima. Ora, lo scarto e provo di nuovo a leggere i dati, ma la soluzione a lungo termine è riprogettare il mio sistema I2C in modo che abbia meno distanza / capacità. Sto considerando un interruttore I2C per isolare i dispositivi sulle proprie corse di segnale. O passare a Modebus o CANbus che sono elettricamente più robusti (e un po 'più costosi da usare perché i dispositivi sono più costosi.)

A causa delle debolezze dello standard stimolate dalle lunghe corse del segnale, ci sono alcuni errori come SDA trattenuto da un dispositivo slave che sono irrecuperabili usando i tipici driver I2C di Linux e possono richiedere un ciclo di accensione. Per correggere i blocchi del bus sul tuo Pi, puoi cambiare i pin I2C in pin I / O generali e quindi ripristinare il bus nel software con i 9 clock richiesti a 400 KHz prima di cambiarli di nuovo alla funzione I2C, ma ci sono molti trucchi per ciò include la richiesta del codice C per attivare il pin CLK abbastanza velocemente per un ripristino. Anche se ho visto questo discusso online, devo ancora trovare alcun codice per esso e sto pensando di scriverlo da solo. O salvando I2C.

A proposito, penso che usare I2C vicino a quello per cui era previsto, come collegare le schede figlie a un Pi, sia abbastanza sicuro.Non ho avuto problemi con questi progetti.