4. [VS6.0] 2 virtuelle COM-Ports: 'ReadFile" schlägt fehl

[VS6.0] 2 virtuelle COM-Ports: 'ReadFile" schlägt fehl

  • M

    Hallo zusammen!

    Habe da ein 'kleines' Problem mit virtuellen COM-Ports.

    Es handelt sich um 2 Geräte (1 GPS Empfänger, 1 RF-Modul) welche per USB an den Rechner angeschlossen werden, sich aber der 'guten, alten' seriellen Kommunikation bedienen. Daher bringen beide einen jeweiligen Treiber zur Umsetzung mit. Die Kommunikation per Hyperterminal klappt bei beiden Geräten ohne Probleme, in einem kleinen Testprogramm kann ich einfach und ohne Probleme Daten lesen und schreiben. Untenstehender Fetzen stellt das übliche lesen von COM-Pots kurz dar (nicht 100% vollständig).

    //...
std::string io ( "\\\\.\\COM16" );
// rs232
DCB dcb; 
memset ( &dcb, 0, sizeof ( dcb ) );
HANDLE hCom;
hCom = CreateFile( io.c_str (),
		   GENERIC_READ,
		   0,
	           NULL,
                   OPEN_EXISTING,
		   0,
		   NULL );

if ( hCom == INVALID_HANDLE_VALUE )
{
        // some error; kill thread;
        repeat = false;
	CloseHandle ( hCom );
	break;
}

BOOL ret ( FALSE );
ret = GetCommState ( hCom, &dcb );
dcb.DCBlength	= sizeof ( dcb );
dcb.BaudRate	= CBR_9600;	// set the baud rate
dcb.ByteSize	= 8;            // data size, xmit, and rcv
dcb.Parity	= NOPARITY;	// no parity bit
dcb.StopBits	= ONESTOPBIT;   // one stop bit
ret = SetCommState ( hCom, &dcb ); 

unsigned len ( 512 );
char* combuffer = new char [len];
DWORD nbrRead ( 0 ) ;
Sleep ( 1000 );

ReadFile ( hCom, 
	   combuffer, 
	   len, 
	   &nbrRead, 
	   NULL );

if ( nbrRead == 0 )
{
	break;
}
// goon...do stuff

    Was allerdings nicht klappt: von beiden Geräten lesen/schreiben gleichzeitig (sind selbstverständlich verschiedene COM-Ports). Hintergrund: GPS-Daten vom COM lesen und in den COM vom RF-Device schreiben.

    Hierbei bleibt der thread welcher vom GPS-Device lesen soll im 'ReadFile' immer stehen und kehrt nicht wieder zurück. (handles für beide COMs sind gültig)

    Meine Vermutung:
    Die beiden unterschiedlichen Treiber für GPS- (LibUSBWin32) und RF-Device (SiLabs) beissen sich irgendwie. Aber, wie gesagt, ist nur eine wage Vermutung.

    Hat vllt jemand einen Tip wie man das umgehen könnte?

    Was leider nicht klappt:
    - beide Geräte mit dem gleichen Treiber betreiben;
    - 2 Applikationen: 1 liest GPS in Datei, 2 öffnet Datei und schreibt in RF-Device;

    In diesem Sinne, einen schönen letzten Wochentag!

    m

    0
  • M

    m.trix schrieb:

    Die Kommunikation per Hyperterminal klappt bei beiden Geräten ohne Probleme, in einem kleinen Testprogramm kann ich einfach und ohne Probleme Daten lesen und schreiben.

    Ich gehe mal davon aus, diese Tests wurden immer nur mit einem der beiden Geräte zur gleichen Zeit durchgeführt, oder?

    Wenn ja: Dann starte mal Hyperterminal zweimal und kommuniziere gleichzeitig mit den beiden Geräten.
    Welches Ergebnis kommt dabei raus?

    Martin

    0
  • M

    Hi, hab erst jetzt Dein Code ein wenig genauer angeguckt...

    m.trix schrieb:

    //...
BOOL ret ( FALSE );
//...

    Was ist denn das für eine Funktion? 😕

    m.trix schrieb:

    //...
