ThreadX vs. µC/OS-III ?

[bitslip]

Hey all,

I'm thinking of starting some new microcontroller work and I'm looking at ThreadX (Azure) or µC/OS-III , targeting Cortex-M0+ devices, likley from Atmel.  I'm starting with a 'clean slate' and don't have a history with either.  I contemplated FreeRTOS but I find the function naming scheme confusing and looking at the source, it's not the easiest to follow and not the smallest on resources.

Since MSFT has decided to properly open-source ThreadX (announced late 2023) that caught my attention, but uC/OS is also open-sourced (Apache) making it seemingly attractive.

I've tried to do my homework here and spent the better part of this past week looking through the source for both ThreadX and uC-OS and went through a PDF of Jean Labrosse's book.  It seems like uC/OS is pretty cleanly laid out and the code is pretty readable and even supports AVRs, MSP430s, etc while ThreadX seems at home with 32b ARM/ARC, etc.  I did notice ThreadX has more pieces written in assembly, likely for performance / low-power.

Both seem to have GUI tools that support showing tasks, etc ; Segger has one for uC/OS and MSFT has the ThreadX visualizer tools and even what looks like a nice UI for VSCode ( https://devblogs.microsoft.com/cppblog/vscode-embedded-development/ ) .

Context:  I've done work with ARM+gcc going back 20-years so this world isn't new, for microcontroller work I've loved the simplicity of AVRs + CodeVisionAVR+ AVR Studio but know I'm reaching the end of the line there if I want an RTOS or if I want to get away from Windows.  The downside with ARM IMO are details like linker scripts, etc.

Comments or feedback welcome.

[bitslip]

Replying to myself,

One other dimension I didn't bring up in my original post are some of the "extras" that both RTOS seem to have, like TCPIP, FileSystem, USB, etc.  In potential future projects USB, Filesystem & TCPIP would be useful, again no idea if one "distribution" is better than other here.

[shtirka]

Hey all,

I'm thinking of starting some new microcontroller work and I'm looking at ThreadX (Azure) or µC/OS-III , targeting Cortex-M0+ devices, likley from Atmel.  I'm starting with a 'clean slate' and don't have a history with either.  I contemplated FreeRTOS but I find the function naming scheme confusing and looking at the source, it's not the easiest to follow and not the smallest on resources.

Since MSFT has decided to properly open-source ThreadX (announced late 2023) that caught my attention, but uC/OS is also open-sourced (Apache) making it seemingly attractive.

I've tried to do my homework here and spent the better part of this past week looking through the source for both ThreadX and uC-OS and went through a PDF of Jean Labrosse's book.  It seems like uC/OS is pretty cleanly laid out and the code is pretty readable and even supports AVRs, MSP430s, etc while ThreadX seems at home with 32b ARM/ARC, etc.  I did notice ThreadX has more pieces written in assembly, likely for performance / low-power.

Both seem to have GUI tools that support showing tasks, etc ; Segger has one for uC/OS and MSFT has the ThreadX visualizer tools and even what looks like a nice UI for VSCode ( https://devblogs.microsoft.com/cppblog/vscode-embedded-development/ ) .

Context:  I've done work with ARM+gcc going back 20-years so this world isn't new, for microcontroller work I've loved the simplicity of AVRs + CodeVisionAVR+ AVR Studio but know I'm reaching the end of the line there if I want an RTOS or if I want to get away from Windows.  The downside with ARM IMO are details like linker scripts, etc.

Comments or feedback welcome.

Hello,

Are you starting this RTOS project with a specific application in mind? Or is this a project for your own learning/benefit? There are several factors that I usually use when choosing an RTOS for any of my projects (no matter if its open source or commercial):

- RTOS ecosystem and support - how much support is there for an RTOS from the various tools like compilers and how easy is it to get the support from the original authors?
- RTOS licensing model
- RTOS source code distribution and modification constrains?
- Does the RTOS need to be certified for a specific industry or application?
- Performance?
- Features apart from the naked kernel (Apache NuttX is pretty much your full stack: kernel + additional stacks)?
- Additional middleware components?
- How labour intensive is it to integrate with current project?
- Cost?
- Will it make my life easier to solve a specific problem?
- Is there a requirement for a minimum "effective throughput" that an RTOS can deliver (in comparison to other solutions)?
I will be speaking from my personal experience here (others may have other views on the matter), but my worry is that generally speaking an RTOS is a tool you just dont use on a whim because there's only a very limited number of use cases where it truly shines (like when you need a more deterministic system behaviour, or when you have higher demands on system performance or effective/maximum throughput than youd achieve by hand so to speak) so using an RTOS will normally cause you more grief than it's worth (because usually it takes more effort to develop a solution to a problem or the solution becomes more complex than it needs to be - and also the system becomes more difficult to support in the long run). So I would really be considering an RTOS on a case by case basis based on what problem I am trying to solve.

Ilya

[shtirka]

Replying to myself,

One other dimension I didn't bring up in my original post are some of the "extras" that both RTOS seem to have, like TCPIP, FileSystem, USB, etc.  In potential future projects USB, Filesystem & TCPIP would be useful, again no idea if one "distribution" is better than other here.

In case you do want something "substantial" in this respect, then check out https://nuttx.apache.org/ - it does have quite an extensive list of supported hardware and various stacks out of the box. What I personally like about it is that it also supports tracing capability out of the box too. There is also a tutorial about that (https://nuttx.apache.org/docs/latest/guides/tasktraceuser.html) using the Trace Compass (https://eclipse.dev/tracecompass/)

[bitslip]

Hi Ilya,

Thanks for the reply. 

I'm not being paid to do this work nor is it a work for hire, but I am working on an idea that I might end up selling if I think it will be useful to more people.  My intent on this initial project is primarily to learn but also invest in tooling (i.e. an RTOS, networking stack, etc) that I can use in future projects.

About my current requirements, the straight-forward answer is my current project absolutely does NOT need any genuine "real-time" capability (i.e. I'm not implementing a PID control-loop for motor control, etc) but it has a basic LED-based UI, PWM, timers, buttons, etc.  The system can naturally be broken down into well defined 'tasks' (update_ui, process_inputs, update_outputs) so I was hoping to not kludge my own baremetals 'tasker'.

In the past I worked on a pretty "substantial" embedded wireless project (AVR+RFIC) which I did purely baremetals / super-loop as a proof of concept.  The proof of concept worked out fine but as expected, when more formal requirements came down and functionality got added it became a real mess to work on.  In retrospect it was really the perfect candiate for an RTOS (it did need determinism, priorities, low-latency and concurrency).   Debugging that project was painful and a lesson in the importance of good architecture first, implementation later after you know the answers to key questions (and have requirements).

Regarding NuttX, that's a great suggestion, I've worked with it in the past on Pixhawk drone CPUs.  I think NuttX is appropriate for a >=256KB flash type devices (which I think of more in the uP territory) but I'm not looking to do anything that "complex" with a uC right now.

[bitslip]

I spent more time tonight reviewing both code bases and some PDFs I was able to find (a 400 page PDF covering ThreadX for MIPS / ARM pre-SiLabs acquisition & Jean L. Labrosse's book on µC/OS-III ) and I'm currently leaning towards µC/OS-III .

My goal is to use some kind of RTOS on a Cortex-M0+ type device (or possibly even an AVR) and it seems ThreadX has a Cortex-M0 port but not an M0+ port specifically.  I figured it wouldn't be too bad to extend ThreadX to M0+ but looking closely at the "port" and the associated ASM files I noticed things like hard coded constants (addresses for NVIC, etc) without any #defines or mneumonics.  In contrast, the µC/OS-III source code had minimal code in assembly, most of it was in C and pretty heavily commented.  Jean's book is pretty comprhensive too!

My instinct tells me unless I'm being paid to port an RTOS to a new CPU (which I am not!) its worth sticking to an RTOS that potentially already supports your device family(ies).

Still open to further comments.

[shtirka]

Hi Ilya,

Thanks for the reply. 

I'm not being paid to do this work nor is it a work for hire, but I am working on an idea that I might end up selling if I think it will be useful to more people.  My intent on this initial project is primarily to learn but also invest in tooling (i.e. an RTOS, networking stack, etc) that I can use in future projects.

About my current requirements, the straight-forward answer is my current project absolutely does NOT need any genuine "real-time" capability (i.e. I'm not implementing a PID control-loop for motor control, etc) but it has a basic LED-based UI, PWM, timers, buttons, etc.  The system can naturally be broken down into well defined 'tasks' (update_ui, process_inputs, update_outputs) so I was hoping to not kludge my own baremetals 'tasker'.

In the past I worked on a pretty "substantial" embedded wireless project (AVR+RFIC) which I did purely baremetals / super-loop as a proof of concept.  The proof of concept worked out fine but as expected, when more formal requirements came down and functionality got added it became a real mess to work on.  In retrospect it was really the perfect candiate for an RTOS (it did need determinism, priorities, low-latency and concurrency).   Debugging that project was painful and a lesson in the importance of good architecture first, implementation later after you know the answers to key questions (and have requirements).

Regarding NuttX, that's a great suggestion, I've worked with it in the past on Pixhawk drone CPUs.  I think NuttX is appropriate for a >=256KB flash type devices (which I think of more in the uP territory) but I'm not looking to do anything that "complex" with a uC right now.

Now that's where I have had a lot of scepticism towards RTOS'es in general in the past - that you can quite often solve your problem with either bare metal programming or adding things like state machines to the project. So there was very little need for an RTOS as such (at least for whatever I was doing).
Regarding NuttX, as far as I remember, they do have several ports for the less powerful/ AVR's (and also NuttX has quite a few config options for controlling what modules get included/turned on) so its one of those OSes that could well run in a resource restricted environments (like quite a few AVR's - though I dont yet guarantee that it would run on anything with less than 16K). So my personal recommendation would be to at least experiment with NuttX (theres even a youtube channel dedicated to it - https://www.youtube.com/channel/UC0QciIlcUnjJkL5yJJBmluw/videos) if I were you - if you have a little bit of spare time and a spare board that you can dedicate to it for a wee while. Personally I have several evaluation boards with both less powerful and more memory restricted AVRs and more powerful M0+ and M4 (quite a few of them include some sort of memory chips that can be used as temp buffer - something I can also recommend you use, either as an external EE memory or otherwise or onboard) so I will absolutely spend at least some of my NY vacation trying to experiment some more with it and see whats what.

Ilya

[tggzzz]

... The proof of concept worked out fine but as expected, when more formal requirements came down and functionality got added it became a real mess to work on.  In retrospect it was really the perfect candiate for an RTOS (it did need determinism, priorities, low-latency and concurrency).   Debugging that project was painful and a lesson in the importance of good architecture first, implementation later after you know the answers to key questions (and have requirements).

Good to see people trying, assessing with 20:20 hindsight, improving I wish more people were like that!

Where determinisim, low latencies, and concurrency are important, you should be aware of the concepts behind the XMOS xCORE xC ecosystem.

Up to 32 cores and 4000MIPs/chip (expandable). Hardware plus software ecosystem starts from guaranteed timing and concurrency for an embedded MCU. Concepts proven over the decades, available at DigiKey.

What unpleasantness does it avoid?...
No priorities necessary: just dedicate a core to a task.
No interrupts: just dedicate a core to a peripheral.
No RTOS: the equivalent facilities are in silicon.
No measuring timing: the IDE guarantees timing before executing the code. (It examines the -O3 optimised binary to determine the exact number of cycles)

I tried it, and it was a pleasure to use. First hard realtime results less than a day after starting from scratch.

[bitslip]

XMOS devices are very impressive, I'm glad the transputer concepts live on!

For what I need right now (LEDs, buttons, low-frequency PWM), an XMOS device is way overkill, but a good reminder to think about it for the future.

[SiliconWizard]

You can also have a look there, as it was recently discussed: https://www.eevblog.com/forum/microcontrollers/how-does-one-select-an-rtos/

[voltsandjolts]

XMOS devices are very impressive, I'm glad the transputer concepts live on!

For what I need right now (LEDs, buttons, low-frequency PWM), an XMOS device is way overkill, but a good reminder to think about it for the future.

Sounds like an RTOS is way overkill too, TBH.

There is a lot you can do with superloop, either that or just run everything in interrupts using priorities (hardware based task switching for 'free').

[tggzzz]

XMOS devices are very impressive, I'm glad the transputer concepts live on!

For what I need right now (LEDs, buttons, low-frequency PWM), an XMOS device is way overkill, but a good reminder to think about it for the future.

Those concepts do live on, albeit mutated into a different application domain.

Actually several application domains, since bits of the concepts keep reappearing in DSP chips (TMS320), languages (Go), and more. That's a big hint that the concepts are worth knowing!

The XMOS ecosystem is the best example of how hardware and software (a) have a grey boundary between them and (b) can work together seamlessly to be better than the sum. But only if properly designed by people with an understanding of both. There are very few such people; the only other one that springs to mind is Ivan Godard.