D'après mon expérience, presque tous les équipements et systèmes avec lesquels j'ai travaillé sautent la parité et utilisent simplement les sommes de contrôle des messages ou les CRC pour détecter les erreurs.

Si vous avez la capacité d'interrompre un message, une erreur de parité peut être utilisée pour tuer une mauvaise transmission plus rapidement qu'un contrôle CRC, en particulier pour les paquets de grande taille. Sinon, un contrôle CRC attrapera tout ce qu'un contrôle de parité, et plus encore. Si vous êtes vraiment concerné, vous pouvez utiliser des méthodes de détection logicielles supplémentaires, telles que la vérification du contexte et la mise en miroir des messages. Les délais d'attente peuvent être utilisés pour empêcher l'OSD de tomber définitivement dans un état incorrect.

Parité paire / impaire

Cela dépendra légèrement de la communication que vous utilisez. Je sais que vous avez dit que vous utilisez UART, mais je vais répondre un peu plus large. Si vous décidez d'aller avec la parité, sélectionnez l'option qui fera que votre état "inactif" exigera que le bit de parité change.

Si vous avez un système actif haut, alors tous les 0 sont inactifs. Donc, faites en sorte que la parité soit étrange pour que le bit de parité doive changer d'état de repos.

Dans un système actif bas, vous devriez regarder combien de bits la parité sera terminée. S'il s'agit de 8 bits, la parité même se traduira par un bit de parité 0, ce qui suit l'idée de forcer un changement d'état pour la parité.

Devriez-vous utiliser la parité?

Eh bien, ce sont des questions un peu difficiles. En général, nous aimons modéliser le bruit comme un bruit gaussien, ce qui signifie que les erreurs sur les bits seront complètement aléatoires. En réalité, le bruit qui a un effet sur notre système n'est pas toujours aléatoire. La raison en est que les éléments qui peuvent provoquer des erreurs sur un PCB sont des radiateurs provenant d'autre chose. Si vous y réfléchissez bien, pour qu'une trace aussi courte ait suffisamment de bruit pour provoquer une erreur de bit, il fallait que ce soit quelque chose d'assez extrême. Lorsque vous avez une source de bruit comme celle-ci, il y a de bonnes chances que vous retourniez plus d'un bit. La parité est inutile contre un nombre pair d'erreurs sur les bits. Sans plonger dans les mathématiques, la parité aidera, mais n'aidera pas des tonnes. Si vous ne pouvez pas vous permettre d'effectuer beaucoup de traitement, la parité est peut-être le meilleur que vous puissiez faire.

Pourquoi utiliser un CRC?

Tout d'abord, vous dites que vous avez un générateur CRC intégré, cela signifie qu'il devrait vous être très facile de calculer. Les CRC sont bien meilleurs pour détecter les erreurs sur plusieurs bits. Dans un environnement où vous voulez une très faible chance d'obtenir des erreurs, vous voulez vraiment utiliser un CRC. En fait, optez pour le plus grand CRC que vous pouvez vous permettre dans votre système. Une petite astuce que je sais fonctionne pour au moins crc16 sinon d'autres est que si vous CRC le message que vous avez reçu avec le CRC dessus, vous devriez obtenir 0 comme réponse. Si vous avez du matériel pour calculer le CRC, c'est un moyen très efficace à la fois de générer le CRC et de vérifier le CRC.

Je travaillerais d'abord sur le blindage de ce fil.

Mettez des plans au sol autour de lui (et / ou) enterrez-le dans des couches internes entre les plans au sol. Alors, faites confiance au CRC. Utilisez la parité si elle est gratuite.

Si vous utilisez la parité, réfléchissez à la manière dont vous allez gérer l'erreur dans votre code. Si vous ne disposez pas d'un moyen efficace de gérer la détection des erreurs, cela ne vous aidera pas beaucoup.

La parité est inutile, à mon avis.

