UART flushing may use hardware implemented flag
Tartasprint opened this issue · 6 comments
Hi, thanks for this amazing tutorials.
For now I'm following the 06_drivers_gpio_uart. Reading the bcm2xxx_pl011_uart driver, I looked at which registers/field were not used in this tutorial, and I found a BUSY flag in the FR register. According to the BCM2711 ARM Peripherals:
UART busy. If this bit is set to 1, the UART is busy
transmitting data. This bit remains set until the complete
byte, including all the stop bits, has been sent from the shift
register.
This bit is set as soon as the transmit FIFO becomes non-
empty, regardless of whether the UART is enabled or not.
I don't know much about how UART works, so I may be mistaken, but I think that is the hardware equivalent of the calculations made in PL011UartInner::flush. So instead of waiting that the TX FIFO is empty and then waiting for some time, we could just wait for the BUSY flag to be 0.
If that is true, this allow us to make this code independent of baud rate, the number of bits to be sent and the CPU frequency; and make us sure that the UART is flushed properly.
Hmm interesting. This somehow escaped me until now, and it would be an awesome improvement.
I‘ll check it out.
did you give it a try already?
Thanks!
I did try it, and the UART output is as expected (in the 06_drivers_gpio_uart tutorial).
However it doesn't seems to me to be a good test case, since we check if the UART was flushed just after the first time we started it. But I don't know how to make a "good" test of this function.
Tutorial 12 can be abused as a test. If the UART is not flushed first during its init(), some characters of the output in the main file are swallowed by the exception dump (which makes use of the panic-console that re-inits the UART).
Works only on the real device though, not QEMU.
Anyways, I’ll test and implement it once I find some time to do so.
I can to that of you want, I've got plenty of time. I'd be really happy to contribute. I've never done this before, but I read the GitHub tutorial, so I think that I should do a pull request, of course if that's what you want and how it works. I can also make your test on tutorial 12, unless you want to check it by your self.
Hoping to help.
Thanks for the offer!
Regarding pull request, I am in the middle of a refactoring of some tutorial code, so I would want to defer any changes until the refactor is done.
Just checking if it works as the documentation suggests would be enough for the time being, and we can do the PR later 👍
Ok 👍