Migrating stm32 USB to TinyUSB

[andrewleech]

I'm keen to work on migrating stm32 USB to TinyUSB, consolidating support with other ports and eventually adding support for the software defined USB profiles.

There are currently a couple of features in the stm USB stack not supported on TinyUSB:

• Buffered startup messages
• Flow control
• DFU in mboot

Are there any other major differences in missing?

The way I see it, mboot can probably stick with the stm stack for now, and most of the flow control settings are things I originally added to stm so I should be able to replicate them on TinyUSB if needed/possible.

The startup messages though is a neat feature on stm that's currently missing on all TinyUSB ports that's worth adding across the board; this is how stm boards always print the startup banner/MOTD when you first open the USB/serial repl even after the board has been running for some time.

In my (simplified) understanding, the stm port essentially configures the ram buffer that's allocated for the CDC port, at startup this is filled with stdout like the banner; once the buffer is full any new stdout is discarded until USB repl is connected and the buffer drained.

I did some initial tests with TinyUSB and I don't think there's any way to make it behave this way with its CDC output buffers.

Option 1: There's always a possibility to modify TinyUSB to support something like this... or

Option 2: TinyUSB could be configured with minimal / no output buffers and we manage the stdout (ring) buffer ourself?

Option 3: Alternatively I could reflector the startup messages/banner into its own function that can be simply re-run upon detection of USB com port connection.

There could be times that other stdout during startup would be useful, which just printing the banner wouldn't help with, but having a big buffer around just for this is inefficient. In most cases a board could always be configured with UART repl if needed to diagnose a startup issue.

Any other thoughts / considerations I'm missing?

[dpgeorge]

There could be times that other stdout during startup would be useful, which just printing the banner wouldn't help with

Yes, I often rely on this feature, that general stdout output is available (not just the banner).

If we move to TinyUSB for stm32, I would work hard to keep this feature of initial data on start up.

[andrewleech]

Is my basic explanation of the feature / requirement correct, in that the first buffer _size worth of stdout is preserved until USB is connected; but if more than said buffer is written it's ignored & lost?

[andrewleech]

Work started in #15592