Avec de courtes connexions puce à puce sur une seule carte comme celle-ci, tant que vous conduisez correctement les lignes, cela devrait être pratiquement sans bruit - - au moins par rapport à, disons, votre DRAM.Certaines personnes s'attendent à une erreur de bit soft, par jour, par gigaoctet de DRAM.Comment savez-vous que l'erreur que vous avez vue n'a pas été causée par une telle erreur de bit soft, plutôt que par du bruit Si vous avez induit un bruit assez gros pour retourner un peu sur une trace de PCB correctement pilotée, vous avez probablement d'autres problèmes plus importants à craindre. (Par «correctement conduit», je veux dire soit conduire activement chaque ligne tout le temps , ou utilisez une résistance pull-up ou une résistance pull-down pour définir l'état entre les messages).

Avec des connexions hors carte à plus longue portée, il est souvent inévitable d'avoir occasionnellement des fils flottants qui présentent une broche d'entrée avec un bruit aléatoire plus ou moins continu, et même lorsque vous transmettez un message, vous obtenez souvent des erreurs de bits.Dans ce cas, la parité vaut mieux que rien. bt2 mentionné, vous voudrez utiliser CRC afin de pouvoir attraper de nombreuses erreurs que la parité manque complètement, et une fois que vous avez CRC, ajouter la parité n'aide pas de manière significative.

S'il est possible de mettre votre système dans un "mauvais état", essayez de concevoir les choses de telle sorte qu'il revienne à un bon état dans un laps de temps raisonnable.Utilisez les temporisations de communication et les minuteries de surveillance comme markrages et bt2 mentionnés.Réémettez périodiquement les commandes d'initialisation de sorte que peu importe Dans quel état étrange se trouve le récepteur, il est remis à l'état correct.

"La statique du satellite a affecté son ordinateur qui a lu le bruit comme une commande d'arrêt. Pour surmonter le problème, les contrôleurs ont envoyé un flux continu de commandes ON au satellite pour qu'il reste allumé. "- Satellites radioamateurs: OSCAR-6

Vous ne voulez pas de parité. Vous voulez une communication plus fiable.

La raison pour laquelle la parité est peu utilisée est qu'elle est chère en termes de débit de données. Cela commence par rendre une trame presque 10% plus longue: bit de départ + 8 bits de données + parité + bit d'arrêt = 11 bits au lieu de 10. Mais c'est bien pire que cela. Si vous avez un moyen de savoir si vous avez correctement reçu les données, vous avez le devoir de faire quelque chose avec cela. Ignorer simplement la communication erronée ne suffira pas; l'émetteur doit le renvoyer. Il a donc besoin de savoir s'il a été bien reçu. Vous devrez envoyer un accusé de réception ( ACK / NAK ) après chaque octet, et l'émetteur ne peut pas envoyer l'octet suivant avant d'avoir reçu le ACK . Si vous utilisez des codes ASCII, c'est 11 bits de retour. Donc, cela réduit de moitié le débit, et nous avons déjà perdu 10%, donc nous sommes maintenant à une efficacité de la charge utile de 36% , contre 80%. Et c'est la raison pour laquelle personne n'aime vraiment la parité.

Remarques:
1. Vous n'avez pas besoin d'accuser réception d'un accusé de réception; la distance de Hamming entre les codes ASCII pour ACK et NAK est de 3 (avec une parité même 4), donc une erreur dans la réception de ACK / NAK peut être non seulement détecté, mais aussi corrigé .
2. De nombreux UART peuvent fonctionner avec des longueurs de données allant jusqu'à 5 bits, et il est possible de passer à 5 bits pour envoyer l ' ACK , mais ce n'est qu'une simple vitrine, et cela ne fait que compliquer la communication.

Une meilleure solution peut être d'utiliser un CRC à la fin de chaque bloc. Les CRC sont meilleurs que les bits de parité pour capturer plusieurs erreurs (mais ils ne peuvent toujours pas les corriger). Une efficacité améliorée ne peut être obtenue que pour de longs blocs; si un bloc se compose de seulement 2 octets, il ne sert à rien d'ajouter un CRC 8 bits.
Un autre inconvénient serait que vous devez quand même accuser réception de la bonne réception. Alors ce n'est probablement pas ça non plus.

Que diriez-vous des codes auto-corrigés ? Les codes de hamming ajoutent peu de frais généraux et vous permettent de corriger vous-même 1 bit erroné; plus besoin de reconnaître. Comme les CRC, les codes de Hamming sont plus efficaces sur des blocs plus longs; le nombre de bits supplémentaires est défini comme étant

\ $ N + H < 2 ^ H \ $

où N = nombre de bits de données, et H = nombre de bits de Hamming. Donc, pour corriger 1 bit dans une communication 8 bits, vous devez ajouter 4 bits de Hamming; un cinquième bit de Hamming n'est requis qu'à partir de 12 bits de données. C'est le moyen le plus efficace de détection / correction d'erreurs sur des messages courts (quelques octets), bien qu'il nécessite un peu de jonglage avec vos données: les bits de Hamming doivent être insérés à des positions spécifiques entre vos bits de données.

Maintenant, avant d'ajouter les codes de correction d'erreur de Hamming, il vaut la peine de regarder dans votre configuration. Vous pouvez vous attendre à des erreurs sur une ligne de 100 m passant entre des machines lourdes, mais vous ne devriez pas avoir d'erreurs sur une ligne de 2 cm. S'il capte du bruit, c'est peut-être une impédance trop élevée. Les conducteurs poussent / tirent-ils? Si c'est le cas, ils devraient pouvoir vous donner des bords rapides, sauf si votre "câble" est capacitif, ce qui ne sera pas à cette courte distance. Existe-t-il des traces de courant élevé parallèles aux lignes de données? Ils pourraient provoquer du bruit. Avez-vous vraiment besoin de cette vitesse élevée et les horloges des deux côtés correspondent-elles assez étroitement? Ralentir à 57600 bits par seconde peut résoudre le problème.

Malgré la pléthore de réponses, j'ajouterai mon article. La parité fonctionnera au niveau des octets et un CRC fonctionnera (généralement) au niveau des paquets. Les schémas de paquets sont à mon avis supérieurs aux communications de type octet brut. Si votre matériel rejette un seul octet en fonction de la parité, c'est parfait pour un flux d'octets brut, mais pas si bon pour un paquet. Tout d'un coup, boum, vous avez manqué un octet au milieu d'un paquet - ce qui fausse votre analyse. Dans le meilleur des cas, tout votre paquet est parti, mais si votre algorithme de recherche de paquets n'est pas bon, vous pourriez potentiellement en perdre plus (et j'ai vu des algorithmes de détection de paquets en état de mort cérébrale utilisés dans de vrais produits). Utilisez des paquets et des CRC comme cela a été suggéré.

La parité est généralement inutile avec une communication de style asynchrone "normale", mais elle peut être utile dans d'autres contextes. Par exemple, certains schémas de codage différentiel exigent que chaque caractère ait un nombre pair de transitions de ligne afin que l'état final de la ligne corresponde à l'état initial. Les codes à barres Code 39 utilisent la parité, sorte de (*), pour valider des caractères individuels, et éliminent généralement le besoin d'un caractère de somme de contrôle.

Si les erreurs sur un seul bit étaient beaucoup plus courantes et les erreurs multi-bits ou le cadrage erreurs, la vérification de la parité par octet pourrait être un complément utile à une somme de contrôle ou à un CRC, car localiser un octet avec une erreur permettrait de corriger l'erreur. Dans la plupart des situations pratiques impliquant des UART, cependant, de nombreux problèmes de ligne provoquent des erreurs de cadrage, rendant la récupération de données dans de nombreux cas impossible avec ou sans parité par octet.

(*) Un caractère Code 39 valide doit avoir un impair nombre d'espaces larges (1 ou 3) et un nombre pair de larges barres (0 ou 2).