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.