Behandlung von UART-Fehlern

Ich konzentriere mich nicht auf eine bestimmte MCU, da UART der meisten Controller eine ähnliche Architektur hat. Sie haben FIFOs für Tx und Rx.

Die häufigsten von UART generierten Fehler sind: - 1. Rahmenfehler 2. Paritätsfehler 3. Überlauffehler (Überlauf von Tx / Rx-FIFOs) 4. Empfangspausenfehler (einige Fehler mit Stoppbits)

Wie sollte man mit diesen Fehlerbedingungen umgehen, um die Kommunikation richtig aufrechtzuerhalten?

Ich verstehe, dass es eine vage Frage ist, aber die meisten Leute sind verwirrt darüber, was man tun soll, wenn solche Fehler auftreten, und am Ende werden nur die Fehlerbits gelöscht.

Um Ihre Frage tatsächlich zu beantworten, verwerfe ich normalerweise alles, was fehlerhaft empfangen wurde. Dies kann eine Neuinitialisierung der UART-Hardware umfassen, je nachdem, um welchen Fehler es sich handelt und welche Details die UART-Hardware enthält.

Die einzige Ausnahme ist, wenn Sie absichtlich Pausen erhalten möchten. Diese werden als Rahmenfehler angezeigt. In diesem Fall übergeben Sie Rahmenfehler als Sonderbedingungen an die höheren Ebenen. Dies erfordert jedoch, dass Out-of-Band-Informationen an die höheren Ebenen weitergeleitet werden, und daher kann die UART-Empfängerschnittstelle nicht als so einfach angesehen werden wie das Abrufen eines Bytestroms. Ich glaube, ich habe dies in vielen Mikrocontroller-Projekten genau einmal gemacht, weil es mit einem alten System kompatibel sein musste, bei dem Pausen absichtlich verwendet wurden.

Steven hat Ihnen einige gute Ideen gegeben, was Sie auf der höheren Ebene dagegen tun können. Wenn Sie der Meinung sind, dass eine echte Fehlerwahrscheinlichkeit besteht und die Datenintegrität wichtig ist, kapseln Sie normalerweise Datenblöcke in Pakete mit Prüfsummen. Der Empfänger sendet eine Bestätigung für jede korrekt empfangene Prüfsumme.

Die überwiegende Mehrheit der Zeit, in der UART-Fehler auftreten, ist jedoch so unwahrscheinlich und nicht unbedingt kritisch, dass Sie sie auf hoher Ebene einfach ignorieren können. Die Art von Fehlern, die die UART-Hardware abfangen kann, ist normalerweise auf die Dummheit des Bedieners zurückzuführen, nicht auf Leitungsrauschen. Am ähnlichsten verursachen Rauschen schlechte Daten, die der UART nicht erkennt. Der UART-Treiber auf niedriger Ebene gibt also alles aus, was unmittelbar mit einem UART-Fehler verbunden ist, leitet den Strom der empfangenen Bytes jedoch weiterhin an die nächste Ebene weiter. Dies geschieht sogar dann, wenn Sie Pakete und Prüfsummen verwenden, da dies auf einer höheren Ebene erfolgt als dort, wo einzelne Bytes empfangen werden.

Diese Fehler können nicht behoben werden, daher ist eine erneute Übertragung erforderlich. Dies erfordert ein Protokoll auf einer höheren Ebene als der UART. In der Regel möchten Sie den korrekten Empfang eines Datenpakets bestätigen. Dieses Paket kann 1 Byte groß sein, es können jedoch auch längere Pakete verwendet werden, wenn die Kommunikation nur geringe Fehler aufweist. Bestätigen Sie jedes Paket, indem Sie eine ACK an den Sender senden, einen NACK, wenn ein Fehler aufgetreten ist. Im letzteren Fall verwerfen Sie das Paket und warten Sie auf die erneute Übertragung.
Wenn Sie Paketübertragungen verwenden, sollten Sie die CRC-Fehlerprüfung anstelle der Parität in Betracht ziehen. Dies ist nicht sehr effizient (fügt 1 Bit pro Byte hinzu) und fängt nur Einzelbitfehler ab.

Wenn in den empfangenen UART-Daten ein Rahmenfehler auftritt, stehen die Chancen gut, dass alle nachfolgenden Bytes Müll sind, bis je nach UART zehn oder mehr Bitzeiten zwischen aufeinanderfolgenden fallenden Flanken auf der Datenleitung neunzehn Bitzeiten liegen von aufeinanderfolgenden Abständen oder neun Bit-Zeiten von aufeinanderfolgenden Markierungen (die letzte davon funktioniert auf allen UARTs). Wenn man ein korrekt gerahmtes Byte mit dem Wert 0x00 oder 0x80 empfängt (0x100 im 9-Bit-Modus) und entweder der Sender keine langen Pausen sendet oder der Empfänger aufhört, Bytes aus einer langen Pause zu analysieren, die der Sender sendet, kann man dies Seien Sie versichert, dass es korrekt ist und nachfolgende Bytes ebenfalls korrekt sind. Wenn man einen Wert erhält, bei dem 0-6 aufeinanderfolgende "Nullen" in den unteren Bits vorhanden sind und die verbleibenden Bits alle gesetzt sind,

S = START P = vorherige Byte-Daten s = Stopp D = aktuelles Byte - = Leerlauf
0111111101000000011111 - Signal online
Ps ------ SDDDDDDDDs ---: Wie vom Sender vorgesehen (0x02)
SPPPPPPPPsSDDDDDDDDs-: Wie empfangen (0xC0)

Wenn jedes Paket mit 0x00 beginnt und auf 0xFF folgt, wirkt sich ein Rahmenfehler bei einem Paket nicht auf das nächste aus. Wenn der Empfänger den Framing-Fehler bemerkt, kann er Daten verwerfen, bis er eine richtig gerahmte 0x00 sieht, woraufhin er weiß, dass es einen legitimen Paketstart gibt.