Basically I want to peek at the driver see when 4 bytes that I am expecting have arrived and then do a single read. fstatus() seems to return 1 if data exists at all.
I'm using an interrupt-based driver.
It is probably better to get characters out of the serial driver one by one and parse the result for your special pattern. Then you can put whatever logic you need at that layer, rather than pollute the driver layer with your application-specific code. I would certainly not suggest embedding knowledge of the application-specific magic four-byte packet you are looking for down in the serial driver layer. Also, what you want to do sounds suspiciously like polling, which is typically not the best plan.
However, if there is some good reason you just need to know if the serial driver has four bytes queued, I would suggest implementing an ioctl command to do this. There is already an ioctl command IO_IOCTL_CHAR_AVAIL that tells you if at least one character is available. It is generic and works for many drivers. You could likely add IO_IOCTRL_4CHARS_AVAIL fairly easily.
Not a fan of polling either and would not think to put application specific things in the driver.
Part of the problem--and I should have mentioned this--is that I'm using a run-to-completion state-machine environment (QP state-machine.com) so I cannot or at least should not make a blocking call. I suppose I could add a separate task that makes a blocking call and publishes an event when it arrives and my state machine would look for this event but that's a little heavy weight for my tastes. I doubt the driver allows me to register a callback.
In that case the ioctl approach would probably suit. _io_serial_int_ioctl() in mqx\source\io\serial\int\serl_int.c provides the implementation for IO_IOCTL_CHAR_AVAIL. It looks like it would be straightforward to copy those few lines of code to implement IO_IOCTL_4CHARS_AVAIL as well.
Thanks for the suggestions. Because I am periodically checking for data (OK polling) I just do the read and associated bookkeeping. If IO_IOCTL_CHAR_AVAIL told me how many bytes were in the buffer that would be ideal as I could just do a single read (into a 32-bit word in my case) when all the data had arrived. It's not difficult to code but I'm a stickler about code maintenance and try to eliminate this sort of noise.
I'm actually not sure why IO_IOCTL_CHAR_AVAIL doesn't return the number in the buffer. I've written many serial port drivers in my day and I always supplied that information.
Retrieving data ...