Try FreeRTOS - compare with ChibiOS/RT

[pito]

.. chibios - 390ns context switch with STM32F4 Discokit..

[westfw]

chibios - 390ns context switch with STM32F4 Discokit..

Counting exactly what?  fat16lib's quoted code shows 18 words of context saved and restored (including the stack pointer swap and the registers stacked by the NVIC.)  If the RAM is single-cycle 80MHz memory, that should take at least 450ns...

[fat16lib]

The STM32 F4 used in this test has a 168 MHz clock and

RAM memory is accessed (read/write) at CPU clock speed with 0 wait states.

Push and pop run in 1 + N cycles where N is the number of registers.

The NVIC takes 12 cycles to respond or return from an interrupt. 

The actual register swap takes a lot less than 390 ns.

[westfw]

168 MHz

oops.  I missed that part, thinking it was still in the 80MHz class.  Never mind. :-(
(in that case, 390ns sounds about right...)
(damn; I went searching through the datasheet to see if RAM was wider than 32bits or other optimization, and I forgot to check the clock  rate!)

[pito]

it depends on the compiler and its setting, however. I did with an another compiler and get slower 440ns (11.4, 2.268Meg/sec) context switch, but higher 11.11 (semaphores..) 3.01Megsec.

[fat16lib]

Variations due to compiler settings in tests like this are to be expected but are not important.  These tests measure the performance of a few statements in tiny functions.  Code generation for a single statement can change the results like this.  The ChibiOS/RT source has comments describing how compiler options can change performance.

OS overhead should be a small percentage of CPU use in any well designed application.   In my data-logging example using ChibiOS/RT, the OS overhead for the ADC task is about 1.5% of CPU time.  If the context switch time increased by 20% it would still be under 2% of CPU time.

The infatuation with context switch time and misuse of this feature in preemptive RTOSs is the mark of a novice.  Even though many other feature of a RTOS are more important, context switch time sells software.

Giovanni Di Sirio, the author of ChibiOS, says that a good RTOS will have features that cause you to choose it even if you are running a single thread as a super-loop.

A chip like the STM32 has so many features that need good support.  This include things like use of DMA channels with SPI, USART, ADC and other peripherals.  Proper use of the NVIC priority interrupt controller.  In ChibiOS/RT this is done in the HAL and low level driver framework.

It's a puzzle why people choose a given RTOS.  FreeRTOS is very popular even though it's context switch time is several times longer and it has no driver framework.

[pito]

..interestingly the author of the chibios explicitely picked up the context switch time as the number to show when first run the benchmark on F4..

[fat16lib]

As I said, context switch time sells software even though it is almost never the most important criteria for selecting a RTOS.

In large projects the selection of a RTOS is a major task.  The most common criteria for selection usually include things like this:

available on a particular type of target processor

configurable

scalable

support for specific development languages

availability of application development tools

type of tasking model

type of inter-process communication

type of scheduling mechanism

customer support by the vendor

Here is another list from NASA

• An RTOS is a preemptive multitasking operating system intended for real-time applications.

• It must support a scheduling method that guarantees response time
- Especially to critical tasks

• Tasks must be able to be given a priority
- Static or dynamic

• An RTOS has to support predictable task synchronization mechanisms
- Shared memory mutexes / semaphores, etc.

• A system of priority inheritance has to exist

• Manages hardware and software resources.

• Deterministic: guarantees task completion at a set deadline.
- A system is deterministic if, for each possible state and each set of inputs, a unique set of outputs and next state of the system can be determined.

• Behavior time constraints should be known and minimized
- Interrupt latency (i.e., time from interrupt to task run)
- Minimal task-switching time (context switching)

See table 3 in this for criteria weights http://articles.adsabs.harvard.edu//full/2003ESASP.532E..50M/0000050.005.html

[Coding Badly]

Are there non-real-time alternatives as well?

I'm a big fan of the Quantum Framework.  The learning curve is steep but, in my opinion, well worth the climb.

Did anyone do a serious application that is difficult without a RTOS.

Indirectly.  I developed a support application for an air conditioner controller.  The controller developer used the Quantum Framework.  The bug rate was much lower than an alternative controller based on a preemptive kernel.  The developer was able to turnaround bug fixes in a few days (versus a few weeks), the bugs were generally trivial problems (versus serious bugs that were never properly fixed), and the controller was very responsive (versus stalling from, in some cases, a few seconds).

Directly.  I can say the same things about the support application which was also built using the Quantum Framework: easy to debug, solution expressed in a way that was easy to understand, major modifications did not introduce any serious bugs, and very responsive.

[fat16lib]

I was going to provide QP for test but found Quantum Leaps has a download for the Arduino http://www.state-machine.com/arduino/index.php.

I am a big fan of state machines for applications like Coding Badly described.

For a while I tried to apply state machines to almost every problem.  It worked well for controlling laboratory support equipment, like super conducting magnets. 

In my world, large high energy physics experiments, this was often called slow controls.  Here is a bit about this area at the CERN LHC http://cerncourier.com/cws/article/cern/33360.

Here is a large experiment http://atlas.ch/ at LHC

For other tasks you can't beat a preemptive RTOS.  So match the solution to the problem by prototyping the tricky part.

Once again There is no best solution for all problems.  The main categories are super-loops, round robin schedulers, cooperative multitasking systems, preemptive RTOSs, and state machines.

[FreeRTOS]

I won't pretend to have read this thread other than skimming what is on this page - I just saw it was there from a Google alert, so my comments might not be that relevant.

To comment on context switch times though.  It is often quoted as the be all and end all, but in reality, you can make it as fast or slow as you like, within the limits of the hardware.  To get it really fast, just remove all the functionality (stack checking, tracing, interrupt nesting, etc.) and use a bitmap scheduler (at the cost of usability).  Alternatively, write it all in assembly code, making it harder and longer to port, and harder to test.

The Cortex-M takes a certain time to save/restore its registers.  This is done mainly in hardware, on interrupt entry, so has nothing to do with the RTOS.  What is left of the context can be saved in just one or two asm instructions, which again, are fixed execution time.  When people measure context save times, generally they measure different things on different systems, and compare apples with guava, thinking they are comparing apples with apples.

I never claim FreeRTOS to be the fastest, but one of the cleanest, smallest, best supported, etc. etec.

Regards,
Richard.


+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.

[fat16lib]

Richard Barry's FreeRTOS is certainly very popular and that is the main reason I ported it as an Arduino library.  FreeRTOS works well as an Arduino library.

Personally I prefer ChibiOS/RT to FreeRTOS on the Arduino.  It uses less RAM and the faster performance is not due to assembly code or tricks that make it hard port, it because of elegant design by Giovanni Di Sirio.

On Cortex-M I really like ChibiOS/RT.  Giovanni's support for STM32 is great.

In short I don't think Barry's comments apply to ChibiOS.  ChibiOS has many debug features, tracing, interrupt nesting, etc.

Both are good RTOSs.  You need to choose which you like by using them.

[maniacbug]

We did have a discussion thread on RTOSs a month back, and the conclusion was they were a total waste of time especially in the arduino context.
They just suck the power out of a processor and move the debugging process into the fighting the RTOS region.

I have been experimenting lately with FreeRTOS as a consequence of buying a Maple board, and I am coming to much the same conclusion, at least as regards an ATmega328p.

In my experiments, a stack size of 85 (as in the 323 port, and in the port from the OP on this thread) is a bit small, 100 is safer.  1500 as a heap size is about the maximum safe size.  So that's 15 tasks, minus space for any queues you'll need.

On the other hand, using my personal framework that just manages communication between objects which all call an update() within loop(), I've got active sketches running ~40 things at once, and I'm nowhere near the edge of SRAM.

So I am also concluding that FreeRTOS is overkill for 328p.  Although I am loving it on the Maple.

[fat16lib]

If you can run 40 things with calls to an update function from loop, you have soft real-time and this is a good approach.

You could probably do the same thing with cooperative scheduling in a RTOS since that doesn't require a stack for each thread.  It does allow priority scheduling.  That would allow 40 tasks on a 328.

Also you can always find a way to avoid a RTOS by writing enough special purpose code.  Often using a RTOS saves time if it will solve a problem without a lot of code.  

When I started doing embedded systems, the battle was over assembler or a higher level language.  The answer is that both have there place and we still do some assembler.  The same is true for RTOSs.  Old timers seem to be flat out against using a RTOS.  The fact is that often a RTOS is an easy way to solve a problem even on small chips.

A RTOS like ChibiOS or FreeRTOS is useful if you can't call an update function with a short enough period or if you need to do something at precise intervals.

Data logging to an SD card is an example where calls to an update function will not work well.  A write to an SD card can occasionally take 100 milliseconds.  If you want to take data points evenly space in time every millisecond you need something more than loop.

It is easy to solve this problem with a few lines of code using two threads and preemptive scheduling.  A high priority thread reads the data and puts it in a circular buffer and a lower priority thread writes data to the SD.  I have included this example on 328 Arduinos for both ChibiOS and FreeRTOS.

Once again you can solve this problem in a number of ways without a RTOS but it only takes a few lines of code with an RTOS.

As to FreeRTOS, I much prefer ChibiOS on small chips.  ChibiOS is much faster and uses less RAM.  

I have ported ChibiOS so loop runs as the idle task and has all the RAM that has not been statically allocated to other tasks.   This means you can start writing an application using the normal setup() and loop().  If it turns out that you have a problem that could be solved with another thread it is easy to use the ChibiOS library and add a thread.

[maniacbug]

If you can run 40 things with calls to an update function from loop, you have soft real-time and this is a good approach.

...

Also you can always find a way to avoid a RTOS by writing enough special purpose code.  Often using a RTOS saves time if it will solve a problem without a lot of code.  

When I started doing embedded systems, the battle was over assembler or a higher level language.  The answer is that both have there place and we still do some assembler.  The same is true for RTOSs.  Old timers seem to be flat out against using a RTOS.  The fact is that often a RTOS is an easy way to solve a problem even on small chips.

A RTOS like ChibiOS or FreeRTOS is useful if you can't call an update function with a short enough period or if you need to do something at precise intervals.

Yes, that's right...  None of the things I'm currently doing demand precise intervals or long updates that require preemption.  "Soft" real-time seems good enough.

I too remember the debate between assembly and C.  One of my early projects was whole commercial release on a dual SH-2 machine in all RISC assembly, which turned out to a be horribly wrong decision.

"Often using a RTOS saves time if it will solve a problem without a lot of code."  Also helps with portability.  I'm rewriting some of my RF radio code in FreeRTOS, and it would be handy to one set of code run on all environments.

Anyway, I will try out your ChibiOS port at some point too, once I fully figure out FreeRTOS.