ret = GetCommState ( hCom, &dcb );
dcb.DCBlength	= sizeof ( dcb );
dcb.BaudRate	= CBR_9600;	// set the baud rate
dcb.ByteSize	= 8;            // data size, xmit, and rcv
dcb.Parity	= NOPARITY;	// no parity bit
dcb.StopBits	= ONESTOPBIT;   // one stop bit
ret = SetCommState ( hCom, &dcb ); 
//...

    Du definierst hier Deine Schnittstellenparameter nur unvollständig.
    Lasse am besten GetCommState() weg und definiere besser alle Member selbst zu Fuß.
    Du weißt nicht was für Einstellungen Dir GetCommState() beim ersten mal liefert.

    Martin

    0
  • M

    Guter Punkt!

    2 Hyperterminals, 2 mal das Ergebnis wie es sein soll:
    Beim GPS-Device fallen die Daten raus, das RF-Modul kann ich kommandieren.

    Einstellungen Hyperterminal:
    GPS-Device:
    Bits pro Sekunde: 9600
    Datenbits: 8
    Parität: keine
    Stoppbits: 1
    Flusssteuerung: keine

    RF-Device:
    Bits pro Sekunde: 38400
    Datenbits: 8
    Parität: keine
    Stoppbits: 1
    Flusssteuerung: keine

    Also bis auf die Baud-Rate nix unterschiedliches was ich verhauen könnt. Oder? Ehrlich gesagt verwirrt mich das jetzt noch mehr: Starte ich 2 Hyperterminals gleichzeitig klappts. Starte ich 2 'gebastelte' Apps gleichzeitig klappts nicht. Starte ich 1 'gebastelte' App klappts.

    😕

    m

    0
  • M

    Deine beobachteten Symptome untermauern meinen Hinweis, daß Deine Kommunikationsparameter nicht vollständig nach Deinen Vorstellungen definiert waren...

    Martin

    0
  • M

    Die Einstellungen des COM-Port sind und waren korrekt.

    Zwei COM-Ports im selben Code verwenden muss man unter zu Hilfe von OVERLAPPED-Strukturen erledigen. Dies muss bereits beim Aufruf vom CreateFile(...) den 'file attributes' mittgeteilt werden und bei ReadFile (...) die entsprechende Struktur übergeben werden.

    HANDLE CreateFile(
  LPCTSTR lpFileName,          // pointer to name of the file
  DWORD dwDesiredAccess,       // access (read-write) mode
  DWORD dwShareMode,           // share mode
  LPSECURITY_ATTRIBUTES lpSecurityAttributes,
                               // pointer to security attributes
  DWORD dwCreationDisposition,  // how to create
  DWORD dwFlagsAndAttributes,  // file attributes
  HANDLE hTemplateFile         // handle to file with attributes to 
                               // copy
);

BOOL ReadFile(
  HANDLE hFile,                // handle of file to read
  LPVOID lpBuffer,             // pointer to buffer that receives data
  DWORD nNumberOfBytesToRead,  // number of bytes to read
  LPDWORD lpNumberOfBytesRead, // pointer to number of bytes read
  LPOVERLAPPED lpOverlapped    // pointer to structure for data
);

    Da ich schlicht keine Zeit hatte mich damit näher zu beschäftigen, habe ich die Funktionalität aufgeteilt. Ein Programm zum lesen der entsprechenden GPS-Daten und erzeugen einer Datei mit selbigen, und ein zweites welches eben diese Datei lesend öffnet um die aktuellsten Daten auf den COM-Port des RF-Device zu schreiben. Funzt ohne Probleme. ( Zugriffsverletzungen werden einfach ignoriert 🙂 )

    //...
BOOL ret ( FALSE );
//...

    Ist ein expliziter Konstruktor-Aufruf (keine Ahnung ob das die korrekte Bezeichnung ist...). Objekte wie folgt

    class foo
{
private:
foo ( bool a_barg, unsigned a_uarg, long a_larg );
//...
};
class bar
{
private:
bar ( bool a_barg );
//...
};

    würdest du (vermutlich) so erzeugen:

    //...
bar obj01 = true;
bar obj02 ( true );
foo obj03 ( true, 0xdead, 0xbeef );
//...

    Was mit komplexen Typen funktioniert, funktioniert auch mir einfachen Typen. Hab mir das während des Studiums angewohnt und so zieht sich das stetig durch meinen Code. Warum das nochmal war, is mir leider entfallen. Kritik wird gerne entgegengenommen!

    Vielen Dank für die anderen Hinweise!

    m

    m.

    0
Anmelden zum Antworten