Question:
Pourquoi les communications à bord comme I2C, SPI, etc. n'ont-elles pas de vérification d'erreurs en général?
Alper
2016-06-04 02:18:59 UTC
view on stackexchange narkive permalink

Certaines méthodes de vérification des erreurs telles que le contrôle de parité, la somme de contrôle, le CRC, etc. sont utilisées pour les communications filaires / sans fil. Cependant, la plupart des CI avec des interfaces telles que I2C, SPI, etc. n'utilisent pas de méthode de vérification des erreurs.

Cherchons "i2c i / o expander" et ouvrons une feuille de données aléatoire. Par exemple, considérons PCF8574 de TI qui est un module d'extension d'E / S 8 bits. Si un bit correspondant au registre de sortie est inversé pendant la transmission I2C, l'IC conduira la broche correspondante à un niveau indésirable. Pourquoi la plupart de ces types de CI n'ont aucun mécanisme de vérification des erreurs? Mon hypothèse est que même si la communication se fait entre les circuits intégrés, tous les signaux sont bruyants. Bien que la probabilité soit assez faible, le bruit peut provoquer un léger retournement.

Est-ce que cela peut être la raison?: Aucun mécanisme de vérification des erreurs ne garantit une communication totalement sans erreur. Ils ne peuvent que nous aider à réduire la probabilité d'erreur. Il est évident que la probabilité d'erreur sur les bits pour une communication longue portée est plus élevée que pour une communication embarquée. Peut-être que la probabilité d'erreur de bit pour la communication à bord est dans une plage acceptable même sans aucun mécanisme de vérification d'erreur.

Que pensez-vous?

Pour la même raison, une route n'offre pas de coussin en cas de chute.La route fournit juste l'avenue pour transporter votre voiture.Vous pouvez mettre dans votre voiture tout équipement de sécurité que vous désirez.Les ports série offrent un moyen de transporter des bits de données.Il appartient au concepteur de fournir autant de vérification des erreurs et des pannes qu'il le souhaite.
la vitesse à laquelle vous synchronisez le bus et le niveau de tension utilisé (i2c est un collecteur ouvert, vous pouvez utiliser une large gamme de tensions) aide considérablement à réduire les erreurs possibles
`Si un bit correspondant au registre de sortie est retourné pendant la transmission I2C, l'IC conduira la broche correspondante à un niveau indésirable.
@Passerby il signifie, si vous envoyez une commande à l'expandeur I2C IO, pour changer les états de sortie, si pour une raison quelconque il y a une condition où l'un des bits qui représente la broche de sortie se trouve avoir du bruit pendant le cycle d'horloge,la sortie prévue sera différente de ce que l'IC émet réellement, grâce à l'octet de commande sur I2C ayant du bruit
@DanLaks Je comprends votre point de vue.Je peux ajouter une vérification d'erreur si * je * conçois les unités qui communiquent sur le port série.Dans le cas I2C, les commandes et le protocole sont fixés par le fournisseur IC et ils n'incluent aucune vérification d'erreur en général.
L'explication de @Passerby KyranF est ce que j'essayais de dire.Merci KyranF
Veuillez le modifier, car ce n'est pas clair pour le moment.
Certains périphériques I2C / SMBus / PMBus prennent en charge PEC, un type de CRC 8 bits.En cas de discordance, le paquet est rejeté.Cela nécessite toujours l'application pour fermer la boucle, c'est-à-dire détecter que la commande demandée n'a pas pris effet, ou renvoyer la requête.
Vous ne pouvez pas effectuer de détection ou de correction d'erreur sans ajouter de frais généraux au protocole.Différentes applications ont des besoins différents en ce qui concerne l'équilibre entre leur tolérance (et risque) d'erreurs et leur tolérance aux frais généraux.Il n'y a pas de solution universelle, donc la meilleure approche est de ne pas le faire du tout à ce niveau, mais plutôt de permettre aux niveaux supérieurs de la pile de protocoles de s'en occuper au besoin.
Sept réponses:
#1
+11
Olin Lathrop
2016-06-04 02:57:45 UTC
view on stackexchange narkive permalink

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.

Merci pour la longue réponse.Je n'ai pas considéré un cas particulier pour ne pas recevoir le bit correct en fait.Ma pensée était beaucoup plus simple.J'ai utilisé des contrôleurs d'E / S I2C dans mes applications pour contrôler quelque chose et je ne veux pas ouvrir un relais en raison d'un simple retournement, disons.Le bruit additif est partout (résistances, transistor, etc.), pourquoi ne provoque-t-il pas un petit retournement pendant la communication.?
#2
+6
supercat
2016-06-04 02:28:10 UTC
view on stackexchange narkive permalink

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é.

Voir aussi: SMBus.
Commentaire: en général, un maître ** ne peut ** tirer SDA haut depuis son collecteur ouvert piloté.Même si un maître passait temporairement à la sortie push-pull et conduisait haut, vous auriez une bataille de bus avec un esclave à faible conduite, se retrouvant avec un état indéterminé et des dommages possibles à la puce.La bonne façon d'essayer d'effacer le bus est de basculer SCL jusqu'à ce que les esclaves libèrent SDA, puis d'envoyer (je crois) environ 8 horloges supplémentaires.
@DoxyLover: S'il y a deux esclaves ou plus et qu'ils sont désynchronisés, on peut avoir une situation où un esclave tire le SDA au niveau bas pendant huit cycles sur neuf, et un autre tire le SDA au niveau bas pendant huit cycles sur neuf différents.Aucun nombre d'impulsions SCK ne résoudrait la situation.Si le maître était connecté à chaque esclave * indépendamment * via par ex.Une résistance de 100 ohms, et pourrait tirer le SDA fort tout en cyclant le SCK pendant neuf impulsions résoudrait probablement le problème.Ce n'est pas une bonne solution, mais mon point principal est qu'il faut éviter de laisser I2C entrer dans cette situation en premier lieu.
#3
+3
Claudio Avi Chami
2016-06-04 02:31:50 UTC
view on stackexchange narkive permalink

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.

Le bit ACK vérifie la réception de la commande, non?(Et si ACK est retourné? Va pour toujours ...) La retransmission est un autre point de communication et elle est acceptable pour de nombreuses applications.Conduire une broche à un niveau incorrect en raison d'un retournement de bits et d'une vérification des erreurs insuffisante est beaucoup plus critique que la retransmission.
#4
+2
John Birckhead
2016-06-04 03:06:30 UTC
view on stackexchange narkive permalink

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.

Cependant, je ne peux pas changer le comportement de l'extension d'E / S I2C mentionnée même si je me connecte à un processeur quad core (puissance).Je ne peux pas ajouter un mécanisme de correction d'erreur supplémentaire en plus de cela.
#5
  0
einzeln00
2016-06-04 02:31:42 UTC
view on stackexchange narkive permalink

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.

#6
  0
user5792628
2018-02-10 17:31:46 UTC
view on stackexchange narkive permalink

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.

#7
  0
Eric Novikoff
2020-03-18 22:44:24 UTC
view on stackexchange narkive permalink

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.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...