COM-Port Daten auslesen

Hallo,

habe hier folgendes Problem: ich bekomme Daten über den COM-Port gesendet (bzw
eigentlich über USB, mit dem TTDI-Chip FT245, aber der Treiber simuliert einen
COM-Port sehr hoher Geschwindigkeit). Das Ganze klappt unter DOS prima mit
dem Programm "serialterm". Es kommen alle Zeichen vor, also alles von 0x00 bis 0xff.

Im Init:

// COM Port Initialization
	m_COMControl.SetCommPort(3);	// com3
	m_COMControl.SetSettings("115200,N,8,1");											// 19200 bits/s, no parity, 8 data bits, 1 stop bit
	m_COMControl.SetInputLen(100);
	m_COMControl.SetInputMode(0);
	m_COMControl.SetDTREnable(FALSE);
	m_COMControl.SetRTSEnable(FALSE);
	m_COMControl.SetEOFEnable(FALSE);
	m_COMControl.SetRThreshold(20);		// only wake me when > 20 chars have arrived
	m_COMControl.SetSThreshold(0);
	m_COMControl.SetPortOpen(TRUE);

Im Messahe handler mache ich folgendes:

VARIANT in_dat;
char cBuf[1024];
unsigned int len;

switch(m_COMControl.GetCommEvent()) {
case 2: /*
	 * comEvReceive Event... this means we received a number of Rthreshold
	 * characters. Event is generated continuously until data is fetched via
	 * GetInput()
	 */
	in_dat = m_COMControl.GetInput();
	// convert from Variant to String
	m_COMPortString = in_dat.bstrVal;
	len = m_COMPortString.GetLength();
	memcpy(cBuf, m_COMPortString, len);
	analyzeData(cBuf, len);
	break;
.....
}

Das Problem:
- ich werde teils auch wegen "0 neuen characters" geweckt... oder wegen 1.. oder 2... oder 7... allerdings wollte ich ja erst ab 20 chars geweckt werden?
- offenbar fehlen einzelne characters (oder mehrere?) im Datenstrom. Jedenfalls ergeben die Daten, so wie sie in analyzeData ankommen, sequentiell betrachtet keinen Sinn.

Woran kanns liegen?

Grüße,
Marc

P.S.: Doppelposting... hab das erste yu früh abgeschickt... bitte anderes Posting löschen.

uah weiss das echt keiner

je nachdem wie gross ich die Parameter waehle werden die Daten entweder
zu langsam abgerufen, oder das Programm crasht. Habe mitterweile noch
folgendes eingebaut:

Im Init:

m_COMControl.SetInBufferSize(300);

Und im Handler statt des alten Codes:

inputlen = m_COMControl.GetInBufferCount();
m_COMControl.SetInputLen(inputlen);
pvar = &m_COMControl.GetInput();
HRESULT hr(SafeArrayAccessData(pvar->parray,(void HUGEP**)&phgbuffer));
memcpy(cBuf,phgbuffer,inputlen);
hr = SafeArrayUnaccessData(pvar->parray);
hr = SafeArrayDestroyData(pvar->parray);
hr = SafeArrayDestroyDescriptor(pvar->parray);
UpdateData(false);	// XXX tut was?
analyzeData(cBuf, inputlen);

Interessanterweise liefert GetInBufferCount() konstant einen wert im Bereich
um 3800 zurück, was ja nun nicht ganz sein kann...

ich habe zu SetInputLen() keine Doku gefunden - was macht das eigentlich?
Ich nehme an es teilt Windows mit in welchen "Blockgrößen" ich die Daten
aus dem Puffer lesen will (d.h. abgeholte Bytes pro GetInput() ?).

Grüße,
Marc

ach ja die Sache mit HRedsult dient angeblich um um eine Speicherlücke in der
C++ api herumzupatchen, laut einem Codefragment das ich im Internet gefunden habe.

grrr eins noch vergessen: im Init habe ich noch SetInputMode(1) gemacht,
d.h. Binaerdaten (vs. "0" für Stringdaten).