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

[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.

[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. · Accepted solution]

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.

[dmarks-ls]

We do need an RTOS, especially considering we're using TouchGFX.  To me, ThreadX is just another RTOS, though the last time I used it was on an ARM7 platform (Digi's Netsilicon line of processors).  I just need to port my OS abstraction layer to ThreadX, which shouldn't be too difficult, since I already have a port of it to FreeRTOS.  As long as I've got all my expected primitives, I'm good.  So yeah, I'll bite the bullet and embrace ThreadX for this project.  Having proper middleware for USB will be nice; NXP's Cortex-M USB middleware is a bit of a shambles.

Dana M.

[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.

[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.