Thanks for the patch.

Now I think about it, maybe also the mp_machine_uart_read function needs to be changed in the same way?

UART interrupts are enabled for both RX and TX, but they are FIFO interrupts and so an IRQ won't necessarily fire, eg, if you're waiting for exactly 1 incoming byte.

For writing in mp_machine_uart_write, it might be OK to wait for an IRQ there, because the loop only waits if the FIFO is full, and that will definitely trigger an IRQ once the FIFO is drained.

Would be good if we can write a test for this failure, eg write some bytes out on the UART and time how long the flush takes.

Thanks for the comments. I will do both, changing uart.read and write a test case.

Updated with a test and change for uart.read().

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (bd21820) 98.36% compared to head (609d760) 98.36%.

❗ Current head 609d760 differs from pull request most recent head 53d23f1. Consider uploading reports for the commit 53d23f1 to get more accurate results

@@           Coverage Diff           @@
##           master   #13379   +/-   ##
=======================================
  Coverage   98.36%   98.36%           
=======================================
  Files         159      159           
  Lines       21088    21088           
=======================================
  Hits        20743    20743           
  Misses        345      345           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Good catch, thanks @robert-hh. Forgot that you don't always get an interrupt in these cases due to the FIFOs.

I've updated the test so it tests multiple baud rates, and so it's possible to run on other ports/boards.

In case someone else encounters this weird bug - this commit appears to have fixed an issue I had with the Pi Pico UART always reading an extra byte when invert = UART.INVERT_RX was set.

It wasn't waiting for any stop bits - so if the line rose and stayed high, this would be incorrectly interpreted as a null byte (a real null byte should have a stop bit - a negative-going pulse at the appropriate time). This was an issue for me because an RS485 transciever would set the line high when it stopped recieving, so every byte recieved would be followed by an extra null byte.

Anyway moving from v1.21.0 to v1.22.1 has resolved this issue for me, and this PR is the most likely candidate as to why, so thank you!