Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes [off-list ref]:

quoted

If possible, please do a callback for every character that arrives.
And not only if the rx buffer becomes full, to give the slave driver
a chance to trigger actions almost immediately after every character.
This probably runs in interrupt context and can happen often.

We don't realistically have the clock cycles to do that on a low end
embedded processor handling high speed I/O.

well, if we have a low end embedded processor and high-speed I/O, then
buffering the data before processing doesn't help either since processing
still will eat up clock cycles.

The best you can do is
trigger a workqueue to switch the buffer data around and call the helper
while the uart may be receiving more bytes.

Ok, assuming DMA double buffering might (almost) double throughput.

The question is if this is needed at all. If we have a bluetooth stack with HCI the
fastest UART interface I am aware of is running at 3 Mbit/s. 10 bits incl. framing
means 300kByte/s equiv. 3µs per byte to process. Should be enough to decide
if the byte should go to a buffer or not, check checksums, or discard and move
the protocol engine to a different state. This is what I assume would be done in
a callback. No processing needing some ms per frame.

What you are asking for you'd get out of the first parts of tidying up
the receive paths because you'd set a different port->rx() method and get
bursts of characters, flags and length data.

Alan