serial device ignores EscapeCommFunction with C

I am migrating (finally) from MSDOS to Windows XP for controlling a meter via the serial port. My old C DOS code works fine.

I want to do as follows:

• meter is continuously taking readings every few sec, but does not send any info until it is requested by the computer
• when computer is ready to receive info from meter, it requests it. It does not accept info otherwise.

My problem is that the readings are just coming into the computer as they are generated by the meter.

I have set the DCB serail params as follows, intending to control communication using RTS and DTR:

dcbSerialParams.BaudRate=CBR_4800;
dcbSerialParams.ByteSize=7;
dcbSerialParams.StopBits=TWOSTOPBITS;
dcbSerialParams.Parity=EVENPARITY;
dcbSerialParams.fDtrControl=DTR_CONTROL_ENABLE;
dcbSerialParams.fRtsControl=RTS_CONTROL_ENABLE;

My old code under DOS was like this:

 outportb(COM1+4,0x03);  /* start Minolta reading */   

 for(j=0;j<=10;j++) /*each reading consists of 11 ascii characters*/
  {
  while(!((inportb(COM1+5)) & 1)); /*wait until char received*/
  reading[j]=inportb(COM1);
  }
 sscanf ( &reading[4], "%f", &lum[k] );
 
 outportb(COM1+4,0x00);  /* stop Minolta reading */

It seems to me that this should work:

void serial_notready(void)
{
EscapeCommFunction(hSerial,CLRDTR);
EscapeCommFunction(hSerial,CLRRTS);
}

void serial_ready(void)
{
EscapeCommFunction(hSerial,SETDTR);
EscapeCommFunction(hSerial,SETRTS);
}

int serial_read(char reading[])
{
DWORD dwBytesRead = 0;
int nbytes=11;
ReadFile(hSerial, reading, nbytes, &dwBytesRead, NULL);
return(dwBytesRead);
}

serial_ready(void);
x = 0; while(x == 0){x=serial_read(reading);}
serial_notready(void);

HOWEVER, the Minolta does not wait to receive the RTS from the computer. It just goes ahead and sends readings as each becomes available. At the same time, the computer does not reject any unwanted reading, but accepts it.

I have been bashing my head against the wall trying to figure this out, trying all kinds of permutations to no avail. Any help greatly appreciated!

Update:

The underlying story is that I present a given luminance (brightness) on a display and then need the corresponding luminance reading. This is done for a whole set of luminances.

L   ---
U      ---
M         ---
     TIME

I present lum1, lum2, lum3, lum4,.... If the measurements are not synchronised to the display, then I may get a supposed reading3 that is actually lum2, or some sort of average because the reading crossed the border between the lum2 and lum3 displays. And, as you said, Hans,the readings will always lag behind the d开发者_如何学Cisplay luminances. Even if I were always systematically one reading behind it would be bad (my situation is worse-- it is a a random relation between the reading and the luminance).

So the behaviour of the windows serial routines is a nightmare for me. Thanks again for the help!

---

dcbSerialParams.fDtrControl=DTR_CONTROL_ENABLE; 
dcbSerialParams.fRtsControl=RTS_CONTROL_ENABLE;

You enable the DTR and RTS signals right away. The meter will immediately start sending data when you open the port. That data gets buffered in the driver's receive buffer. You didn't have a buffer before in the DOS code. It depends how long it takes for you to call serial_notready(). You'll have a pretty full buffer if that takes a second or so. Yes, that makes it look like the meter is just sending data. And you are always reading an old sample.

Start with the DCB values set to DISABLE. Beware that the scheme is brittle, you could turn the signal off pretty reliably back in the DOS. Now you've got a driver in between. You may well end up turning RTS off too late. Which risks getting a stale reading. An alternative is to startup a thread that just reads continuously. And have your main code just use the last value that it read. The overhead is quite low, serial ports are slow.

---

The first thing to do would be to check the return values of the calls to EscapeCommFunction(). If the return value is zero, the call failed and you should use GetLastError() to receive more error information.

---

I use a free third party serial port emulator VPS. its got a interval request timer that dectate when excatly the data need to be updated/grapped. also allow me to log the bus packets into an excel file.