shared/tinyusb: Buffer startup stdout (banner) to send once usb cdc is connected. #14485
Conversation
|
Code size report: |
7fddddc to
4d29eec
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #14485 +/- ##
=======================================
Coverage 98.39% 98.39%
=======================================
Files 161 161
Lines 21204 21204
=======================================
Hits 20864 20864
Misses 340 340 ☔ View full report in Codecov by Sentry. |
|
Initial tests working on rp2! |
4d29eec to
3b8e785
Compare
|
|
3b8e785 to
526af51
Compare
|
|
526af51 to
aff686c
Compare
|
Note this PR currently has the TinyUSB submodule pinned to my PR with required SOF updates, so it won't currently build easily. This upstream PR will need to be merged first, it's blocked by the need to test on renesas. |
FWIW I think we could emulate something similar by adding a callback in the mp_usbd_task, or maybe even soft timer. However I think better to stick with the approach you've already used, if it's going to be available soon. |
|
Yes I'd originally thought of using a soft timer however it does have some overheads, and I'm not sure if all needed ports have it enabled. I think the upstream change should be achievable, I've had very productive discussions on it already. I'm just blocked by renesas port testing, I can't figure out the auto generated code being used in the board profiles there enough to enable USB on the evk board I've loaned. |
130e763 to
54e0abf
Compare
|
I've now got a renesas board working finally and have finished the implementation there, it's all working too. I just need to clean up some of the commented code in the nrf stuff and it's all good to go! |
54e0abf to
9b8d07d
Compare
|
This PR has tested working on
The required updates to TinyUSB have been merged upstream and the submodule here is now pinned to the matching master commit. As such I consider this PR complete and ready for review. |
9b8d07d to
b3216eb
Compare
a38ae6e to
94381cf
Compare
|
Branch has been rebased and re-tested on:
|
That's in espressif's custom driver, which is not the one used in #15108 |
94381cf to
4d9c33d
Compare
Signed-off-by: Andrew Leech <andrew@alelec.net>
At startup, buffer initial stdout / MicroyPthon banner so that it can be sent to the host on initial connection of the USB serial port. This buffering also works for when the CDC becomes disconnected and the device is still printing to stdout, and when CDC is reconnected the most recent part of stdout (depending on how big the internal USB FIFO is) is flushed to the host. This change is most obvious when you've first plugged in a MicroPython device (or hit reset), when it's a board that uses USB (CDC) serial in the chip itself for the REPL interface. This doesn't apply to UART going via a separate USB-serial chip. The stm32 port already has this buffering behaviour (it doesn't use TinyUSB) and this commit extends such behaviour to rp2, mimxrt, samd and renesas-ra ports, which do use TinyUSB. Signed-off-by: Andrew Leech <andrew@alelec.net>
4d9c33d to
8809ae7
Compare
|
Now merged! This is a very nice quality-of-life improvement, thanks for the effort getting it all worked out! (I made some minor changes to this PR before merge, to get the ARDUINO_NANO_33_BLE_SENSE board building, same issue as last time.) |
|
Ah yes, that's a good point thanks! The |
At startup, buffer stdout / microypthon banner so that it can be printed on initial connection of mpremote, just like stm port does.
Requires: hathach/tinyusb#2629 (merged) and hathach/tinyusb#2647 (merged)
Extra details: hathach/tinyusb#2595
Sitting on top of #14462
functional change
This change is most obvious when you've first plugged in a micropython device (or hit reset) when it's a board that uses USB (CDC) serial in the chip itself for the repl interface. This doesn't apply to UART going via a separate usb-serial chip.
On all ports other than stm32 currently, nothing happens when you first run a terminal like mpremote on a freshly booted board.
A user might typically first hit enter to look for a repl prompt
>>>to ensure they are connected to a micropython board, then maybe hit ctrl-d to soft reboot and see the banner to check they're connected to the right board.On stm however, on a freshly started board when you connect mpremote the banner is immediately shown!.
This PR extends this behaviour to rp2, mimxrt, samd and renesas. It's also extended to esp32s2 / s3 in the follow up PR.