Stuttering issue with native_sim + ec_tui when using the interrupt driven UART

[jerrysxie]

Running on Linux, native_sim connecting to ec_tui app through an emulated UART pipe produces stuttering issues on ec tui. App is completely not responsive.

On WSL, other user observe the stuttering, but it is not as bad. So it seems to be some kind of timing bug.

Switching the rust wrapper configuration for UART from interrupt driven to async

CONFIG_UART_ASYNC_API=n
CONFIG_UART_INTERRUPT_DRIVEN=y

to

CONFIG_UART_ASYNC_API=y
CONFIG_UART_INTERRUPT_DRIVEN=n

causes the stuttering issue to go away. It seems like it might have something to do the cadence of fill/reading from the buffer one byte at a time in the rust wrapper.

[bjackson312006]

More context:

The uart_callback() in uart_interrupt.rs currently reads and writes bytes from the Zephyr API one-at-a-time. If you look at the fn fifo_read() and fn fifo_fill() helpers nested inside the callback, they each call crate::raw::uart_fifo_read(device, &mut character, 1) and crate::raw::uart_fifo_fill(device, &character, 1) even though you could technically pass in values larger than 1. This may cause issues on certain platforms (mainly native-sim thus far). So, because the Zephyr API can accept values larger than 1, we might as well try updating uart_callback() to take advantage of this, since it is a possible cause for the stuttering issue.

This should be somewhat straightforward for TX since crate::raw::uart_irq_tx_ready() returns the amount of bytes you can fill via crate::raw::uart_fifo_fill() (assuming I am understanding the API correctly). However for RX, crate::raw::uart_rq_rx_ready() seems to only return a boolean for "bytes can currently be read" versus "bytes cannot currently be read", rather than an exact number of RX-ready bytes. So we may have to create a static buffer inside the callback and then create a slice from it based on whatever crate::raw::uart_fifo_read() returns for "number of bytes read". For both TX and RX, there will need to be changes to how the callback's while loops work since they are currently built on the one-byte-at-a-time system.