USB discussion

[Levi--G]

Hey @fpistm

I know you are busy so i'll try not to take up too much time.

This week i made the final changes for https://github.com/Levi--G/USBLibrarySTM32 for the 1.0.0 release, i think this would be a good candidate to eventually be a usb alternative for the now existing usb classes. I am open to eventually integrate it in the base core as a built-in library, but i first want to tackle some issues i didn't get done in 1.0.0. And with the (hopefully) influx of more users using it i bet the amount of issues will also need quick bugfixing and i don't want to make everyone download the platform again each time ;)

To that end I need some help supporting the library on arduino IDE next to platformio. I asked arduino for support and created an issue there but that led nowhere and went dead as soon as it was made. (arduino/arduino-cli#2908) The issue is that USBCON and HAL_PCD_MODULE_ENABLED need to be defined without the composite device or other classes loading. One way i could see this is if we would add an option to the usb menu with "External USB library" and then just defining those 2 without the classes. Would you be open to that? Or do you know a better solution?

If we can find something we can agree on i can make a pull request to integrate it?

Looking forward to hearing from you.
Levi

[fpistm]

Hi @Levi--G
I already seen your work and follow it, thanks for your hard work.

I first have to try it to better understand how it works and how to solve/enhance its support.
As a first feedback, I'm not sure add it as a builtin library is a good idea as this will mean we have to maintain it.
As you probably seen the USBDevice support was moved as a builtin library and hope this will help to provide external USB libraries support.
One other idea would be to add the PluggableUSB feature from the Arduino Core API.
About menu option, of course we probably rework it or add new entry.

Last idea, I have is to be able to provide build options override from a library as I think it is a real blocker for some support (ex: FreeRTOS).
I thought to extent the build_opt.h features using the prebuild hook.
Idea is to check if an included library have a build_opt* and then merge it in the one used to build.

As you can see, I've already think about several solutions. So looking forward to hear from you too 😉
Let's go to the test now.

[fpistm]

H @Levi--G
sorry was in vacation.
Let's go for a PR, this is not a big change.

[Levi--G]

H @Levi--G sorry was in vacation. Let's go for a PR, this is not a big change.

No problem, i actually did some testing with this since i posted the reply and it turns out not all files in the built-in library are looking for the CDC or composite flags, so either i add a new define for the external usb and exclude it from all the built-in files or add cdc || composite checks to the built-in files, I think the latter would be easier to implement and maintain? Ill start creating a pr and we can discuss it there.

[fpistm]

OK let's see 😉

[Levi--G]

After even further investigation i have hit an issue i can't seem to solve, the searchpath of the built-in library seems to take precedence over the library (i think pio has library before platform to allow overrides), this means that with the included CDC/composite guards the code doesn't compile due to the inclusion of the standard usbd_conf.c rather than the libraries config. This causes the code to not compile. I do not know of a way to fix this. Arduino cannot exclude platform files from library inclusion like pio can. I think im properly stuck with the way arduino is set up...

[Levi--G]

The external menu option is working fine and i fixed the library import but without the headers from the library the middleware will just use the normal ones. Even if i would include the middleware source in the library the middleware source files would still get compiled.

[Aymane-ST]

Hey @Levi--G , I hope you’re doing great 🙂 ,

I’m currently working on integrating the ArduinoCore-API into the STM32duino core #2852 . As part of this, the core will provide the official PluggableUSB.h / PluggableUSB.cpp implementation. Since you already built an external USB stack that uses PluggableUSB on top of the ST USBDevice library, I’d like to discuss with you how we could eventually use your work as a base to properly integrate it as an alternative to the current built‑in USB classes.

Looking forward to your thoughts 😊

Aymane

[Levi--G]

Hello @Aymane-ST Nice to see there is interest again in the topic! 🙂
I am in fact at the moment still working on improving the implementation i made. Several things are still missing:

• USB HS support (my test boards arrived just last month as an xmas gift to myself 😄)
• Better RAM usage by using less buffers when not needed (for example the usbserial uses too much ram atm)
• Ram allocation at compile time since usb repurposing is a rare scenario and this provides more feedback to endusers their chips don't have enough ram, currently the usb dynamically allocates and fails if too many libraries are used. Very common problem on F1 chips atm.
• Better USB EP distribution, currently only half are used in worse case scenario (due to arduino api using single direction ep only)
• Better USBSerial implementation (the current one is incomplete)
• Better stall handling for the older USB implementation like F1, currently the connection is dropped or data is lost since there is no stall on the older USB stack, (F4 and alike are working with stall already)

As you can see there is still much work to do before i would consider it "finished". But we could always use a beta version and update it along the way. How do you want to proceed with this? We can have a call if you want but its only possible at the earliest next week for me.

Friendly regards,
Levi

[Aymane-ST]

Hello @Levi--G ,

Happy to hear from you, and thanks for the detailed and quick feedback 😊
I see clearly the points you listed as still missing (HS support, RAM usage, EP distribution, stall handling, etc.), and I agree there’s still work to do before calling it “finished”.

From our side, we think it’s a good idea to start integrating your stack in the core as a beta and improve it along the way, rather than wait for a “perfect” v1. We’re considering targeting this for STM32duino 3.0.0, in parallel with the ArduinoCore‑API integration, so that the core itself will provide the official PluggableUSB implementation.

In parallel, we’re also evaluating TinyUSB support. There is already an ongoing PR from @code-fiasco for Adafruit TinyUSB here:
#2906.

We haven’t decided yet how we’ll expose TinyUSB vs the PluggableUSB based stack in the user API (especially since the Adafruit TinyUSB does not use PluggableUSB), but it’s part of the discussion.

A call next week works for me :) .

Best regards,
Aymane