Go Down

Topic: Try FreeRTOS - compare with ChibiOS/RT (Read 20 times) previous topic - next topic

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

#28
Dec 20, 2011, 10:44 pm Last Edit: Dec 20, 2011, 10:49 pm by fat16lib Reason: 1
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.

Go Up