Raspberry Pi - UART - Framing error

Matthias Gast #3979565
Lesenswert?
• ▲
▼ 
Hallo,

ich möchte beim Raspberry Pi (Modell B v2.0) die UART in einem 
C-Programm konfigurieren und auslesen. Ich verwende dazu die Funktionen 
aus termios.h.

Mein Problem:
Ich möchte die UART so konfigurieren, dass weder Paritätsfehler noch die 
BREAK-Kondition berücksichtig werden, sondern ausschließlich framing 
errors (fehlendes Stoppbit) mit der Sequenz '\377' '\0' signalisiert 
werden.

Hier ein Auszug aus meiner Konfiguration:

1
cfsetispeed(&rpiOpt, B9600); // set baud rate line in

2
cfsetospeed(&rpiOpt, B9600); // set baud rate line out

3


4
rpiOpt.c_cflag &= ~PARENB;   // no parity bit

5
rpiOpt.c_cflag &= ~CSTOPB;   // 1 stop bit

6
rpiOpt.c_cflag &= ~CSIZE;    // 8 data bits

7
rpiOpt.c_cflag |= CS8;

8
rpiOpt.c_cflag |= CLOCAL;        

9
rpiOpt.c_cflag |= CREAD;     // allow read access

10


11
rpiOpt.c_lflag &= ~ICANON;   // non-canonical mode (raw mode)

12
rpiOpt.c_lflag &= ~(ECHO | ECHOE); // no echo

13
rpiOpt.c_lflag &= ~ISIG;     // no interrupts

14
    

15
rpiOpt.c_iflag &= ~IGNPAR;   // do not ignore input framing/parity errors

16
rpiOpt.c_iflag &= ~INPCK;    // disable input parity checking

17
rpiOpt.c_iflag |= PARMRK;    // mark framing/parity errors

18
rpiOpt.c_iflag |= IGNBRK;    // ignore BREAK

19
    

20
rpiOpt.c_oflag &= ~OPOST;    // raw output

21
  

22
rpiOpt.c_cc[VMIN] = 0;       // wait for at least 0 chars

23
rpiOpt.c_cc[VTIME] = 10;     // timeout 1 second

24


25
tcflush(rpiFd, TCIOFLUSH);

26
    

27
tcsetattr(rpiFd, TCSAFLUSH, &rpiOpt);


Der Zeichenempfang funktioniert soweit. Doch leider werden keine framing 
errors markiert - obwohl definitiv vorhanden!

Wie muss ich die Konfig. abhändern? Ist das gewünschte Verhalten über 
termios.h überhaupt möglich?

Vielen Dank im Voraus!

Gruß,
Matthias
Beitrag melden Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Markierten Text zitieren Antwort Antwort mit Zitat
Matthias Gast #3979605
Lesenswert?
• ▲
▼ 
Wenn ich es richtig verstanden habe, sind die Paritätsprüfung und der 
Framecheck unabhängig. Das eine prüft, ob das Paritätsbit zu den 
Datenbits passt, das andere, ob das Stoppbit zum erwarteten Zeitpunkt 
eintrifft.

Die Nachrichten, die ich empfange, haben KEIN Paritätsbit, daher soll 
die Paritätsprüfung auch deaktiviert werden. Trotzdem sollen framing 
errors erkannt werden, also die Tatsache, dass das Stoppbit fehlt.

Den Raw-Mode habe ich gewählt, weil ich in jedem Fall ALLE Bytes 
empfangen möchte, egal ob mit oder ohne framing error. Ich möchte nur 
informiert werden, falls ein framing error aufgetreten ist oder nicht.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
OldMan Gast #3979631
Lesenswert?
• ▲
▼ 
Matthias schrieb:
> Den Raw-Mode habe ich gewählt, weil ich in jedem Fall ALLE Bytes
> empfangen möchte,

Framing errors can be detected with parity bits.

Jedoch sollte man, wenn man eine wirklich sichere Übertragung 
sicherstellen will ein Transportprotokoll implementieren.
Dazu eignet sich bspw. schon ein CRC-Check. Hier gut beschrieben: 
http://www.lammertbies.nl/comm/info/crc-calculation.html

Früher setzte man oft STX/ETX Protokoll ein.
Ein zu übertragender Datenblock wurde wie folgt eingerahmt:
STX Daten ETX BCC

BCC = BlockCheckCharacter (ist ein Bytewert des X-OR über alle Daten)
Besser ist ein CRC-16 oder CRC-32 anstelle des BCC.
Kann leicht über Tabellen generiert werden.

Damit kann der Empfänger prüfen, ob der Datenblock ok ist oder nicht.
Im negativen Fall sendet er ein NAK und im positiven Fall ein ACK an den 
Sender.
Nachdem der Sender ein NAK erhalten hat, wiederholt er den Block.
Beim ACK geht es mit dem nächsten Block weiter.

Ergo: Wenn die Datenübertragung gesichert sein soll, kommt man um ein 
minimales Protokoll nicht herum.

Weitere, höhere,Übertragungsprotokolle sind bspw.: HDLC/SDLC, LSV1, 
MSV1, usw.
Google mal danach.
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Matthias Gast #3979747
Lesenswert?
• ▲
▼ 
Danke für die Info, aber mir geht es nicht darum eine sichere, robuste 
Übertragung zu implementieren. Mich interessieren ausschließlich die 
fehlenden Stoppbits, da die Kommunikation mit 8N1 läuft und daher 
ohnehin keine Paritätsbits enthält.

Irgendwie muss ich doch das FE (framing error) Bit, NICHT das PE (parity 
error) Bit!, von der Raspberry Pi Uart alleine auswerten können!?
Beitrag melden Bearbeiten Löschen Markierten Text zitieren Antwort Antwort mit Zitat
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren