Hi,
I recently developped a program that retrives data over a RS-232 connection. The issue is that the frames are 20 bytes long and sometimes the last four ones are missing : the bytes are not in the buffer.
20 frame bytes - 4 missing bytes = 16 = UART internal buffer size.
Which means (I think) that sometimes the data are not transferd from the hardware buffer to the software buffer, or not fast enough.
The speed is important beacause com port is handled as a callback so it is in the event queue, and has to wait for all interface related pending events (graphs, file storing), before being processed.
The port readings are made using installcomcallback, using the LWRS_RXFLAG event detecting the first byte of the frame.
Moreover there is another issue : sometimes the event is beeing triggered, and the event character is not in the buffer. This is the situation that is descibed in the installcomcallback function panel help.
But since things were still going wrong we checked the input buffer size after a delay and the buffer now containes the character :
if (GetInQLen(Comport) == 0)
{
Delay(0.1);
if (GetInQLen(Comport) == 0) return 0; // Fake interrupt
// REAL interrupt (!)
}
Sometimes, interrupt with empty buffer are triggered, but if we wait a little and check again the buffer, it isn't empty anymore (!)
Here are the questions :
why the buffer is empty while a real interrupt is triggered ?
Is it possible to handle com port interrupts in an own thread (like ibnotify for GPIB), for faster response to byte arrival event, and interface independant processing speed ?
Is it possible to use functions that will not miss events or send two interrupts for the same event (ie : to overcome windows com port managment), or require a 100 ms delay for transferring a byte from a buffer to another place that is not so far away ?
The computer is a celeron 500 with 128 Mb ram, configuration : win 98, CVI 7.0. running after a fresh reboot with no other lauchned applications.
Pierre
