It is possible for stm32_uart_rx_timer_expire() to happen before stm32_uart_receive(). In this case, stm32_uart_receive() can jam, running at the rate of the core qemu event loop, which, experimentally, is 1Hz. This makes I/O to a virtual USART device appear so slow as to not be happening at all, or maybe it triggers #7.
This patch address this by resetting the I/O timer every time it expires (much like javascript's setTimeout loops). For my use case, this completely eliminates the flaky I/O issues I've been having with qemu_stm32.
It is possible for
stm32_uart_rx_timer_expire()
to happen beforestm32_uart_receive()
. In this case,stm32_uart_receive()
can jam, running at the rate of the core qemu event loop, which, experimentally, is 1Hz. This makes I/O to a virtual USART device appear so slow as to not be happening at all, or maybe it triggers #7.This patch address this by resetting the I/O timer every time it expires (much like javascript's setTimeout loops). For my use case, this completely eliminates the flaky I/O issues I've been having with qemu_stm32.