Re: RFC: Clarifying UART API
Hello Daniel,toggle quoted messageShow quoted text
On Mon, 8 May 2017 14:32:56 +0100
Daniel Thompson <daniel.thompson@...> wrote:
Yes, I kinda implied that, and that's why I sent this RFC ahead of fullInterpretation 1:Perhaps we should note that interpretation 1 is the "right" one in
analysis of each and every existing drivers/serial/ case, but just
confirming on my side your previous suggestion to use uart_ns16550.c
driver as the reference.
I also view interpretation #2 is only possible when the reasonerI don't agree here. It's very easy to get to that interpretation by
reading almost any hardware datasheet, even 16550 itself have things
called "Transmitter Holding Register Empty" and "Transmitter Empty",
the first meaning it can slurp more, while latter meaning it's done.
And yep, FIFO is always optional, so reasoning should start without it,
and then FIFO should be consistently integrated into it.
Sure, there would be a patch review where the exact formulation cab beI'm proposing to make the following changes to deconfuse it:Agree. Perhaps phrase as "accept at least one char for a
I kind of agree that it would be almost unrealistic to enforce behavior
like "if irq_rx_disable() was called, then irq_rx_ready() should always
return false". Then, any driver which so far does that in software can
be made few bytes shorter and few cycles faster by removing the ANDing
Similarly I agree that uart_irq_tx_complete() is a useful addition toI definitely appreciate detailed multi-faceted discussion of the matter,
though with all discussion we already had in previous mails, in
tickets, on IRC, I wonder if sometimes we lose track that the top-level
goal of this effort is improving Zephyr's console subsystem, not just
speculative research in UART "zoology" ;-).
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog