Eingangspuffer bei seriellen Ports

Hallo,

ich habe hier ein merkwürdiges Problem beim Lesen von Daten an seriellen Ports. Mit SetupComm() habe ich die Input-Queue auf 4096 Bytes eingestellt und trotzdem gehen schon beim Lesen von weniger als 1000 Bytes (die in mehreren kleineren Blöcken gesendet werden) einige Daten verloren, wenn ich die Daten nicht alle umgehend lese. Ich musste dazu "ReadTotalTimeoutConstant" beim Aufruf von SetCommTimeouts sehr hoch setzten (250) und in einer Schleife so lange lesen, bis ReadFile mit 0 gelesenen Bytes zurückkehrte, damit das in meinem Testfall funktionierte. Dieses Verhalten ist sowohl an COM1 als auch an COM2 absolut reproduzierbar. ReadIntervalTimeout und ReadTotalTimeoutMultiplier habe ich auf MAXDWORD gesetzt. Baudrate ist 9600 baud.

Laut Dokumentation von SetupComm() kann der Treiber diese Angabe ignorieren, sollte dann aber sicherstellen, dass ein Datenverlust durch Pufferüberlauf höchstens unter extremen Umständen auftritt, die hier aber wirklich nicht vorlagen (etwa 600 Bytes und ein Zeitraum von etwa 700 ms). Wie puffert der Treiber für die serielle Schnittstelle die Daten? Muss ich da auf irgend etwas aufpassen?

Quote

Sie sollten auch den aktuellsten Kernel verwenden.

Wir verwenden einen eigenen Kernel. Ist das BSP vom 12.3.2007 auf der Downloadseite aktuell genug?

Quote

Der Puffer kann maximal 2k groß sein.

SetupComm() hat aber einen Wert ungleich 0 zurück gegeben. Wie groß ist der Puffer denn dann nach dem Aufruf?

Ich kann mir immer noch kein Bild von dem machen, was da bei den seriellen Ports abläuft. Irgendwie verhalten sich die seriellen Schnittstellen auf dem PicoMOD anders als ich es von anderen Systemen gewohnt bin.

Die Dokumentation von SetupComm() habe ich so verstanden, dass diese Funktion nur dann einen Wert ungleich 0 zurück gibt, wenn der Treiber entweder den entsprechenden Puffer auf diese Größe einstellt oder gewährleisten kann, dass durch andere Vorgehensweisen ein Datenverlust ausgeschlossen werden kann. Wenn ich also eine bestimmte Puffergröße einstelle, dann tue ich das, weil ich sichergehen will, dass ankommende Daten gepuffert werden, so lange mein Programm mit etwas anderem beschäftigt ist.

Die Einstellungen für Priority256 und WaterMark habe ich für COM2 ausprobiert und es scheint tatsächlich stabiler zu laufen. Allerings hören sich diese beiden Einstellungen für mich so an, als ob Sie vermuten, dass die Daten nicht rechtzeitig aus dem Hardware FIFO gelesen wurden. Stimmt das? Und warum sind hier die Default-Werte so wie sie sind und nicht so wie es besser läuft?

Probleme habe ich trotz dieser Einstellungen noch immer, wenn ich zwischendurch mit einem Breakpoint den Ablauf anhalte. Da gehen dann auch regelmässig Daten verloren, was das debuggen ziemlich erschwert.

Also: Ich möchte (und muss!) meine Software hier so auf dem PicoMOD zum laufen bringen, dass möglichst keine Daten die an den seriellen Schnittstellen ankommen, verloren gehen. Was muss ich dazu beachten?

Ich wäre Ihnen daher sehr dankbar, wenn Sie mir diese Fragen und die aus meinem vorhergehenden Posting noch beantworten könnten. Danke.

Quote

Die Standard-Implementierung in Windows CE für den entsprechenden ARM-Prozessor ist relativ ineffizient programmiert. Wir haben den Treiber darum vor ein paar Monaten komplett überarbeitet, ja mehr oder weniger neu geschrieben. Seitdem ist das ganze Verhalten deutlich besser. Ich habe es seitdem noch nicht "geschafft", bei 115kbit/s auch nur ein Byte zu verlieren. Arbeitet man auf einem Port sogar bidirektional, dann kriege ich mit der PicoMOD sogar meinen PC, immerhin ein recht flotter Pentium D, in die Knie.

Für diesen Treiber wenden Sie sich bitte an unsere Verkaufsabteilung.

Mit freundlichen Grüßen,

H. Keller

Display More

Sorry, habe mein Posting gerade gemacht als sie geantwortet haben. Könnten Sie mir den anderen Treiber per E-Mail senden?