Spiegeln Sie auf dem PIC16F1829 FERRden Framing-Fehlerstatus des obersten Bytes im seriellen Zwei-Byte-Empfangs-FIFO wider. Unter der Annahme, dass keine neuen Bytes mit Rahmenfehlern ankommen, sollten daher zwei Lesevorgänge von RCREG FERR immer löschen.
Es ist jedoch möglich, dass ich viel zu viel in diese Anmerkung im PIC16F1829-Datenblatt für den USART lese. Der relevante Abschnitt ist 26.1.2.4 auf Seite 287:
Wenn alle Empfangszeichen im Empfangs-FIFO Rahmenfehler aufweisen, werden wiederholte Lesevorgänge des RCREG das FERR-Bit nicht löschen.
Dies scheint zu implizieren, dass, wenn beide Bytes im FIFO Framing-Fehler hätten, FERR für immer stecken bleiben würde. Dies erscheint mir etwas unwahrscheinlich, aber an derselben Stelle beschreibt das Datenblatt, wie das Löschen von FERR durch Zurücksetzen des EUSART erzwungen werden kann.
Hat jemand eine Erklärung? Ich wollte zählen, wenn aufeinanderfolgende Bytes zu einem Framing-Fehler führten, aber wenn ich nicht muss, wäre das schön!
Hier gibt es eine Feinheit, die das Datenblatt nicht erläutert, aber einer der Anwendungshinweise ( AN774 ).
Soweit es geht, ist der FIFO RCREG + ein 1-Byte-Puffer. Plus RSR - das Empfangsschieberegister.
FERR wird niemals aktualisiert, es sei denn, RCREG ist es. Der Vorgang des Lesens von RCREG ermöglicht es jedem wartenden Pufferbyte, sich in RCREG zu bewegen – dies aktualisiert gleichzeitig FERR (immer) und RX9D (falls zutreffend). Somit haben wir drei Fehlertypszenarien:
Ein schlechtes Byte im RCREG und ein ok-Byte im Puffer: FERRist gesetzt, RCIFist gesetzt.
Das Lesen von RCREG bewirkt, dass das gute Pufferbyte zusammen mit seinem Framing-Status in RCREG verschoben wird.
Jetzt FERRist klar, RCIFeingestellt.
Ein fehlerhaftes Byte im RCREG und keine Bytes im Puffer: FERRist gesetzt. RCIFeingestellt ist.
Das Lesen von RCREG führt RCIFzum Löschen. Es ist keine Aktion aktiviert FERR. Es bleibt gesetzt, bis ein gutes Byte in RCREG ankommt.
Ein fehlerhaftes Byte im RCREG und ein fehlerhaftes Byte im Puffer: FERRist gesetzt. RCIFeingestellt ist.
Das Lesen von RCREG bewirkt, dass das Pufferbyte zusammen mit seinem schlechten Framing-Status in RCREG verschoben wird.
Jetzt FERRist eingestellt, RCIFist eingestellt. Puffer ist klar. Die Situation ist jetzt wie unter (2) oben.
Für Situation 3 werden wiederholte Lesevorgänge des RCREG das FERR-Bit nicht löschen. Das ist genau das, was der Zettel sagt.
Bearbeiten: Beachten Sie die Auswirkungen von Szenario (1). Wenn Sie in diesem Fall RCREG lesen, ist FERR für das gerade gelesene Byte nicht gültig. Sie müssen FERR überprüfen, bevor Sie RCREG lesen.
Schnitzel