GPS-Treiber die Daten von einem virtuellen seriellen Port-Treiber Verlangsamen

Question

folgen auf - GPS Intermediate Driver Issues

Die oben wurde nicht erfolgreich beantwortet und ich fühle mich neue Informationen über das Thema haben für eine neue Frage zu gehen.

Das Problem, mit dem ich konfrontiert bin, ist die Geschwindigkeit, mit der Daten vom GPS Intermediate Driver geliefert werden.

Ich habe Pocket Putty erfolgreich verwendet, um die seriellen Schnittstellen zu lesen und die genauen Informationen zu sehen.

COM 1 - GPS-Treiber

COM 6 - Serielle Schnittstelle zum PC (Eingangsdaten manuell)

COM 8 - virtuelle serielle Schnittstelle für die GPS-Hardware.

Beim Lesen von COM 8 sehe ich ungefähr 18 NMEA-Zeichenfolgen alle ~ 3 Sekunden, das ist so schnell wie wir es über die begrenzte USB-Verbindung schieben können. Und es erscheint schnell auf dem Display. Beim Lesen von COM 6 (Daten vom PC manuell senden) wird es genauso schnell angezeigt. Es gibt also kein Problem mit den verfügbaren Daten.

Geben Sie den GPS-Intermediate-Treiber ein. Wenn der GPS-Intermediate-Treiber auf COM1 (Software) und COM6 (Hardware) eingestellt ist. Die an COM6 eingegebenen Daten werden auf COM1 genauso schnell angezeigt wie ohne den GPS Intermediate Driver. Die Daten sind unverändert, wenn ich also "JON" an COM6 sende, wird es auf COM1 erscheinen, obwohl es nicht gültige NMEA-Daten sind, was in Ordnung ist.

Das Problem ist mit COM8. Wenn der GPS-Intermediate-Treiber auf COM1 (Software) und COM8 (Hardware) eingestellt ist. Die Daten, die in PocketPutty auf COM1 angezeigt werden, sind wirklich langsam. Die Ausgabe auf dem Bildschirm ist etwa 5 Zeichen pro Sekunde, die Daten sind gültig, aber es wurde nur sehr langsam geliefert. Dies weist auf ein Problem bei der Implementierung des virtuellen seriellen Ports hin, als ob der GPS Intermediate Driver nicht alle Daten nur ein Zeichen gleichzeitig lesen würde, vorausgesetzt, ich habe das Problem an meinem virtuellen seriellen Port isoliert.

Kann jemand ein klares Beispiel für eine virtuelle serielle Schnittstelle bereitstellen, da ich nicht sicher bin, was ich ändern könnte, um dies zu verbessern, vorausgesetzt, COM8 arbeitet direkt mit GPS-Software und die PocketPutty-Anwendung, die anzeigt, dass die Daten verfügbar sind, wird gelesen und ist richtig.

Answer 1

Nachdem die Unterstützung des Geräteherstellers, der einen Debugbuild ausgeführt hat, unterstützt wurde, war die Ursache des Problems, dass Clientanwendungen viele Leseaufrufe machten. Die serielle Schnittstelle könnte sie alleine bewältigen, aber über den GPS Intermediate-Treiber war die Anzahl der Anrufe zu hoch und der Overhead lähmte die Kommunikation, dies war auf Mutex-Sperren und allgemeine Threading-Probleme zurückzuführen.

Client-Anwendungen müssen 960 Datenbytes pro gelesenem GPS-Intermediate-Treiber lesen, damit sie ordnungsgemäß funktionieren. Dies ist keine ideale Lösung, daher wurde eine andere Lösung gefunden.

Die Lösung bestand darin, ein WaitForSingleObject (IsThereEnoughGPSDATAEvent, COMTotalTimeout) in die read-Methode einzufügen, so dass alle Lesevorgänge nur Daten erhalten würden, wenn genügend Daten verfügbar wären. Ursprünglich habe ich 960 angefordert, um im Puffer verfügbar zu sein, aber ich habe es auf nur 10 Bytes heruntergesetzt, und es funktioniert immer noch.

Beispielcode

DWORD COM_Read(DWORD hOpenContext, LPVOID pBuffer, DWORD Count) 
{ 
    if(gpsThreadEvents[GPS_THREAD_EVENT_DATA_AVAILABLE] != NULL) 
    { 
     if(WaitForSingleObject(gpsThreadEvents[GPS_THREAD_EVENT_DATA_AVAILABLE], GPSTimeouts.ReadTotalTimeoutConstant) != WAIT_OBJECT_0) 
     { 
      return 0; 
     } 
    } 

    //read code goes in here 

    return dataOut; 
}