STM32 MCU: AZURE RTOS as an ARM based RTOS? I do not assume.

[tjaekel]

I understand, why STM goes meanwhile with AZURE RTOS: it has several nice features. e.g. FileX, LevelX, several network and USB stacks (where STM needs effort to provide as well).

But I do not understand why this AZURE RTOS should be a "Real-Time OS" for ARM based platforms?

I see so many violations on ARM based coding rules, esp. this:

• ARM based systems use up to four registers directly, for the function call parameters
• if you use more as four parameters on a function call: a stack located parameter is needed (and shuffling registers inside the called functions) - suggestion is to put more as four into a struct and use "call by reference"
• using stack based call parameters: it consumes space from stack (memory size!) - and it can be slower compared to the use of MCU registers (stack is on slower memory)
• it makes it tough to predict how many stack size do you need

I see so many function calls with more as four parameters, e.g. in FileX:
    UINT fx_directory_first_full_entry_find(
         FX_MEDIA *media_ptr,
         CHAR *directory_name,
         UINT *attributes,
         ULONG *size,
         UINT *year,
         UINT *month,
         UINT *day,
         UINT *hour,
         UINT *minute,
         UINT *second);

Is AZURE RTOS really designed to act as an RTOS on ARM systems? (I have some doubts)

It is not "my approach" for a real-time system, esp. to ignore ARM coding guidelines. And it scares me to consider AZURE as an RTOS (with real real-time support).

To be very sarcastic: "why to go with a Microsoft RTOS for ARM systems where their main OS is not considered as a real-time system?"

Dear STM team: why you do not have labels as "RTOS", "AZURE" in your list when posting...?

[tjaekel]

For a real "real-time and mission critical" RTOS I would love to see STM32 supporting Wind River VxWorks or MicroC/OS-III.

VxWorks is well known for "mission critical" embedded systems, MicroC is well known for education (many students get familiar with it). I have used VxWorks since years and I miss still STM32 supporting it - since years (even it comes with a license fee, but using IAR and other IDEs need anyway also a license)

Why departing from FreeRTOS? - I only understand due to Middleware support, such as USB and network protocols. But honestly: moving to AZURE RTOS does make "our live" easier (for hard-core real-time implementations).

[KnarfB]

Azure RTOS is the new name for ThreadX when the company was aquired by Microsoft. TheadX was around since the late 90ies, long before the first ARM Cortex-M appeared. See the ThreadX Wikipedia page for more about its history, certifications, and prominent uses.

It was obviously aquired by Microsoft to have an OS for edge devices talking to their Azure cloud. Similar things happend with Amazon and FreeRTOS, Google and ZephyOS. In such scenarios, edge device hardware is considered interchangable, so the RTOS should be field proven and easily portable to new platforms. You see also on the no licence fee policy, that the money is generated on the other side, the cloud services.

I clearly see you point that you are anticipating performance penalties, but that's the way it goes. And, real-time only means a deterministic worst-case reaction time. In that sense, my bicycle could be considered a real-time vehicle as could be my Ferrari.

hth

KnarfB

[tjaekel · Accepted solution]

All fine.
I agree: AZURE is great, esp. for IoT devices (supporting so many features).
Porting another RTOS - yes, can be done. 

[Andrei Chichak]

I was having some philosophical issues with ThreadX a couple of weeks ago and I got a reply from ST that made my path a little more clear. Let me indulge you.

One phrase that the ST rep used was that ThreadX was going to be used on new processors going forward. The processor that I was using didn't have FreeRTOS as an option, but it was in the git repo if I wanted to graft it into my code.

That made me stop to see what this Azure (shudder, microsoft, don't step in it!) is all about. I find that microsoft is gifting away ThreadX to the Eclipse foundation and the Azure name is going away. This leaves a bunch of chip companies in a weird situation, they all jumped on when microsoft decided that they needed an RTOS to get the IoT people who bleed microsoft blood to use Azure as their back-end. The IoT bubble burst, or never happened, leaving microsoft with an RTOS that didn't bring enough business in to support the project (conjecture on my part). 

So, ST previously chose FreeRTOS, FatFS, LwIP, and did their own USB. All a bit of a bodge, especially LwIP. A much better setup would be ThreadX and all of its associated code, at least it was meant to be used together (unlike LwIP whose authors like bare metal and any issues that you have are exactly that, issues that you have, not them).

Currently it is a bit of a weird time, the handover from microsoft to Eclipse happened in November (???) and the first release is supposed to happen real-soon-now. The RTOS seems to work fine, it's got better safety certifications than FreeRTOS (without going to SafeRTOS), uC/OS was cut loose of Silicon Labs a while ago and I think Jean has had enough so don't expect it to be ported to new ST processors, and Nordic is using Zephyr just to be different.

I've decided to go with ThreadX, but I'm keeping an eye on what ST's next move will be. Will they continue in the consortium, or will they blink and do something completely different. Dropping out would be disappointing for me since the feature set of FileX (wear levelling isn't in FatFS), NetX (proper RTOS support unlike LwIP and mDNS unlike FreeRTOS' networking), and a wider selection of USB devices (including compound devices) look really good for making my future products easier to put together.

[Pavel A.]

> The IoT bubble burst, or never happened, leaving microsoft with an RTOS that didn't bring enough business 

Not quite the bubble burst. IMHO the IoT evolved very fast into "edge compute/ML/AI" which demands more capable processors, with higher security/crypto capabilities as well. This obsoletes the simple old RTOSes.

Of course simple old RTOSes are not dead yet, but their niche applications are no longer interesting for the fat cats.

Want good free (*) OS with good free (*) drivers? Linux.

(*) Just remember that Linux is free - but not cheap.