openAV-Ctlra VS tinyusb

I have been talking to the author of Ctlra who has reverse engineered the screens. The screens work by sending a bunch of pixels to a vendor defined class USB bulk endpoint. Unlike some other controllers with screens which just take some metadata from the software and do their own rendering, Native Instruments controllers with screen rely on the software to do the rendering. Traktor does this by rendering QML to an offscreen buffer. However, according to the author of Ctlra it is more complicated than that to get 60 FPS framerate to the screens because simply sending all the pixels continuously saturates the USB bus. Fortunately that doesn't interfere with any other features of the controller because the other USB signals have higher priority (isochronous for the audio, interrupt for the HID). So to get a good framerate, which would matter for sending scrolling waveforms to the screens, my understanding is that Mixxx would have to compare every rendered frame to identify which rectangles of the screen to update in each USB packet.

Implementing the required USB host interface is another hurdle, but tinyusb seems to have sorted most of that out, except that UAC2 is implemented as a device while you need a host.

Have a look at TinyUSB. It supports the STM32WB and demo programs for the Nucleo-WB55RG. It even offers an example for dual CDC ports, so very close to what you're looking for.

Second: Distrust, misunderstanding, and out of date opinions of C++ in embedded spaces. I often see "compatibilty" thrown around as a goal for using C and not C++, but for most modern embedded systems, C++ compilers exist and are (usually) well tuned. Arm is a shining example here*. C++ is more optimizable than C as the intent can be clearer to the compiler. C++ constexpr and templates are a godsend for embedded systems, and I used both heavily in my recent arduino and pico testing. I combined both of them for a really cool experimental USB interface descriptor builder that runs at compile time and avoids the need to count byte sizes, but I gave up on it when the maintainer said C only, despite the fact that C can't do that. I was similarly disappointed when the pico "C++" was C only, as there was no backwards compatibility necessary.

I looked at this but the fork seems to have had a lot of problems from looking at the PR: https://github.com/hathach/tinyusb/pull/1219

I think a better solution might be to use a USB flash drive in the usbc port. Unfortunately micropython and circuitpython don't support this (yet), so you'd have to use c++ https://github.com/hathach/tinyusb

It's possible to make the s3 be a mass storage device via TinyUSB. https://github.com/hathach/tinyusb/tree/master/examples/device/cdc_msc_freertos