Hello Andy,

On Fri, 7 Apr 2017 08:29:08 -0700
Andy Ross <andrew.j.ross@intel.com> wrote:

Paul Sokolovsky <paul.sokolovsky@linaro.org> wrote (on Thursday,
April 06, 2017 11:04PM):

My kind request though is: please don't try to shift it all on UART
and talk about the need of DTR/RTS, etc. UART is damn slow device by
the current standards, which should "just work" with dozens-of-MHz
CPUs without any flow control on hardware side.

I'm not completely sure I buy that. If your consumer thread isn't
being scheduled due to all the UART interrupts, the CPU is clearly
*not* fast enough

Thanks for the reply. The original hunch was that there was some kind
of issue with the scheduling implementation. I explained where it came
from - because other explanations, like "fast thread can't keep up with
slow ISR" or "the problem is in UART handling" seemed to be too simple
an answer and thus unrealistic to be true. It more and more looks like
I was wrong, and the issue lies on UART handling side, and is a
relatively obvious to be looked at and ignored :-/.

to handle the bytes arriving at the line rate (maybe
that's something we should fix, though -- have you looked to see where
the cycles are going?).

Speculatively, yes - they go into busy-polling implementation of UART
TX. And as mentioned in my previous email, we always spend more cycles
to send a char (because of the overheads we do besides send), than to
receive, so with busy-polling send, we'll never get a reliable behavior.

I mean... I know you don't want to hear this but the situation you
have is precisely what buffering and hardware flow control are
designed to solve. Make the buffer big enough to handle the sudden
flood, or flag your buffer-full condition to the other side with
RTC/CTS (I know this won't work on lots of console devices which don't
wire the flow control lines).

So, either everyone does wrong, or people save on wires because they
aren't needed in prevalent number of modern usecases.

Or if you can, adjust the protocol to
include a software flow control mechanism like an ACK with a max
"packet" size (not XON/XOFF though, that never works).

Right, the last one is 2nd most popular workaround nowadays - almost
all protocols are request-response, and require response much sooner
than after sending a megabyte of data, but some do send many kilobytes
nonetheless. The 1st workaround is still just handling a UART with a
fast CPU such that flow control issues aren't hit in the realistic
scenarios. "Realistic scenarios" include being able to paste a dozen of
lines in an echoing application. That works in many systems
- why don't we target Zephyr being able to do that too?

Andy

Thanks,
Paul

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