Arduino for STM32

@BennehBoy
One thing you should consider to preserve/reuse is the USBD_reenumerate().
This will ensure to properly enumerate.
https://github.com/stm32duino/Arduino_C ... /usbd_if.c

There's a lot to consider - for example the bootloader magic code handling, I'm not thinking about this just in terms of HID, but about being able to amalgamate any standard classes into a composite. So that could be CDC, MSC, HID interface/s, MIDI, Audio, same footprint as arpruss' library, but I think there may be a lot in his library that caters for edge/niche cases.

And tbh it might all be beyond me

for usbcomposite, i'd think it be a pretty big achievement to support the existing already implemented usb classes as composite devices.
while the generic callback api (e.g. usbcore) is quite 'standard', the protocol themselves are very different.
e.g. even within hid itself, a mouse and keyboard is different and a full keyboard implementation can be very complex and far from a simple minded sendKey(code) kind of api. (keyboard has modifier keys in addition)
usb mass storage is often scsi over usb-mass storage, and if a sd card is involved, another huge sd card protocol stack and maybe even sd-fat gets involved there

for other 'generic' usb device classes, a 'tutorial' or 'wiki' that points to the relevant links and resources is probably adequate.

Fortunately there are people out there who are cleverer than I -> https://github.com/stm32duino/Arduino_C ... /pull/1088

Always best to stand on the shoulders of giants.

interesting i think i'd need to fixup my 3d printer and eventually try running Marlin on stm32

So, I've been looking at CDC, and the CDC+MSC composite PR, and it seems to me that the classes within these need abstracting away. There needs to be an abstracted simple device, a composite device, and then an abstracted class for each interface type, be that CDC, MSC, MultiSerial, Xbox

Some time also needs spending to figure out why the HID menu option doesn't work, then the appropriate abstraction applied to that once fixed, this would give us a HID class (+ each HID type: kb, mouse, joystick, etc).

This way the existing menu based selections can simply instantiate the devices/classes that they need. ie easy mode to keep usb setup in the core. OR the user can elect to not have USB initialised in the core, and do it within the sketch. Building the device (simple or composite) with the appropriate classes as required which would be frontended by a library (obviously one tightly coupled to the core).

It might be possible to maintain API compatibility with arpruss library, but if I'm honest the code in there is pretty impenetrable to me at the moment - probably due to the tight integration with the maple way of doing usb, and my OOP novice status.

Sorry if I'm boring or annoying anyone with my ramblings, I just find it a good way to gather my thoughts.