> Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx>: > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
