A SrmReceive with a byte count of one and a minimal timeout should immediately return with the first byte of the two byte buffer. If there is no data available, then SrmReceive should wait for the timeout period and then return with a timeout error code. Any data in excess of the SrmReceive request should be left in the uart or the OS buffer. I say "should" since you have the code & I am just talking theory here.
There are three places the byte travels through on its route to your buffer. First the uart receives it and places it in the receive FIFO buffer. The FIFO buffer can hold up to 64 bytes, and can be programmed to interrupt on one, 8, 16, 56, or 60 characters present (see OMAP documentation for uart3, FCR register, FX_FIFO_TRIG field). The uart certainly has the capability of buffering 8 characters before ever notifying the cpu that anything has happened. The operating system reads data from the FIFO when the uart interrupts, or it could also do it in response to a SrmReceiveCheck (which should look at the LSR register bit RX_FIFO_E (flags "at least one data character in the RX_FIFO)). The OS can either store the character in its own buffer or in yours. If you don't tell the OS where to store the data, then it must use the OS buffer. Finally you issue a SrmReceive, and the character is transferred to the buffer specified with the SrmReceive. Lots of places to get lost here, but the number 8 screams that the data must be stuck in the FIFO buffer. The reason OS/5 behaves differently than earlier OSes is that OS/5 on the Tungsten/T uses the TI OMAP processor. Earlier OSes all run on Motorola 68k cpus, which use an entirely different uart. New code, new bugs. I agree that your code should work, but this looks like a bug in the serial support for the Tungsten/T. Trying SrmReceive would be an attempt to exercise different code that might not exercise the assumed bug. You might also try the code on a Sony NX or NZ machine - the uart is different and so the device driver must also be different. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
