Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes =

[off-list ref]:

=20

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.

=20
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=C2=B5s 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.

=20
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.
=20
Alan