It looks like the delay is occuring in SrmReceiveCheck(). It's odd how it will wait for exactly 8 byte times or wait for exactly 8 bytes to accumulate in the buffer before returning. Also puzzling is why this ONLY occurs in OS 5.
If you use SrmReceive() without first calling SrmReceiveCheck() to get the number of bytes in the buffer, you may have problems. SrmReceive() will wait until the number of bytes in the buffer exactly matches the count value that is passed into the function. For example, if you call SrmReceive and pass the value 1 as the count, but there are already 2 or more bytes in the buffer (due to delays in other code such as the system handling events), then SrmReceive() will hang until a serial timeout occurs. It would be nice if it returned immediately with a value of 2 and letting the developer figure out what to do with the extra byte. Just something to keep in mind if you are not able to call SrmReceiveCheck() before SrmReceive() like I am. --- In [EMAIL PROTECTED], "Rob Larson" <[EMAIL PROTECTED]> wrote: > My guess is that the Uart is buffering the characters in its FIFO. > > Instead of the SrmReceiveCheck for a large number of characters, you might > try a SrmReceive for a single character with a timeout of zero (or if zero > doesn't work, try one). -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
