hid-remapper VS tinyusb

You could use HID Remapper basically a USB dongle that sits between your device and computer. It's hardware based so no installation on company device, program it at home, plug n play. Supports macros too. Very cheap and easy to build.

Try to build this: https://github.com/jfedor2/hid-remapper

If you do not need WiFi or BLE, take a look at https://github.com/jfedor2/hid-remapper. Works on Adafruit Feather RP2040 with USB Type A Host board. Or use a raspberry pi pico board and wire in a USB Type A host connector. The USB host works by bit-bang assisted in hardware using the PIO.

Here's another solution that is OS independent. I configured mine so that if I hold right click, moving the ball scrolls. Right click works normally when clicked. https://github.com/jfedor2/hid-remapper

The best way I have found is to build an HID remapper and remap the buttons with its web interface. I know most would prefer a software solution but this is very intuitive and gives you so much control over the device.

I know this open source device exists, which among other things can do polling rate overclocking to ensure 1 kHz polling rate.

There's always HID Remapper!

Bill and myself did some e-mail exchanges this week starting about April 25. He is quick. He managed to get the hid-remapper (https://github.com/jfedor2/hid-remapper) from Jacek Fedoryński (jfedor2) working on this new RP2040 and we got our first taste of tremor filtering with the new device.

That would be Pico-PIO-USB library or some people combine two Pico boards (or one board with two RP2040 MCUs).

Check out hid-remapper. It allows remapping of all Slimblade buttons with a lot of flexibility.

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