✔ COM-Port will nicht

[CodeFatal]

Hallo liebe Gemeinde,

ich hab da ein kleines Problem mit einem COM-Port.
In meiner Software, die Zugriff auf selbst gebaute Hardware nimmt, habe ich eine Routine eingebaut, die alle Ports durchläuft bis diese bestimmte Hardware gefunden wird. Innerhalb dieser Initialisierung versuche ich von geöffneten Ports zu lesen um sicher zu stellen, das keine alten Daten in der Pipline sind. Das hat auch alles soweit ganz gut funktioniert bis ich das System auf einem Rechner mit Bluetooth Treibern installiert habe.
Soweit ich innerhalb des Debug-Modus sehen konnte wird der Port zwar geöffnet aber kann nicht gelesen werden.
Mich wundert eigentlich auch mehr das dieser Port überhaupt geöffnet wird, da ich den entsprechenden Stick nicht eingesteckt hatte.

Hat jemand von euch evt. schon mal ein ähnliches Problem?
Gibt es vielleicht auch eine elegantere Lösung sicher zu stellen, das keine alten Daten in der Pipline sind?

Hier meine Init Funktionen:

	HRESULT CVirtCom::Init(CDialog *ParentDlg,CString Com,DWORD Baud,BYTE ByteSize, BYTE Parity, BYTE StopBits)
            DCB dcb;
	BOOL bResult= FALSE;
	unsigned long  nwrite=0;
	unsigned long  nread=0;
	char buf[MSG_LENGTH];
	HANDLE hComPort;//handel auf den ComPort
	CString log;

	if(WriteReadTd.hCom)//Ist bereits ein Port geöffnet
		CloseHandle(WriteReadTd.hCom);//Port schließen
	WriteReadTd.hCom = NULL;
	if(Com.IsEmpty())return E_FAIL;
	//ComPort öffnen
	hComPort = CreateFile ( Com,
		GENERIC_WRITE | GENERIC_READ,
		0,
		NULL,
		OPEN_EXISTING,
		0,
		NULL);

	if(!hComPort)return E_FAIL;
	if(hComPort == INVALID_HANDLE_VALUE)return E_FAIL;

	DWORD err = 0;
	COMMTIMEOUTS  ctmoOld;
	//Timeouts werden so gesetzt, das nur das zurück gegeben wird, was auch wirklich benötigt wird
	GetCommTimeouts(hComPort,&ctmoOld);
	ctmoOld.ReadIntervalTimeout = MAXDWORD;
	ctmoOld.ReadTotalTimeoutConstant = 0;
	ctmoOld.ReadTotalTimeoutMultiplier = 0;
	ctmoOld.WriteTotalTimeoutMultiplier = 0;
	ctmoOld.WriteTotalTimeoutConstant = 500;
	if(!SetCommTimeouts(hComPort, &ctmoOld)) // COM-Einstellungen speichern
		err = GetLastError();

	ZeroMemory(&dcb,sizeof(DCB));
	dcb.DCBlength = sizeof(DCB);// setzen der Blocklaenge, muss erfolgen
	GetCommState (hComPort, &dcb); // COM-Einstellungen laden
	dcb.BaudRate = Baud; // Baudrate einstellen
	dcb.ByteSize = ByteSize; // Datenbits einstellen
	dcb.Parity = Parity; // Parität einstellen
	dcb.StopBits = StopBits; // Stopbits einstellen
	if(!SetCommState (hComPort, &dcb)) // COM-Einstellungen speichern
		err = GetLastError();

	if(!hComPort)return E_FAIL;
	if(hComPort == INVALID_HANDLE_VALUE)return E_FAIL;

	//Interface finden
	SMsg msg;

	WriteReadTd.hCom = hComPort;//Handle hier speichern, da folgende Funktionen diese erwarten

	//Buffer leeren
	if(FAILED(RX_BufferEmpty()))
	{
		CloseHandle(hComPort);//Port schließen
		WriteReadTd.hCom = NULL;
		return E_FAIL;
	}
/*
Hier noch spezielle Routinen fals die richtige Hardware gefunden wurde werden im Fehlerfall aber nicht erreicht.
*/

und die zum Pipline leeren:

HRESULT CVirtCom::RX_BufferEmpty()//Leert den angelaufenen Buffer
{
	if(!WriteReadTd.hCom)return E_FAIL;
	if(WriteReadTd.hCom == INVALID_HANDLE_VALUE)return E_FAIL;

	BOOL bResult;
	unsigned long nread;
	char buf[MSG_LENGTH];
	//Buffer leeren
	do 
	{
		ZeroMemory(buf,sizeof(char)*MSG_LENGTH);
		nread = 0;
		bResult = ReadFile(WriteReadTd.hCom, &buf, MSG_LENGTH, &nread, NULL) ;
	}while(nread>0);
	return S_OK;
}

Danke für eure Hilfe.

Gruß Michael

 

[MCoder]

Das Problem mit Bluetooth kenne ich auch: Wenn die entsprechende Hardware fehlt, rödelt der Treiber zyklisch über alle Ports und stört damit die Kommunikation mit an den COM-Ports angeschlossenen Geräten. Da hilft nur Hardware einstecken oder den Treiber deaktivieren.

Gibt es vielleicht auch eine elegantere Lösung sicher zu stellen, das keine alten Daten in der Pipline sind?

Verstehe ich nicht ganz, wenn ein COM-Port neu geöffnet wird, sollten eigentlich keine Daten in irgendeiner Pipeline sein?

Gruß
MCoder

 

[CodeFatal]

Danke für die schnelle Antwort,

dann wird eben der Treiber deaktiviert.

Verstehe ich nicht ganz, wenn ein COM-Port neu geöffnet wird, sollten eigentlich keine Daten in irgendeiner Pipeline sein?

Das hab ich auch gedacht nur leider beim Testen eines Besseren belehrt.
Es handelt sich dabei um irgendwelche Zeichen (5-15). In der Software des USB-Interface werden die zumindest nicht bewusst gesendet. Da aber beim anschließen des Gerätes bereits ein Datenverkehr stattfindet, können die Daten eigentlich nur zwischen Chip und Windows übrigbleiben. Aufgefallen sind diese übrigens bei WinCE 5.0 nicht bei XP.

Gruß Michael