New strategic directions for STM32Cube

Ok.

Three years ago, you told us FreeRTOS is dead and you do not intend to fix bugs and support it anymore.

Now you switch again to FreeRTOS.

Now try to reply:

Surprised that I am a litlle upset?

What about tons of bugs we found on FreeRTOS?

What should we say to all our customers we have recommended to switch to ThreadX?

Even STM32CubeIde seems dead - my last report on bugs is only 2 month old and nothing happened.

Ok, you do not have any interest in software and you are probably ready to switch to ever solution that propose new horizons instead of solving old problems and build consistent environment.

second the comment of mbarg.1, there is definitely more explanation needed?

See also: 

https://community.st.com/t5/stm32-mcus-embedded-software/freertos-replacing-threadx-as-the-main-kernel/td-p/802609

Dear ST Team,

Your next work are already determined.

Revive "ChaN's FatFs library support" for recently added newer STM.

Best regards,
Nemui.

@Nemui Trinomius but they've said they're supporting FileX - so that seems unlikely?

What about dual core mcu like h755/45?

This post intends to provide additional information following the questions raised following the developer news and the STM32 summit about the transition to FreeRTOS and enhanced middleware offerings.

The primary goal of STM32Cube Ecosystem is to help developers achieve more and faster, getting the most of STM32 features and focusing on their application and differentiators. In the context of middleware, the main value ST can bring to help developer saving time is optimized porting of middleware on STM32 hardware, with many ready-to-use application examples. Middleware configuration and debug assistance will help as well. STMicroelectronics aims to enable developer as well to cherry-pick in STM32Cube Ecosystem what they need into their own development environment. All software delivered in STM32Cube are free-of-charge with user-friendly license terms.

The porting of RTOS and middleware on STM32 are maintained by STMicroelectronics in STM32Cube Middleware Libraries repositories. These repositories contain the latest updated version of RTOS, and middleware used by STMicroelectronics in STM32Cube framework, without the application examples.

These ports are deployed on various STM32Cube Ecosystem elements and deliverables, across the large STM32 portfolio. You will find some different version of middleware, depending on the selected STM32 series and depending on where you start from.

For instance, you may start from STM32Cube Examples delivered in STM32Cube MCU packages (for instance, STM32CubeH5) and in STM32Cube Expansions (for instance, X-CUBE-FREERTOS) . You may start as well from STM32CubeMX tool, or from GitHub repositories (for instance, STM32H5 classic core middleware)

On the latest introduced STM32 series (STM32U5, STM32H5, STM32C0, STM32U0, STM32WBA, STM32N6, STM32U3), Azure RTOS was delivered as a primary offer in STM32Cube, with the main intention of bringing a consistent and professional grade USB, file system and TCP/IP stack.

With the Azure RTOS components transferred by Microsoft to Eclipse foundation, renamed Eclipse ThreadX and going open-source under the MIT license, ST is committed to continue to provide support on existing STM32Cube packages including Azure RTOS. The safety artefacts formerly proposed by Microsoft are now available from Eclipse foundation, as a commercial offer.

As most of STM32 users stayed on FreeRTOS and LwIP, ST took the opportunity to rework USBX and FileX/LevelX to decouple them from ThreadX and enable them to be used bare-metal or with other RTOS kernels. This will allow to leverage the existing base of USBX and FileX/LevelX application examples to be used with FreeRTOS (and other RTOS).

These new versions for USBX and FileX/LevelX will be released on ST GitHub before end of this year, with some examples on few series of STM32.

@Maxime_MARCHETTO So the key reason for the change was that more users were requesting FreeRTOS than ThreadX ?

From picture above, It seems that for H7 ThreadX will still be the main choice - please confirm, thank you.

An official statement, would help me a lot.

Mike Bargauan

> with the main intention of bringing a consistent and professional grade USB, file system and TCP/IP stack.

It is confusing to me as to why ST would go away from this when ThreadX is also open source now. 

I agree that a lot of users did not switch from FreeRTOS. Probably because the ThreadX offering was new?

Now that ST has officially stopped supporting in CubeMX, I do not think that new/existing users would want to use ThreadX. Sad to see that!

I was really happy with NetXDuo, the first time I tested it with H723 Nucleo, I got 8 MB/s throughput on 100 Mbps Ethernet line. Will ST support NetX driver porting for future devices (May be for the Qualcomm WiFi module)? Or is this out of scope?