Embedded ARM OS options?

[Berni]

Well a RTOS can also help you utilize resources more efficiently and reduce CPU load.

When the waiting chain for a resource is short and tightly controlled then you can handle it with interrupts and/or DMA. Its a lot of low level messing about to make everything work nicely and be reliable in non ideal situations but can be very efficient.

But then you get to something like reading from a SD card from multiple parts of your program. All access to your card likely goes trough a FAT32 library to manage your filesystem. So your main code calls the filesystem that calls the storage media abstraction layer that calls the sd card driver that initiates a sector read to the card. Now the card has to go find your data and start transferring it over the bus to you. Okay you might have a DMA handling that so that the whole transfer happens in the background and you get a interrupt when the sectors data is ready to go inside a RAM location, but what do you do in the mean time. The storage media abstraction layer can't do anythyng until it has the sectors contents so the FAT library has to wait and the main code has to wait. So all you can reasonably do in the meantime is service interrupts while the sd card driver waits in a empty while loop until the data is here.

Bring a RTOS in the mix and things look diferently. The moment that sd card driver starts the sector read it goes and tells the OS to switch context so it sends it off running other tasks in the mean time. Once the DMA is done and fires a interrupt that tells the OS to switch context back and unblock that thread and we are back executing where we left off now that we have the data we need and can go on to do things with it. No CPU time was wasted for the cost of a bit of context switching overhead. And in case another thread needs the SD card too it will simply block magicaly since the OS will realise the SD card is not free yet and just stall that thread until its free.

[mikerj]

Okay you might have a DMA handling that so that the whole transfer happens in the background and you get a interrupt when the sectors data is ready to go inside a RAM location, but what do you do in the mean time. The storage media abstraction layer can't do anythyng until it has the sectors contents so the FAT library has to wait and the main code has to wait. So all you can reasonably do in the meantime is service interrupts while the sd card driver waits in a empty while loop until the data is here.

You use state machines to carry on running other "tasks", just the same as any reasonably well written embedded code running without an RTOS.  It tends to start getting a bit messy and more difficult to maintain as the size and functionality of the code grows, which is where an RTOS starts making sense.

[nctnico]

Okay you might have a DMA handling that so that the whole transfer happens in the background and you get a interrupt when the sectors data is ready to go inside a RAM location, but what do you do in the mean time. The storage media abstraction layer can't do anythyng until it has the sectors contents so the FAT library has to wait and the main code has to wait. So all you can reasonably do in the meantime is service interrupts while the sd card driver waits in a empty while loop until the data is here.

You use state machines to carry on running other "tasks", just the same as any reasonably well written embedded code running without an RTOS.  It tends to start getting a bit messy and more difficult to maintain as the size and functionality of the code grows, which is where an RTOS starts making sense.

But you have to realise that this only works if you setup the OS to do time slicing and really run tasks in parallel. This means that you'll need mutexes for shared data and that each task will need to have it's own stack. Many OSses do round robin scheduling by default which is pretty similar to having one big main loop.

IMHO an RTOS only makes sense if you need to interrupt a task (=time slicing) which is taking a long time to complete and thus blocks other tasks. The cost will be high though because time slicing will make the system as a whole less deterministic.

[Berni]

Well yes you can do a lot of multitasking like things with a giant loop of state machines, but it can get messy in some cases.

