2016-04-05 11:40 GMT+02:00 Rolf Evers-Fischer <embedded24@xxxxxxxxxxxxxxxx>: > Uwe Kleine-König <u.kleine-koenig@...> 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@xxxxxxxxx _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
