serielle Schnittstelle: gehen Zeichen verlohren, wenn interface nicht offen gehalten wird?

[montagskind (Gast)]

Ich verwende eine (USB-FTDI) serielle Schnittstelle in Linux, um 
ASCII-Zeichen zu empfangen. Hier bin ich mir nun aber nicht sicher in 
wieweit sich nun das geöffnet lassen der Schnittstelle auf die Daten 
auswirkt.

Wenn die Daten kontinuierlich an den PC gesendet werden, dann gehen sie 
doch (bei voll gelaufenen Puffer) genauso verloren, als wenn die 
Schnittstelle zwischendurch immer wieder mal geöffnet/geschlossen wird. 
Oder?

[50c (Gast)]

montagskind schrieb:
> Wenn die Daten kontinuierlich an den PC gesendet werden, dann gehen sie
> doch (bei voll gelaufenen Puffer) genauso verloren,

ja

[asdfasd (Gast)]

Wenn das Gerät nicht geöffnet ist, existiert nicht mal ein Puffer - es 
wird alles was ankommt weggeschmissen.

[Jim M. (turboj)]

montagskind schrieb:
> Wenn die Daten kontinuierlich an den PC gesendet werden, dann gehen sie
> doch (bei voll gelaufenen Puffer) genauso verloren

Wenn der FIFO im FTDI Chip voll läuft, kann er Flow Control Signale 
Setzen (Hardware oder Software Handshake). Ohne Datenflusskontrolle 
nutzt Dir das allerdings nix. IIRC haben moderne FTDI Chip mehrere 100 
Byte FIFOs.

montagskind schrieb:
> wenn die
> Schnittstelle zwischendurch immer wieder mal geöffnet/geschlossen

Dabei könnte der Treiber u.U. einen FIFO Flush machen. Du musst ja beim 
Öffnen auch die Parameter (wie Baudrate) angeben - alte Daten sind dann 
bei geänderten Werten womöglich kompletter Müll.

[Sascha W. (sascha-w)]

montagskind schrieb:
> Ich verwende eine (USB-FTDI) serielle Schnittstelle in Linux, um
> ASCII-Zeichen zu empfangen. Hier bin ich mir nun aber nicht sicher in
> wieweit sich nun das geöffnet lassen der Schnittstelle auf die Daten
> auswirkt.
bei geöffneter Schnittstelle könnte der Treiber u.U. noch einen 
zusätzlichen Puffer in Software verwenden.

> Wenn die Daten kontinuierlich an den PC gesendet werden, dann gehen sie
> doch (bei voll gelaufenen Puffer) genauso verloren, als wenn die
> Schnittstelle zwischendurch immer wieder mal geöffnet/geschlossen wird.
> Oder?
Warum sollte man die Schnittstelle schließen wenn man doch Daten 
empfangen will?
Also der FTDI empfängt, nachdem die Schnittstelle einmal geöffnet war, 
auch bei geschlossener Schnittstelle mit den eingestellten Parametern 
weiter Daten und puffert sie intern. Öffnet man die Schnittstelle wieder 
kommen die Daten auch noch in der Software an.

Sascha

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Sascha W. schrieb:
> Also der FTDI empfängt, nachdem die Schnittstelle einmal geöffnet war,
> auch bei geschlossener Schnittstelle mit den eingestellten Parametern
> weiter Daten und puffert sie intern. Öffnet man die Schnittstelle wieder
> kommen die Daten auch noch in der Software an.

Dies mag im konkreten Fall vielleicht ein bei den meisten Kernel- und 
Treiberversionen zu beobachtendes Implementierungsmerkmal handeln, aber 
man sollte sich nicht darauf verlassen, dass dieses Verhalten auf alle 
Plattformen usw. gleich ist. Wie von anderen schon geschrieben, kann 
beim Öffnen des Geräts auch eine Neuinitialisierung mit Löschen der 
Puffer erfolgen. Und insbesondere beim Setzen der Baudratenregister ist 
nicht sichergestellt, dass Zeichen, die währrenddessen empfangen werden, 
dabei erhalten bleiben. Ein kleiner Blick in den Quelltext des 
FTDI-Treibers zeigt zwar, dass nach Möglichkeit nur bei tatsächlichen 
Konfigurationsänderungen auf den Baustein zugegriffen werden soll, aber 
welche Ausführungspfade insgesamt existieren, ist auf die Schnelle nicht 
zu erkennen.

Wahrscheinlich ist das Problem aber schon bekannt, dass manche Leute 
bzw. deren Programme Gerätedateien immer wieder öffnen, kurz 
reinschreiben, wieder schließen, wieder öffnen, usw. und sich dann 
wundern, warum so etwas manchmal in die Hose geht.

[Noch einer (Gast)]

Die Linux Puffer sind riesig.

Habe das umgekehrte Problem. Nach einem Programmabsturz bekommt das neu 
gestartete Programm noch Megabyte an Daten, mit denen es nichts anfangen 
kann.

Du hast 3 Probleme. Du bekommt alten Schrott. Du weisst nicht, ob Daten 
verloren gegangen sind. Und du weisst nicht, ob einige Bytes einer 
Nachricht verloren gegangen sind. Dein Device sendet "12345\n" zwei Byte 
Pufferüberlauf und dein Programm bekommt "345\n".

[Georg A. (georga)]

Noch einer schrieb:
> Habe das umgekehrte Problem. Nach einem Programmabsturz bekommt das neu
> gestartete Programm noch Megabyte an Daten, mit denen es nichts anfangen
> kann.

Dagegen gibts tcflush. Wenn man das Programm nicht ändern kann, kann man 
ja ein Tool zwischen den Restart schieben, das das macht.