RTOS for Embedded Systems

Question

I have seen many articles that tell me I should be using RTOS for time management and resource management. My time has not permitted my own research, so I come to chiphacker for advice.

I use low resource microcontrollers(MSP430, PIC) and was looking for RTOSs I can use.

To the point:

1. Resource cost of system
2. Advantages of system
3. Disadvantages of system
4. Implementation Tricks
5. Situations the RTOS should/should not be used in.

I do not use systems like the arduino, the projects I work with cannot support the cost of such a system.

Answer 1

I haven't had much personal experience with RTOS's other than QNX (which is great on the whole but it's not cheap and I have had a really bad experience with a particular board vendor and QNX's we-don't-care attitude for systems other than their most common) which is too large for PICs and MSP430's.

Where you will benefit from an RTOS is in areas such as

• thread management/scheduling
• inter-thread communications + synchronization
• I/O on systems with stdin/stdout/stderr or serial ports or ethernet support or a filesystem (not an MSP430 or PIC for the most part, except for the serial ports)

For peripherals of a PIC or MSP430: for serial ports I'd use a ring buffer + interrupts... something I write once per system and just reuse; other peripherals I don't think you'd find much support from an RTOS, as they are so vendor-specific.

If you need timing that is rock-solid to the microsecond, an RTOS probably won't help -- RTOS's have bounded timing, but typically do have timing jitter in their scheduling due to context switching delays... QNX running on a PXA270 had jitter in the tens of microseconds typical, 100-200us maximum, so I wouldn't use it for stuff that has to run faster than about 100Hz or which needs timing much more accurate than about 500us. For that kind of stuff you probably will have to implement your own interrupt handling. Some RTOS's will play nicely with that, and others will make it a royal pain: your timing and their timing may not be able to coexist well.

If the timing/scheduling is not too complex, you may be better off using a well-designed state machine. I would highly recommend reading Practical Statecharts in C/C++ if you haven't already. We've used this approach in some of our projects where I work, and it's got some real advantages over traditional state machines for managing complexity.... which is really the only reason you need an RTOS.

Answer 2

Have you tried FreeRTOS? It's free (subject to T&C), and has been ported to both the MSP430, and several flavours of PIC.

It's small compared to some others, but this also makes it easy to learn, especially if you haven't used an RTOS before.

A (non-free) commercial license is available, as well as a IEC 61508/SIL 3 version.

Answer 3

I just found out about NuttX RTOS, that can even work on an 8052 (8-bit) system. It's doesn't have a lot of ports, but it looks interesting. The POSIX can be a plus, because it may make some of your code a little more portable if you move up to a beefier processor and you want to run real-time linux or QNX.

I don't have any experience with commercial RTOS's myself, but I have used homemade ones for years! They are great at helping you divide up your code development among many programmers, because they can essentially each get a "task" or "thread" to work on their part. You still have to coordinate and someone must oversee the whole project to make sure each task can make it's deadline.

I also recommend you research Rate Monotonic Analysis or RMA when using an RTOS. This will help you guarantee that your critical tasks will meet their deadlines.

I would also look into Miro Samek's QP-nano event-driven programming framework that can work with or without an RTOS and still give you real-time capability. With it, you're dividing up your design into hierarchical state machines instead of traditional tasks. Jason S mentioned Miro's book in his post. An excellent read!

Answer 4

One thing I've found useful on a number of machines is a simple stack switcher. I haven't actually written one for the PIC, but I would expect the approach would work just fine on the PIC18 if both/all threads use a total of 31 or fewer stack levels. On the 8051, the main routine is:

_taskswitch:
  xch  a,SP
  xch  a,_altSP
  xch  a,SP
  ret

On the PIC, I forget the name of the stack pointer, but the routine would be something like:

_taskswitch:
  movlb _altSP >> 8
  movf  _altSP ,w,b
  movff _STKPTR,altSP 
  movwf _STKPTR,c
  return

At the start of your program, call a task2() routine which loads altSP with the address of the alternate stack (16 would probably work well for a PIC18Fxx) and runs the task2 loop; this routine must never return or else things will die a painful death. Instead, it should call _taskswitch whenever it wants to yield control to the primary task; the primary task should then call _taskswitch whenever it wants to yield to the secondary task. Often, one will have cute little routines like:

void delay_t1(unsigned short val)
{
  do
    taskswitch();
  while((unsigned short)(millisecond_clock - val) > 0xFF00);  
}

Note that the task switcher doesn't have any means of doing any 'wait for condition'; all it supports is a spinwait. On the other hand, the task switch is so fast that a attempting a taskswitch() while the other task is waiting for a timer to expire will switch to the other task, check the timer, and switch back faster than a typical task-switcher would determine that it doesn't need to taskswitch.

Note that cooperative multitasking has some limitations, but it avoids the needs for a lot of locking and other mutex-related code in cases where invariants that are temporarily disturbed can be reestablished quickly.

(Edit): A couple caveats regarding automatic variables and such:

1. if a routine which uses task-switching is called from both threads, it will generally be necessary to compile two copies of the routine (possibly by #including the same source file twice, with different #define statements). Any given source file will either contain code for only one thread, or else will contain code which will be compiled twice--once for each thread--so I can use macros like "#define delay(x) delay_t1(x)" or #define delay(x) delay_tx(x)" depending upon which thread I'm using.
2. I believe that PIC compilers that can't "see" a function being called will assume that such a function may trash any and all CPU registers, thus avoiding the need to save any registers in the task-switch routine [a nice benefit compared with preemptive multitasking]. Anyone considering a similar task switcher for any other CPU needs to be aware of the register conventions in use. Pushing registers before a task switch and popping them after is an easy way to take care of things, assuming adequate stack space exists.

Cooperative multitasking doesn't allow one to completely escape issues of locking and such, but it really does greatly simplify things. In a preemptive RTOS with a compacting garbage collector, for example, it's necessary to allow objects to be pinned. When using a cooperative switcher, this isn't necessary provided that code assumes GC objects may move any time taskswitch() is called. A compacting collector which doesn't have to worry about pinned objects can be much simpler than one which does.

Answer 5

I have used Salvo on the MSP430. This was very light on processor resources and, providing that you obey the implementation rules, very easy to use and reliable. This is a co-operative OS and requires that task switches are performed at the outer function call level of the task functions. This constraint allows the OS to work in very small memory devices without using vast amounts of stack space maintaining task contexts.

On the AVR32 I am using FreeRTOS. Again very reliable so far but I have had some configuration/version discrepancies between the version that FreeRTOS publish and the version supplied with the Atmel framework. This however has the advantage that it is free!

Answer 6

The December edition of Everyday Practical Electronics has part 3 of a series on Real Time Operating Systems for PICs (in the PIC n' Mix Column) and has details of setting up FreeRTOS with MPLAB and a PICKit 2. The previous two articles (which I haven't seen) appear to have discussed the merits of various RTOSes and settled on FreeRTOS. Once the current article has setup the development environment they go on to start designing a binary digital clock. It appears that there's at least one more part to come on this topic.

I'm not sure how available EPE is in the US, but there does appear to be a US Store linked to from their site and there may be electronic copies available.

Answer 7

The CCS compiler for the PIC comes with a simple RTOS. I haven't tried it, but if you have this compiler, it would be easy to experiment with.

Answer 8

Closely related question: https://stackoverflow.com/questions/1624237/multithreading-using-c-on-pic18

Answer 9

You haven't said much about your application. Whether you use an RTOS depends a lot on what you need to do in the PIC. Unless you're doing several different asynchronous things, which require strict time bounds, or have several threads running, then an RTOS might be overkill.

There are many ways to organise the time on a microcontroller depending on what's most important:

1. Constant frame rate: For a PIC running a servo controller which must run at 1000Hz for example. If the PID algorithm takes less than 1ms to execute, then you can use the remainder of the millisecond to do other tasks, like check the CAN bus, read sensors, etc.

2. All interrupts: Everything that happens in the PIC is triggered by an interrupt. The interrupts can be prioritised according to the importance of the event.

3. Stick it in a loop and do everything as fast as you can. You might find this provides suitable time bounds.