Gestion des erreurs UART

Je ne me concentre pas sur un MCU spécifique car l'UART de la plupart des contrôleurs a une architecture similaire. Ils ont des FIFO pour Tx et Rx.

Les erreurs les plus courantes générées par UART sont: - 1. Erreur de trame 2. Erreur de parité 3. Erreur de dépassement (dépassement des FIFO Tx / Rx) 4. Erreur de rupture de réception (une erreur avec les bits d'arrêt)

Comment gérer ces conditions d'erreur pour maintenir la communication correctement?

Je comprends que c'est une question vague, mais la plupart du temps, les gens se trompent sur ce qu'il faut faire lorsque de telles erreurs se produisent et finissent par effacer les bits d'erreur.

Pour réellement répondre à votre question, je rejette généralement tout ce qui a été reçu avec erreur. Cela peut inclure la réinitialisation du matériel UART, en fonction de l'erreur et des détails du matériel UART.

La seule exception est si vous souhaitez recevoir délibérément des pauses. Ceux-ci apparaissent comme des erreurs de cadrage. Dans ce cas, vous transmettez les erreurs de cadrage aux niveaux supérieurs comme conditions spéciales. Cependant, cela nécessite que les informations hors bande soient transmises aux niveaux supérieurs et, par conséquent, l'interface du récepteur UART ne peut pas être considérée comme quelque chose d'aussi simple que d'obtenir un flux d'octets. Je pense que je l'ai fait exactement une fois dans de nombreux projets de microcontrôleurs car il devait être compatible avec un ancien système où les pauses étaient utilisées délibérément.

Steven vous a donné de bonnes idées sur ce qu'il faut faire à ce niveau supérieur. Lorsque vous pensez qu'il existe un risque réel d'erreurs et que l'intégrité des données est importante, vous encapsulez généralement des morceaux de données dans des paquets avec des sommes de contrôle. Le récepteur envoie un ACK pour chaque somme de contrôle correctement reçue.

Cependant, la grande majorité des erreurs UART sont si peu probables et pas absolument critiques que vous pouvez simplement les ignorer au niveau élevé. Le type d'erreurs que le matériel UART peut détecter est généralement dû à la stupidité de l'opérateur, pas au bruit de ligne. La plupart comme le bruit entraînera de mauvaises données, que l'UART ne détectera pas. Ainsi, le pilote UART de bas niveau rejette tout ce qui est immédiatement associé à une erreur UART, mais continue sinon à transmettre le flux d'octets reçus au niveau suivant. En fait, il le fait même si vous utilisez des paquets et des sommes de contrôle, car cela se fait à un niveau supérieur à celui où les octets individuels sont reçus.

Ces erreurs ne peuvent pas être corrigées, une retransmission est donc requise. Cela nécessite un protocole à un niveau plus élevé que l'UART; vous voudrez généralement accuser réception de la bonne réception d'un paquet de données. Ce paquet peut être de 1 octet, mais des paquets plus longs peuvent également être utilisés si la communication comporte peu d'erreurs. Acquittez chaque paquet en envoyant un ACK à l'émetteur, un NACK en cas d'erreur. Dans ce dernier cas, jetez le paquet et attendez la retransmission.
Si vous utilisez des transferts de paquets, vous voudrez peut-être envisager la vérification des erreurs CRC au lieu de la parité, ce qui n'est pas très efficace (ajoute 1 bit par octet) et ne capture que les erreurs sur un seul bit.

Lorsqu'il y a une erreur de cadrage dans les données UART reçues, il y a de fortes chances que tous les octets suivants soient des ordures jusqu'à ce que, selon l'UART, il y ait au moins dix temps de bits entre les fronts descendants consécutifs sur le câble de données, dix-neuf temps de bits d'espacement consécutif, ou neuf fois bits de marquage consécutif (le dernier de ceux-ci fonctionnera sur tous les UART). Si l'on reçoit un octet correctement cadré avec la valeur 0x00 ou 0x80 (0x100 en mode 9 bits) et que l'émetteur n'envoie pas de longues pauses ou que le récepteur cesse d'essayer d'analyser les octets de toute longue pause que l'émetteur envoie, on peut assurez-vous qu'il est correct et que les octets suivants le seront également. Si l'on reçoit une valeur dans laquelle il y a 0-6 "zéros" consécutifs dans les bits inférieurs, et les bits restants sont tous définis,

S = START P = données d'octet précédent s = stop D = octet actuel - = inactif
0111111101000000011111 - Signal en ligne
Ps ------ SDDDDDDDDs ---: comme prévu par l'émetteur (0x02)
SPPPPPPPPsSDDDDDDDDs-: Tel que reçu (0xC0)

Si chaque paquet commence par 0x00 et est suivi par 0xFF, une erreur de trame sur un paquet n'affectera pas le suivant. Lorsque le récepteur remarque l'erreur de tramage, il peut commencer à rejeter les données jusqu'à ce qu'il voit un 0x00 correctement cadré, après quoi il saura qu'il a un début légitime de paquet.