Rahmenfehler können durch das verursacht werden, was @jippie erwähnt - der Empfänger hat das Startbit erkannt und wo er das Stoppbit erwartet, werden die Daten invertiert. Dies kann auch auf eine Datenbeschädigung zurückzuführen sein, die durch eine auf das Stoppbit auftreffende Leitungsstörung verursacht wird. Sie müssen dies immer für jedes empfangene Byte überprüfen.
Paritätsfehler treten auf, wenn Parität auf der Datenverbindung implementiert ist und eine Beschädigung vorliegt, die eine Paritätsfehlanpassung in den empfangenen Daten verursacht. Sie müssen dies immer für jedes empfangene Byte überprüfen.
Eine Empfangspause wird ebenfalls als Fehler angesehen, obwohl dies tatsächlich ein Hinweis darauf ist, dass die eingehenden Daten länger als 1 Datenbyte auf die logische Null gefallen sind. Normalerweise ist logisch 1 der "Umgebungs" -Zustand zwischen aufeinanderfolgenden Datenbytes und bleibt dies auch. Es ist ein Rückfall in alte Telegraphiesysteme, denke ich. Ich würde dies nicht überprüfen, wenn Sie diese "Funktion" nicht verwenden würden, um dem Empfänger einen Rücksetzbefehl anzuzeigen (z. B.).
Ein Überlauffehler liegt vor, wenn ein neues Byte empfangen wird, bevor das vorherige Byte von einer CPU gelesen wurde. Etwas anders, wenn ein FIFO beteiligt ist, aber dasselbe ist - gültige empfangene Daten gehen aufgrund der Langsamkeit der CPU verloren. Überprüfen Sie dies immer, bevor Sie ein Byte lesen. Wenn das Byte Teil einer längeren Nachricht (oder eines längeren Befehls) ist, werfen Sie die gesamte Nachricht / den gesamten Befehl weg und fordern Sie den Sender auf, die gesamte Nachricht / den gesamten Befehl erneut zu senden.
Unter Ausführen ist kein wirklicher Fehler, sondern zeigt dem sendenden UART an, dass sein Sendepuffer leer ist, dh er fordert ein neues Byte zum Senden an. Sie müssen dies nicht überprüfen.