Vous devez supposer que certaines choses fonctionnent, même dans un monde où les erreurs sont vérifiées. Pourquoi choisir IIC ou SPI alors qu'il y a généralement beaucoup plus de signaux numériques sur une carte? Vous semblez être d'accord pour supposer que tout cela sera interprété comme prévu.

Un circuit correctement conçu sur une carte correctement conçue doit être fiable. Pensez à une sortie CMOS pilotant une entrée CMOS sur une carte. Autre que la défaillance pure et simple des composants (qui est un problème totalement différent de la corruption occasionnelle des données), pensez à ce qui peut réellement mal tourner. Du côté de la conduite, vous avez un FET avec un maximum garanti sur la résistance connectant une ligne à Vdd ou à la terre. Selon vous, qu'est-ce qui peut causer le fait de ne pas avoir le bon niveau à la réception?

Au départ, l'état peut être indéterminé car la capacité sur la ligne est chargée ou déchargée. Ensuite, il peut y avoir une sonnerie dans la courte trace. Cependant, nous pouvons calculer le pire des cas maximum pour que tout cela se stabilise et que la ligne franchisse de manière fiable un certain seuil à l'autre extrémité.

Une fois que ce temps a été atteint et que nous avons attendu le pire cas retard de propagation de la logique est, il y a peu de changement du signal. Vous pensez peut-être que le bruit provenant d'autres parties de la carte peut se coupler au signal. Oui, cela peut arriver, mais nous pouvons également concevoir pour cela. La quantité de bruit dans une autre partie de la carte est généralement connue. Sinon, cela vient d'ailleurs et dans une conception appropriée, il serait serré pour être limité à certains dV / dt maximum et à d'autres caractéristiques. Tout cela peut être conçu pour.

Le bruit externe peut en théorie perturber les traces sur une carte, mais l'intensité du champ devrait être déraisonnablement grande pour une carte correctement conçue. Des environnements très bruyants existent, mais sont limités aux emplacements connus. Une carte peut ne pas fonctionner à 10 mètres d'un émetteur de 10 kW, mais même cela peut être conçu pour.

La réponse est donc fondamentalement que les signaux numériques sur la même carte, s'ils sont conçus correctement, peuvent être considérés comme absolument fiables pour la plupart des utilisations ordinaires. Dans des cas particuliers où le coût de l'échec est très élevé, comme l'espace et certaines applications militaires, d'autres stratégies sont utilisées. Ceux-ci incluent généralement des sous-systèmes redondants. Vous considérez toujours les signaux individuels sur une carte comme fiables, mais supposez que les cartes ou les sous-systèmes dans leur ensemble peuvent parfois se tromper. Notez également que ces systèmes coûtent beaucoup plus cher, et un tel fardeau rendrait la plupart des systèmes ordinaires, comme les ordinateurs personnels par exemple, inutiles en étant trop chers.

Cela dit, il y a des cas où même en ordinaire une détection et une correction d'erreurs électroniques grand public sont utilisées. C'est généralement parce que le processus lui-même a une certaine probabilité d'erreur et parce que les limites sont repoussées. La mémoire principale haute vitesse pour les ordinateurs inclut souvent des bits supplémentaires pour la détection et / ou la correction des erreurs. Il est moins coûteux d'obtenir les performances et le taux d'erreur ultime en repoussant les limites et en ajoutant des ressources à la correction d'erreur que de ralentir les choses et d'utiliser plus de silicium pour rendre tout intrinsèquement plus fiable.

Surtout pour les protocoles qui ne sont pas conçus pour être utilisés sur des câbles, une carte correctement conçue n'aura pas d'erreurs, et une carte mal conçue ne fonctionnera pas bien avec ou sans vérification des erreurs. Par exemple, des problèmes sur un bus I2C avec plusieurs esclaves peuvent verrouiller le bus de façon permanente (*) à moins que le maître n'ait un pilote capable de tirer SDA haut même lorsque les esclaves essaient de le tirer bas. Se prémunir contre cela ralentirait le protocole, mais si le bus est suffisamment exempt de problèmes pour qu'un tel comportement possible ne soit pas considéré comme un risque, il n'y aurait pas besoin d'une logique de vérification des erreurs en général.

(*) Si un esclave pense voir une condition de démarrage au milieu d'un octet de données en cours de lecture à partir d'un autre appareil, et interprète les données lues comme le démarrage d'une commande qui devrait lire une chaîne de zéros, alors ce serait possible pour chacun des périphériques esclaves d'accuser réception des octets de données envoyés à l'autre de telle sorte qu'à tout moment, au moins un des esclaves maintienne le bus enfoncé.

