Direkt auf RS232 Buffer zugreifen

Mach den Puffer sehr gross (z.b ein paar kb) und lese immer nur 3 Byte
auf einmal aus. Diese werden durchs lesen ja automatisch aus dem Puffer
gelöscht. So geht ganz sicher nichts mehr verloren. Und setz den Timeout
tiefer.

Das kommt mir oberfaul vor.
Ein GHz getakteter PC soll nicht in der Lage sein, alle 20 ms ein paar
bytes zu verarbeiten? 20 ms sind eine halbe Ewigkeit.

Frage: Hast Du Handshaking aktiviert? Welches, XON/XOFF oder
Hardware-handshaking? Handhaking soll genau das verhindern, dass der
Sender sendet, waehrend der Empfaenger noch nicht zur Datenaufnahme
bereit ist.

> Nein ein Handshaking hab ich leider noch nicht implementiert.

Dann hast Du genau hier Dein Problem, warum Dir zwischendurch
immer wieder mal Daten verloren gehen.

> Mein problem ist, dass mein Rechner mit anderen Sachen zwischendurch
> beschäftigt ist.

Deckt sich genau mit der Fehlerbeschreibung

> Wie funktioniert das mit dem Handshaking? Ich vermute,
> dass ich eine zusätzliche Leitung habe, die z.B. auf High ist,
> wenn der PC für einen Datenempfang bereit ist.

Das ist dann Harware-Handshaking.
Beide Teilnehmer an der Kommunikation haben eine eigene Leitung
zum jeweils anderen, mit der sie mitteilen, dass sie jetzt
bereit sind Daten anzunehmen oder auch nicht. Ist die Gegenstelle
nicht bereit, dann sendet der Sender auch nicht.

Die andere Moeglichkeit ist Soft-Handshaking. Dazu sind im
ASCII Code eigene Zeichen definiert: XON und XOFF

Dein PC empfaengt Daten. Nachdem du weisst, das er jetzt eine
Zeitlang beschaeftigt sein wird, sendest Du sofort ein XOFF
and den Sender. Dieser sendet darauf hin nichts mehr. Erst
dann wenn der PC wieder bereit zum Empfang ist, schickt er
erstmal ein XON los und wartet auf Daten. Die Gegenstelle empfaengt
das XON und hat damit die Freigabe zum senden. usw.

Das ganze ist so, wie wenn Deine Freundin Dir einen Roman erzaehlt,
du aber momentan nicht aufnahmefaehig bist. Dann sagst Du:
"Einen Moment bitte", machst das was Du grade tust fertig, und
forderst sie mit "So, jetzt" zum 'senden' auf.

Ist doch immer wieder erstaunlich wie sich kompliziert klingende
Computer-Konzepte im realen Leben wiederfinden :-)

Interrupts werden aber eigentlich recht flott ausgeführt und für einen
aktuellen PC sind 1-2ms eine Ewigkeit. Vondaher sollte dadurch
eigentlich nichts verloren gehen

Der Treiber für die serielle Schnittstelle hat wiederum einen Puffer,
der beim Auftreten eines Interrupts mit Daten gefüllt wird. Da das auf
Devicetreiberebene geschieht, treffen hier die diversen verzögernden
Aspekte des Windows-Schedulers nicht zu. Selbst ein sehr altes System
(486er) unter einem ernstgemeinten* Windows ist in der Lage, serielle
Schnittstellen mit einer Datenrate von 57600 oder 115200 Baud zu
bedienen, ohne daß Daten verlorengingen. Natürlich muss sichergestellt
werden, daß der Puffer des Devicetreibers auch zeitig geleert wird; die
Usermode-Applikation sollte sich dabei also nicht zu "dumm" anstellen,
beispielsweise in ein und demselben Thread  GUI-Ausgaben und die
Kommunikation mit der seriellen Schnittstelle abwickeln.

Das alles ist unter den Hobby-Frickel-Windows-Versionen** sicherlich
anders, da hat MS (noch) weniger Wert auf vernünftige Funktion gelegt
als bei NT.

Natürlich sieht das ganze auch anders aus, wenn man unter den
ernstgemeinten Windows-Versionen noch mit DOS-Programmen hantiert; es
gibt wohl immer noch Exoten, die sowas machen. Die Performance der
simulierten seriellen Schnittstelle der VDM ist zwar von NT-Version zu
NT-Version immer besser geworden, aber praktisch immer noch oft
unbrauchbar.

*) NT ab Version 3.1; das schließt Windows 2000 und XP (NT 5.0 und 5.1)
mit ein
**) 16-Bit-Varianten sowie alle Aufgüsse von Windows 95