I've got a project on both the K22D and K22F series that needs to communicate at 1000000 baud and hardware flow control is a necessity to make sure that it doesn't miss anything.
As far as I can tell, the hardware RTS signal and the RDRF interrupt are both controlled by the RXWATER threshold. This causes a performance hit, because the only way to be guaranteed an interrupt for every RX event is to set RXWATER to 1, and the UART de-asserts RTS after a single byte, causing the transmitter to hold off even though the FIFO has 7 more bytes available.
The Processor Expert driver appears to only fetch a single byte per interrupt. I was able to modify it easily enough to keep fetching bytes while any remained in the FIFO, but this has the defect of not getting an RDRF interrupt until the RXWATER threshold is reached. If RXWATER is 4 and it only receives 3 bytes, it'll never get an interrupt.
In this particular application the number of bytes to received should usually be known, so I can (if I want to more heavily modify the PE driver or throw it out entirely) set RXWATER appropriately. I still have to add a timer to poll the RX count periodically just in case it gets out of sync. This seems inefficient.
What's the accepted procedure for using hardware flow control without generating an RTS pulse after every single byte? Is there another driver out there that does it any better?
This normally wouldn't be a huge deal and the performance hit isn't that bad, but in this case I'm talking to a Silicon Labs WGM110 WiFi module and it's got a bug in its software UART that will cause it to lock up if it gets just the right RTS pulse. In version 1.0 of the WGM110 firmware you can trigger the bug by generating a 2.5 usec pulse at a rate of say 1 kHz on RTS and the module will very quickly lock up.
Silicon Labs has provided a partial fix that decreases the incidence of the problem, but it still exists. I'm sending in a board to demonstrate the problem so hopefully they'll be able to squash the bug entirely, but in the meantime reducing unnecessary RTS pulses would let me continue with my development work.
Scott
