Datenverlust bei ReadFile auf virtuellen COM-Port

[hathor]

Schlechte Kabelverbindung ausgeschlossen?
Zu lang, zu alt, "wackelig"...

CBR_256000 ist sehr hoch - geht es auch langsamer?

Ein Computer macht eigentlich nichts zufällig, ausser mit "Random"...
Ist das Device auch als HID vorhanden?

[BlackGuest]

Zitat von hathor:

Schlechte Kabelverbindung ausgeschlossen?
Zu lang, zu alt, "wackelig"...

Ausgeschlossen. Ein Gerät, ein Kabel, zwei Rechner am Ende des Kabels. Ist von daher schon ausgeschlossen, da die Daten über USB schon "gekapselt" übertragen werden. Mit der alten RS232 hat das nichts mehr zu tun. Der Port wird nur fast identisch angesprochen.

Zitat von hathor:

CBR_256000 ist sehr hoch - geht es auch langsamer?

Die Einstellung ist eigentlich egal. Über USB werden die Daten immer mit Full-Speed (12MBit/s) übertragen.
Evtl. könnte der Wert intern noch für irgendwelche Timings verwendet werde. Mit 9600 ist das Ergebnis aber das Gleiche.

Zitat von hathor:

Ist das Device auch als HID vorhanden?

Nein, nur als CDC.

Zitat:

Ist auch klar, denn du liest nur das aus, was "aktuell" im Puffer ist, das können mehr oder wender sein, als das, was du jetzt auslesen willst.
Bei weniger mußt du entweder auf die fehlenden Daten warten oder die Daten sammeln und zusammensetzen, bis die Anzahl ausreicht.

Ich arbeite syncron. ReadFile liefert mir erst ein Ergebnis zurück, wenn entweder die Anzahl Datenbyte gelesen werden konnte oder ein Timeout eintritt.
Ein Timeout tritt noch obigem Code nach 50ms ein. Selbst mit 1000ms habe ich das gleiche Problem.
Beim Senden treten keine Fehler auf. Wenn, dann würde mein Device auch nicht antworten bzw. mit einer Fehlermeldung.
Der Port wird beim Programmstart geöffnet und beim Beenden geschlossen. Ist also die ganze Zeit offen.

Mein Device sendet nur Daten, wenn es vorher eine gültige Befehlssequenz empfangen hat.

Ich hoffe ich konnte einige Unklarheiten ausräumen.

Mein Programm läuft auf einigen Windows 7 PCs problemlos, unter Windows 8 kommt es zu dem Datenverlust, wobei ich da zu wenig Hardware hier habe um 100%-ig sagen zu können, dass es am Windows 8 liegt. Kann auch an der "PC"-Geschwindigkeit liegen. Mein Windows 8 Rechner ist ein Tablet.

Gruß und danke für die bisherigen Hinweise.
BlackGuest

[hathor]

Zitat von BlackGuest:

Die Einstellung ist eigentlich egal.
BlackGuest

Das bezweifle ich.
Was empfiehlt der Hersteller des Gerätes oder des USB-COM-Wandlers?

Da Deine "Selbstbau"-Software NICHT Event-gesteuert ist, hängt es vom Zufall ab, wann WINDOWS die Daten aus dem Buffer holt.

Ich habe hier die Beschreibung eines CDC-Chips:
256 kommt da NICHT vor:
The following baud rates are supported: 1200, 2400,4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, and 921600 bps.

[BlackGuest]

Zitat von hathor:

Zitat von BlackGuest:

Die Einstellung ist eigentlich egal.
BlackGuest

Das bezweifle ich.
Was empfiehlt der Hersteller des Gerätes oder des USB-COM-Wandlers?

Die CDC ist ja eigentlich für USB-Serial Wandler gedacht. Dort spielt der Wert eine Rolle. Bei der reinen Übertragung über USB nicht. Der CDC Treiber läuft direkt auf einem Microcontroller, also nicht USB-Serial Wandler <--> Microcontroller. Wie schon geschrieben, könnte es sein, das der PC-seitige Treiber den Wert für irgend welche Timings verwendet. Nur mit 9600 Baud (Einstellung im MC) kommt es auf das Gleiche raus.

Zitat von hathor:

Da Deine "Selbstbau"-Software NICHT Event-gesteuert ist, hängt es vom Zufall ab, wann WINDOWS die Daten aus dem Buffer holt.

ReadFile sollte schon den Buffer auslesen. Auch ohne Event.
Sollte, schon möglich das da das Problem liegt. Nur warum sollte ich auf jedes einzelnen Zeichen reagieren, wenn mich nur die Komplette Antwortsequenz interessiert, die nun mal x-Datenbyte lang ist? Wieso funktioniert das Ganze unter Windows 7 anscheinend völlig ohne Probleme?

Gruß
BlackGuest

[hathor]

Testprogramm:
http://www.rosseeld.be/DRO/PIC/TestCDC.zip

[BlackGuest]

Danke für den Link.
Werde ich dann gleich mal anschauen.

Habe inzwischen noch was rausgefunden. ReadFile liest schon alle Daten die ankommen bzw. die im Puffer sind, bevor die Funktion ein Timout auftritt.
Ich habe jetzt einen festen Testdatensatz verwendet. Es fehlen nicht Bytes am Anfang oder am Ende, sondern irgenwo mitten in der Antwortsequenz. Ich vermute fast, dass die CDC Implementation in meinem MC nicht mit der Windows 8 Implementation zusammenpasst und da irgendwo dieses Problem begründet ist.

Gruß
BlackGuest

[BlackGuest]

Danke noch mal für das Beispiel.
Der Code dort entspricht im Prinzip dem aus meinem Startthread.

Ich habe das Ganze ein wenig umgeschrieben, so dass ich in einer Endlosschleife immer die gleiche Sequenz zum MC sende und auch immer den gleichen Datensatz zurück bekommen sollte. Das Problem ist auch hier das Gleiche. Es gehen hin und wieder Datenbyte verloren. Auch unter Windows 7. Das ist nur nicht aufgefallen, da das Problem wesentlich seltener auftritt und ich im Fehlerfall das Kommando ein mal wiederhole. Liegt wohl eher doch an der Rechnergeschwindigkeit.

Gesendet werden 6 Byte und die Antwort sollte 35 Byte lang sein. Auf meinem Windows 7 Rechner fehlt auch ca. alle 2000 Abfragen irgend ein Byte.

Die Fehlerhäufigkeit kann ich dadurch minimieren, in dem ich mit ReadFile nicht den ganzen Block lese, sondern immer nur ein Byte.

Keine Ahnung, was da schief läuft. Ich werde es mal auf Ereignissteuerung umbauen.
So sollte es aber eigentlich auch problemlos funktionieren.??

Wenn jemand noch einen Einfall hat, immer her damit.

Gruß
BlackGuest