Pourquoi demandez-vous cela uniquement à propos de la vérification des erreurs?

Comment pouvez-vous être sûr que la condition de départ est interprétée correctement? Sur les communications filaires ou sans fil, le début de la trame est une combinaison très complexe de bits, tandis que sur RS-232 c'est un simple changement de haut en bas, et sur I2C une simple violation de protocole.

Mon point est que non seulement la vérification des erreurs est différente, mais que tous les éléments du protocole sont beaucoup, beaucoup plus simples pour les protocoles embarqués que leurs homologues pour les communications filaires et sans fil. Et la raison en est que la probabilité d'erreur est inférieure de plusieurs ordres à celle des communications filaires / sans fil.

La réponse courte est que de nombreux appareils auxquels I2C et SPI sont destinés sont des appareils à faible consommation avec de petits jeux d'instructions et une mémoire programme limitée. Les spécifications leur permettent d'être implémentées dans un firmware avec peu de frais généraux. Si vous avez la puissance, vous pouvez ajouter autant de couches que nécessaire, mais ces couches élimineraient de nombreuses petites applications intégrées.

Je n'ai pas pu fournir de réponse claire mais une comparaison. Les protocoles réseau ont besoin de couches de mécanismes, faire tout cela en même temps n'est pas une bonne idée, vous n'avez pas de paquet crc dans PHY jusqu'à ce que la couche MAC ait détecté l'erreur RF dans 802.11.

SPI et i2c ont tous une synchronisation synchronisée, donc le taux d'erreur et les conflits de communication dans le timing seront minimum, et le matériel pour les implémenter est considéré comme rare.

c'est tout ce à quoi je peux penser.

Trouvez une solution spécifique à un problème spécifique.

Si vous disposez de 3 relais nécessitant une fiabilité absolue: Mesurez ensuite leur sortie avec 3 entrées numériques, un système de confirmation redondant, adapté à votre application.

Si vous deviez concevoir un protocole de communication personnalisé, pour résoudre tous les problèmes de fiabilité une fois pour toutes, vous commettriez une erreur de conception courante; S'écarter des exigences spécifiques pour se laisser distraire dans les généralités.

Tout d'abord, il est important de se rappeler que I2C est l'acronyme de circuits intégrés à circuits intégrés. Il a été conçu pour fonctionner de puce en puce sur une carte PC. Cependant, avec des systèmes comme le Raspberry Pi conduisant une connexion I2C via des câbles, la norme n'est pas utilisée pour ce à quoi elle était destinée et la dégradation du signal qui en résulte signifie que la transmission sera beaucoup plus sujette aux erreurs. Je lis ce fil parce que je cherche des indices sur la façon de réduire les erreurs I2C dans ma configuration Raspberry Pi.

Cela dit, chaque appareil compatible I2C sur mon bus valide et génère des CRC pour vérifier les erreurs de bus. Ce qui ne vérifie pas les erreurs, c'est le pilote de périphérique I2C entrant sous Linux, mais vous pouvez facilement trouver des bibliothèques en ligne pour C ou Python afin de vérifier les CRC qui reviennent. Ce que je peux vous dire, c'est que les vérifier a été révélateur car une fraction alarmante des données renvoyées était mauvaise. Maintenant, je le jette simplement et j'essaye à nouveau de lire les données, mais la solution à plus long terme est de repenser mon système I2C pour avoir moins de distance / capacité. J'envisage un commutateur I2C pour isoler les appareils sur leurs propres signaux. Ou passer en Modebus ou CANbus qui sont plus robustes électriquement (et un peu plus chers à utiliser car les appareils sont plus chers.)

En raison des faiblesses du standard stimulées par de longues courses de signaux, il existe des erreurs telles que SDA maintenue par un périphérique esclave qui sont irrécupérables en utilisant les pilotes Linux I2C typiques et peuvent nécessiter un cycle d'alimentation. Pour corriger les blocages de bus sur votre Pi, vous pouvez changer les broches I2C en broches d'E / S générales, puis réinitialiser le bus dans le logiciel avec les 9 horloges requises à 400 KHz avant de les remettre à la fonction I2C, mais il y a beaucoup de pièges pour cela, y compris la nécessité de code C pour basculer la broche CLK assez rapidement pour une réinitialisation. Bien que j'aie vu cela discuté en ligne, je n'ai pas encore trouvé de code pour cela et j'envisage de l'écrire moi-même. Ou renflouer I2C.

Au fait, je pense qu'utiliser I2C proche de ce à quoi il était destiné, comme connecter des cartes filles à un Pi, est assez sûr.Je n'ai eu aucun problème avec de telles conceptions.