Taking the SD card example again. Once you issue the call into the FAT32 library you are essentially giving it control of your time sharing since the library was likely something you taken from someone else (If you didin't then you have way too much time on your hands). It won't return until its done with what you asked it to do. And a FAT32 library can become quite busy sometimes. A single call into it could send it looking for the allocation table, realising it doesn't have it ready, then realising it has dirty data in its sector buffer since you can't afford lots of RAM dedicated to that so it has to first flush that, get the allocation table data, realize it needs another part of it from somewhere else, modifies the table and its other copy because its FAT32, flushes all that out and then finally places the piece of data in the location you asked to write upon finally returning back out. In the process making a heap of random read and write accesses to a old crappy SD card that has abysmal random access performance so by the time you get back out of there a lot of time has passed. You could have the sd card driver call some functions to do usefull work while its waiting for data but then those function get time assigned to them very eraticaly and if they set off something that ends up talking to the FAT32 library or the code that started the FAT32 call you could have mangled some data or got into a call loop that eats up the whole stack and crashes. It even does it in that nice random non reproducible way that is a nightmare to troubleshoot.

Not saying that RTOS is a magical wand that fixes all this. If a RTOS is used wrong it can cause huge slowdowns and resource usage and you shouldn't be running like 100 threads in it. But when well thought out to keep the number of threads and context switches down it can make things run very efficiently while providing great and reliable millisecond accurate timing for the semi time critical things. The really time critical things you simply do in oldschool high priority interrupts to take control away from the RTOS and get your nanosecond timing for where you really need it. That way you get the best of both worlds.

[obiwanjacobi]

Just wanna throw this in here, for when you need a bit more structure but (perhaps) not a full-blown RTOS.

There is a way to setup a cooperative multitasking scheme that does not have much overhead. It uses macros to do the magic.

You can put one task in a file (C) or a class (C++) because it requires a singe var to maintain its state-machine.

You can write code like this (main loop / C++)

Code: [Select]

task1.Execute();
task2.Execute();
task3.Execute();
task4.Execute();
The task methods itself (using the macros):

 

Code: [Select]

Task_Begin(Execute)
  {
    // no - this will not hang the program ...
    while(true)
    {
      // ... because we yield from this method (that is the magic!)
      Task_YieldUntil(IncrementCount());
      /* Execution will exit (yield) and enter (next call to Execute) exactly here (Task_YieldUntil).
       * So make sure you perform the action required by the task (for this part) in one method.
       */

       // execution falls through when IncrementCount returned true.
      _counter = 0;
      Serial.print("Counted to ");
      Serial.println(_maxCount);
    }
  }
  Task_End

Note that this is cooperative multi tasking, so play nice.
I have used this in several occasions and it has worked well.
[2c]

[nctnico]

Yuk! Another kind of protothreads! 

[mikerj]

Note that this is cooperative multi tasking, so play nice.

It's not really cooperative multitasking, it's a bunch of state machines hidden beneath some syntactic sugar, just like protothreads.

[obiwanjacobi]

I take it you guys are not big fans of protothreads. 
(had to look it up)

I do not see why this would not be cooperative? It breaks if you do not play nice - that pretty much makes it cooperative in my book.

Anyway, whatever you call this, it works for simple scenario's without much overhead (low on resources - not everybody runs on an ARM cortex with a more memory than you can count) and the ugliness is pretty well hidden in the macros.
You have to follow the pattern -or it may not work- but if you do, it's simple and sweet.

If you have room to spare and you already know an RTOS' API, then by all means, go with that.

[Vic20]

I personally use ChibiOS/RT
It's quite easy to set-up, it can use only static memory allocation, and is complemented with a good HAL.
In my case it is a very good option because of the number of ST32 demos available using this RTOS.
Don't know the work that could be needed to port it to PSOC.

[nctnico]

I take it you guys are not big fans of protothreads. 
(had to look it up)

I do not see why this would not be cooperative? It breaks if you do not play nice - that pretty much makes it cooperative in my book.

The problem is that protothreads (or whatever you call you own reincarnation of it) hides functionality/actual flow in macros which makes the code less obvious and thus harder to maintain.

[rhb]

Minix 3 runs on ARM.  I'm not sure the status of it, but it's got a good pedigree and the project focus is reliability.  I would have suggested it earlier, but it's probably overkill for the OP's work.

[andersm]

Minix 3 runs on ARM.  I'm not sure the status of it, but it's got a good pedigree and the project focus is reliability.  I would have suggested it earlier, but it's probably overkill for the OP's work.

AIUI, modern Minix requires an MMU, while the OP asked about something running on a Cortex-M4. I also believe the ARM version so far only runs on the BeagleBoard and BeagleBone, though that may be outdated information. Probably also a more complex setup than what OP was looking for (same goes for eg. RTEMS and Zephyr).

[rhb]

I just included it for the benefit of someone else reading the thread later. 

I'm not sure why Minix would need an MMU.  I'm pretty sure that it does not implement virtual memory.  The entire reason that Linux came into being was Andy Tanenbaum refused to put in virtual memory and Fred van Kempen got in trouble with Prentice-Hall for copyright violations and had to take down his patches to Minix.

The only reason I can think of that Minix3 would use an MMU is so that an addressing error would generate a page fault and kill the process without doing other damage.

[bd139]

You need an MMU for page protection as well.

[andersm]

I'm not sure why Minix would need an MMU.  I'm pretty sure that it does not implement virtual memory.

According to the release notes, virtual memory was added in Minix 3.1.4, released in 2009.

[Vic20]

You need an MMU for page protection as well.

Memory protection can be obtained using a MPU (Memory Protection Unit)
Cortex M4 processors have MPU but not MMU
You can protect memory pages but you don't get virtual memory

In an RTOS used in firmware development it is usual to trust all the tasks so the MPU, if present, is not always used.
For high security applications a MPU can come handy.
In a Cortex-M4 application I think that a MMU would be overkill.

[mikerj]

I take it you guys are not big fans of protothreads. 
(had to look it up)

I do not see why this would not be cooperative? It breaks if you do not play nice - that pretty much makes it cooperative in my book.

It's cooperative purely in the sense that it's up to the programmer to ensure each "task" doesn't consume too much time, but it's not a cooperative RTOS.