I'm using rs232 library callbacks to read incoming streaming messages
of various types on a serial port.
Messages look like
this: <Command> <Message Body> <CRG RTN>
I
use a callback on the rs-232 library to notify on receipt of the
command, which is a single ASCII character like 'x'. (LWRS_RXFLAG) I
read the inqueue up to the 'x' using ComRdTerm, throwing everything
away (i.e. searching for the message body in the inqueue). I then do
another ComRdTerm for a CRG RTN, thus reading the body of the message
I'm after.
Originally, I was un-installing the callback
as soon as I was in the callback: i.e., I was trying to prevent
callbacks from stacking up due to receipt of subsequent 'x' char in the
in queue. I never saw anything to indicate that I can't do this -
uninstall the callback from within the callback itself.
While
this worked for some commands, it soon became apparent that something
wasn't quite right: the second ComRdTerm was sometimes missing the
first several chars of the message body - it varied from one to maybe
five or six, and happened about 10% of the time the callback was used -
so looking like a timing issue.
I eliminated the
un-install of the callback from the beginning of the callback and
instead unistalled the calback just before exiting the callback. This
still led to errors of the same kind.
Finally, on entry
into the callback , I would immediately zero out the buffer I intended
to read into with the ComRdTerm calls. This caused everything to work
solidly.
Interestingly, it is the time it takes to do
the zeroing that matters: I had it zeroing the wrong buffer at one
point and the code still worked solidly.
Does anyone
understand what type of timing issue might be happening here? Is it OK
to disable a callback from within the callback itself?
What
happens to the inqueue if it overflows - does it wrap around? Drop
incoming frames? If I uninstall a callback, does it then flush any outstanding callbacks on that port that exist at the time of the uninstall?
Other info -
My inqueue size on
OpenComConfig is 4096, and the buffer I do the ComRdTerm's into is
32768 bytes. Baud rate is 115,200. No flow control.
I also use the callback if the inqueue gets half full,
and flush it by reading and discarding 2048 chars out of the inqueue.
#define INPUT_SIZE (4096)
CHAR szInputBuffer[32767 + 1];
RS422Error =
OpenComConfig (PCP_Comport, NULL, BAUD_RATE, PARITY, DATA_BITS,
STOP_BITS, INPUT_SIZE, OUTPUT_SIZE);
VOID CVICALLBACK MessageCallback (INT portNumber, INT eventMask, LPVOID callbackData) {
if
(eventMask & LWRS_RXFLAG) {
for (i = 0; i < sizeof (szInputBuffer); i++)
szInputBuffer[i] = '\0'; // must be here for this to work!?!?!?!
// 'x' is in the input queue. Read up to the 'x', throw away
iBytesRead = ComRdTerm (portNumber, (&szInputBuffer[0]),
INPUT_SIZE, 'x');
szInputBuffer[0] = 'x'; // Put the 'x' back in the buffer as first
char of message
iBytesRead = ComRdTerm (portNumber, (&(szInputBuffer[1])),
INPUT_SIZE, CRG_RTN;
InstallComCallback (portNumber, DISABLE_COM_CALLBACKS,
0, 0, 0, 0);
return;
}
else if (eventMask ==
LWRS_RECEIVE) {
// In queue is at least half full, read half the input queue
size and discard it, 'x' isn't in the first half.
// We can't just flush the inqueue, the 'x' may have arrived
after the callback was invoked. Leave the callback active.
ComRd (portNumber, szInputBuffer, INPUT_SIZE / 2);
return;
}
} // end, callback
Message Edited by menchar on 03-03-2010 04:12 PM
Message Edited by menchar on 03-03-2010 04:14 PM
