Repository navigation
Let Ctrl-C stop a UART write that is stuck on flow control - #11578
mikeysklar wants to merge 4 commits into
Conversation
|
The console and The new write stops on a pending REPL Ctrl-C or reload, which would cut console output short. It also blocks when the host port is closed, where TinyUSB ports drop data. It's Zephyr-only, so I renamed it to |
|
Correction on your first question: the USB console didn't need to change.
Only the UART console calls it directly, since On the console, that Ctrl-C arrives on the same stream, so it's the case you described. |
dhalbert
left a comment
dhalbert
left a comment
There was a problem hiding this comment.
whoops, I didn't actually submit these review questions. The serial.c one is moot now, I think.
|
Sorry for the confusion here. Zephyr's serial writes have three separate bugs, which I split into three PRs: Ctrl-C (this one), the write timeout, and lost USB output. To your question: yes, On a plain UART console that could hang if the other side holds off, and Ctrl-C can't stop it. Our console UARTs don't use flow control, so in practice they always finish. On USB it never hangs; it throws bytes away when the buffer fills. That's the third bug.
Coming next:
|
On raspberrypi and espressif, write() loops until every byte is in the TX FIFO. When CTS is held deasserted the FIFO never drains, so the loop never ends and Ctrl-C is ignored. Check mp_hal_is_interrupted() in the wait loops, the same way read() already does, and return the number of bytes written so far. Fixes adafruit#10621. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
write() sent each byte with uart_poll_out(), which waits inside the driver until the byte is out. When CTS is held off it never returns, so Ctrl-C was ignored. Feed the driver from the TX interrupt in serial_cb() instead. write() only waits for that to finish, stops early on Ctrl-C, and returns the bytes handed to the driver. The console and usb_cdc keep using uart_poll_out(). With the host port closed, the CDC ACM driver drops their output instead of blocking, which matches the other ports, and console output is never cut short by a pending Ctrl-C or reload. Related to adafruit#10621. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
common_hal_busio_uart_write_poll() is Zephyr-only, so drop the common_hal_ prefix. Explain in its comment why the console and usb_cdc use it instead of common_hal_busio_uart_write(). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
It already uses the blocking write, so only the UART console needs the direct call. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
9c046af to
25f1057
Compare
|
Rebased on main, which now has #11586 and #11587. Retested on the nRF54LM20 DK:
@dhalbert ready for another look when you have time. |
2 participants
What
Ctrl-C now stops
busio.UART.write()on RP2, ESP32 and Zephyr boards.Why
When CTS is held off, the write waited forever and only a reset recovered.
Fixes #10621.
Nordic and STM ports still hang; that needs a separate fix.
Written with Claude; tested on hardware by me.
🤖 Generated with Claude Code