Scrolling issues in edit command

[Guillermo Rodriguez Garcia]

2016-04-05 11:40 GMT+02:00 Rolf Evers-Fischer <embedded24 at evers-fischer.de>:
> Uwe Kleine-König <u.kleine-koenig at ...> writes:
>
>>
>> Hello,
>>
>> On Tue, Apr 05, 2016 at 10:40:48AM +0200, Guillermo Rodriguez Garcia
> wrote:
>> > I am wondering: If I am correct, serial in/out in barebox is not
>> > interrupt-driven. Plus, the default UART in the sama5d3_xplained board
>>
>> right
>>
>> > that I am using (DBGU) has no FIFOs. Plus, "edit" does a lot of
>> > repaint work while editing. Could it be the case that received chars
>> > are being missed by barebox due to the repainting work in "edit" ?
>>
>> Sounds likely.
>>
>
> But if the instruction cache is enabled, the SAMA5 should be fast enough,
> even without any interrupt handling for the UART data.

It actually seems to be fast enough for handling input data the
command line. I only see problems in "edit". And the original issue
(problems while scrolling continuously) mostly happens when the window
needs to be scrolled, and thus fully repainted for every scroll
up/down command received.

I don't think the limitation is actually related to CPU power in the
SAMA5. When "edit" is repainting, it needs to send all the new data
out through the serial port. If serial port tx is also not
interrupt-driven (not sure about that), then this means that barebox
will not have a chance to process new input until "edit" is done
sending data. Combine this with the lack of FIFOs in the DBGU port and
I guess that this could explain the results.

However if there are other issues I would also like to find out. If
you would like to suggest any new tests please let me know and I'll be
happy to try them here.

Best,

Guillermo Rodriguez Garcia
guille.rodriguez at gmail.com