Graduate II

Question

FreeRTOS replacing ThreadX as the main kernel - May 2025 STM32 Summit

Forum|Forum|9 months ago
May 15, 2025
8 replies
3462 views

Hi,

On the keynote speech, I saw that FreeRTOS will be the main kernel.

Does that mean that ThreadX will not be offered as an alternative?
What is the reason for this change?
What about NetXDuo as a middleware?

I am quite happy with how ThreadX and its components worked with each other. Over the years, I have developed several products with NetXDuo, USBX middlewares with ThreadX as an operating system. Not sure why ST is stepping back to FreeRTOS. Curious to know.

Best regards,

Navin

This topic has been closed for replies.

A

Andrew Neil

Super User

@NRedd.2 wrote:
On the keynote speech,

So from the May 2025 STM32 Summit ?

It's an hour-long video - please give a link to where this is actually said.

A

Andrew Neil

Super User

Ah - this has just appeared: New strategic directions for STM32Cube by @Maxime_MARCHETTO:

Transition to FreeRTOS and enhanced middleware offerings

We are moving back to FreeRTOS™ as the main kernel, integrating it with USBX, FileX, and LWIP. This strategic shift will help us build a consistent middleware offering, set to be introduced before the end of this year. Notably, USBX and FileX will be available in both bare metal and RTOS-agnostic versions, providing greater flexibility and adaptability for your projects.

In parallel, we continue our investment in supporting leading open-source frameworks.

@mbarg.1 @jos_

N

NRedd.2Author

Graduate II

@Andrew Neil

It is around -10 minute mark of the video.

A

Andrew Neil

Super User

So here: https://youtu.be/ezHZGMuEA1k?t=2946

L

LCE

Graduate II

> We are moving back to FreeRTOS™ as the main kernel, integrating it with USBX, FileX, and LWIP.

:D :D :D

This is really funny after ThreadX / Azure - but good for me concerning LWIP support, I don't care about OS.

U

urbito

Graduate II

Which other drivers/apps are present in ThreadX and can be good to be ported to FreeRTOS? Any idea?

P

Pavel A.

Super User

Hmmm. Will see. FreeRTOS is attractive because of simplicity and it has CMSIS OS wrapper. But the complicated drivers for ETH, USB and so on won't fix themselves. For ETH, the FreeRTOS+ TCP is worth to consider.

On the top end of the RTOS range are posix-style Zephyr and Nuttx, and then the MPUs. ThreadX can fall between the chairs (like many other Microsoft's orphans).

A

Andrew Neil

Super User

@Pavel A. wrote:
For ETH, the FreeRTOS+ TCP is worth to consider.

and yet ST are promoting LwIP as their IP stack

O

Ozone

Explorer

I have a hunch that certain political and economical circumstances might have influenced this decision as well.
Be that as it may - I am confronted with FreeRTOS-based applications in my dayjob, so this is surely an advantage for me.

P

Pavel A.

Super User

What circumstances? Once Microsoft has adopted ThreadX, they provided skilled resources to port network and USB components to STM32. It was significant and costly effort, resulted in (almost) production quality. Then the love story ended (here I agree, for technical and economical reasons). Amazon still stands behind FreeRTOS, and the community seems to like it because of simplicity - compared to alternatives. So I guess the yield for the money is better for Amazon. Anyway there should be professional support behind complex low-level drivers (ETH, USB, CAN...) on the same level as Microsoft AzureRTOS devs did it. It should be understandable that ST won't develop our products for us and won't provide production grade RTOS for free. What they offer is good for demos, tests and quick prototypes to drive sales of their chips. FreeRTOS is fine for this.

O

Ozone

Explorer

Just a hunch, of course I might be wrong. I was thinking of tariffs and possible future licence issues.

To be honest, I am only somewhat involved in the maintainance of FreeRTOS based application, not much development in this regard in my company. Those applications involve SIL-2 certifications, OS changes / updates are avoided whenever possible. So I didn't really follow developments in this field.
And for my hobby projects I either go bare-metal, or use Linux.