uos.dupterm() behavior in underspecified, implementations broken
While not directly related to HW API, https://github.com/micropython/micropython/wiki/Hardware-API#os-module-additions specifies os.dupterm(), used for:
os.dupterm([stream_obj]) get or set duplication of controlling terminal, so that REPL can be redirected to UART or other (note: could allow to duplicate to multiple stream objs but that's arguably overkill and could anyway be done in Python by making a stream multiplexer)
Unfortunately, this description is not clear/detailed enough, or alternatively, current implementations of it in stmhal and cc3200 ports are not general or just broken. First of all, it should be made clear if the talk is about duplicating "controlling terminal", or replacing it. If there's talk about duplicating, then there should be immediate talk about non-blocking streams. Otherwise this line https://github.com/micropython/micropython/blob/master/cc3200/hal/cc3200_hal.c#L187 will simply hang the entire REPL, as it will wait until a character is available on that particular stream, ignoring all other input sources.
And then if there's requirement to non-blocking streams, it should be kept in mind that all other REPL sources should be non-blocking too, otherwise standard source can block custom installed one. But requirement of non-blocking sources is merely a minimal condition to get it all working, but working quite inefficiently and requiring weird workaround to not make it burn CPU cycles (and a battery of battery-powered device), e.g. https://github.com/micropython/micropython/blob/master/cc3200/hal/cc3200_hal.c#L196. So, next step is making requirement that REPL sources are pollable, and actually poll them.
That's quite a bunch of requirements to get it working in the general case, sure.
Draft: tinyusb cdc class in python / dupterm
Summary
In the stm port the built-in USB CDC / virtual com port is exposed as a class in python. It's also connected to repl by being registered in dupterm by default.
The benefits of this are that at runtime the user can de-register it from dupterm to disable repl in that port and then also use it as a custom stream if desired.
This PR replicates this behaviour on other ports which use TinyUSB.
Testing
This has been tested so far on:
- Renesas
Trade-offs and Alternatives
This does come at a cost to code size.
Currently it's written such that it dupterm is not enabled the previous behaviour is used, with the class no longer created.
A define MICROPY_HW_UART_REPL is commonly used to specify whether a UART should be connected to repl, I'm considering whether a matching MICROPY_HW_USBD_CDC_REPL define should be added to specify whether the CDC should be registered in dupterm automatically or not.
Then there's also a question about whether a separate define should be added to specify if the class should be created anyway in case people want access to that for custom data.