STM32U5 - USB and FreeRTOS?

[dmarks-ls]

I'm starting a project on the STM32U5G9, and one feature we want is USB connectivity, just a simple virtual COM port (CDC class).  Looking at the Middleware picker in CubeMX, the only USB-related items are USBPD (don't need Power Delivery at the moment), and USBX, which is the ThreadX/Azure RTOS USB stack.  If I look for CubeMX examples for the STM32U5G9J-DK2, the only USB examples offered are for ThreadX and USBX.

Is it reasonable to assume that if I don't want to be writing my USB application from scratch on the STM32U5, I should be using ThreadX/Azure RTOS instead of FreeRTOS?

Dana M.

[Pavel A.]

ST offers for STM32U5 so called "classic USB middleware": https://github.com/STMicroelectronics/stm32u5-classic-coremw-apps

 

[dmarks-ls]

Pavel,

Hmm, this indicates to me that, on the STM32U5 at least, FreeRTOS USB support is a "second class citizen".  The fact they're calling it "classic" suggests that what they provide (USBX + ThreadX) in their standard tools is considered "modern", and "classic" is another word for "legacy".  Since we don't have prior experience with ST's "classic" USB firmware, it probably makes sense to adopt what ST currently offers in their mainline tools.  Thanks.

Dana M.

[Pavel A.]

Yes, "classic" means legacy, that's the ST's simple "bare metal" library that existed before the AzureRTOS integrations for STM32.

> it probably makes sense to adopt what ST currently offers in their mainline tools.

Probably yes, but the cost is complexity. If you need a RTOS anyway, this cost is justified. USBX can be used without ThreadX, but examples are scarce.

 

 

[mbarg.1]

We used FreeRtos for many year, but with poor results in term of portability, re-use and reliability.

Since we moved to AZRTOS, we are several order of magnitude more stable and our libraries are fully re-usable.

Spend some time and have a look to AZRTOS, I am sure you will be happy of this effort.

We use as main platform, H7 devices, and we use USB for many task with great reliability and good performances.

[nico23]

@Pavel A. 

Sorry to bring back this old thread but I'm facing the same issue. I need to use the USB Audio class on my TouchGFX project with FreeRTOS.

The project is in an early stage and it seems using USBX in pair with ThreadX seems the easier path as there's no example on how to use USB Audio Class in FreeRTOS and TouchGFX.

I've never had the chance to use ThreadX so I don't know how hard it would be to switch from FreeRTOS on this project.

[dmarks-ls]

I've had extensive experience with both FreeRTOS and ThreadX, so I can tell you, it's actually not too bad.  In a lot of ways, I consider ThreadX to have a cleaner API than FreeRTOS.  (If nothing else, I appreciate that ThreadX doesn't use Hungarian notation for all of its function and variable names.)  All the same basic RTOS primitives are there - threads, queues, mutexes, and semaphores.  You can implement stream buffers and message buffers with a bit of work.

One major difference is that ThreadX does not *explicitly* provide heap support.  But it does have a primitive called a "byte pool" which is effectively a heap.  I let CubeMX declare an application byte pool of appropriate size, then I override malloc() and free() to access the byte pool instead.  (This can work for C++ too, you just need to override operators new, new[], delete, and delete[] as well.)

The chief benefit of ThreadX IMO is that you get the FileX and USBX middleware as well; it's not surprising to me that ST chose to adopt USBX and thus ThreadX for some of their newer parts.  I got USB CDC (virtual COM) working on the U5 with very little difficulty.  (The biggest issue was sorting out how big certain byte pools needed to be in CubeMX.)  If you have any questions about ThreadX or FreeRTOS, feel free to reply to this.

Dana M.

[mbarg.1]

Let me first say I agree with @dmarks-ls and her opinion.

While my experience with FreeRTOS (old code) were not positive, with ThreadX and ..X family we were able to get stable and reliable designs with very little extra effort and overhead, last but not least with an easy learning phase.

We pack many interfaces all time critical in our IOT solutions, Network interface(Ethernet) for management and reporting(SCADA), removable mass storage (USB pen drive, USBX) with legacy file system and Remote access (FTP) for logging events and operations, Modbus RTU on UARTs for levels, Ph meters and other IOT, multiple I2C bus with several devices, a great bunch of GPIO with interrupt, all within a SNTP-driven RTC clock providing scheduling and timestamps on H7 devices with WEB file system in internal flash - all stable, deterministic, and IWDG set for emergency that was triggered only once in one product installed where severe thunderstorm are usual.

And that is why I do ecourage everybody to approach this OS.

Obviosly there is space for further improvement and I hope that ST will drive ThreadX (where they have big leverage) to go further: add new feature, make code more performant, fix minor bugs (yes, nobody is perfect), and look carefully at developers feedback!

Mike B.

[nico23]

Hi @dmarks-ls 

First of all, thanks for the in-depth point of view. It is really helpful.

It's my first try with USB Audio and USB in general with STM32 (I've used I2C and USART for years and they've always served me well ahahah)

Now, thanks to the USB-C on the STM32U5A9J-DK, I would like to implement a very simple sort of sound card to connect to my PC. The idea was to focus on the actual sound-card functionalities such as filters, EQ and more.

I didn't really want to become crazy to implement the actual USB audio communication but I would really love some sort of API that, on the USB-C connection, when an audio stream is sent to the USB, the STM32 is able to pick it, process it and send it back to the PC.  

From your experience, the implementation of such "pipeline", (if possible) is easier using ThreadX and the USBX driver (as it seems I'm unable to find documentation about how to use them to config the microcontroller as USB Audio device and read/send USB Audio datastream)

Thanks again for your help

[dmarks-ls]

I get lots of good hits on Google for this: https://www.google.com/search?q=USB+audio+player+class

In particular, there are tutorials from NXP and Silicon Labs.  These may be for other SDKs, but the concepts should carry over.  And there's the official specification from USB-IF, though it's probably a bit dry.

There's also ST's page for X-CUBE-USB-AUDIO.  And this forum post seems relevant.  Hopefully this gets you started.

Dana M.