New version of FreeRTOS for Teensy 3.0, Due, and AVR boards

Status
Not open for further replies.

Bill Greiman

Well-known member
I have posted new versions of FreeRTOS libraries for Teensy 3.0, Due, and AVR as FreeRTOSBeta20121215.zip http://code.google.com/p/beta-lib/downloads/list.

FreeRTOS is extremely popular, the SourceForge site reports it has been downloaded about 100,000 times in the last year. It is easy to port and already runs on most microcontrollers.

Here is a nice study of FreeRTOS http://stiff.univ-brest.fr/~boukhobza/images/stories/Documents/Teachings/OSM/expo/FreeRTOS_Melot.pdf.

See the FreeRTOS website for more information www.freertos.org.

It is possible to disable preemption and run FreeRTOS as a cooperative scheduler.
 
Last edited:
Bill-

I just started looking at getting FreeRTOS running on the Teensy-3. Your .zip file on Google Code appears to restructure FreeRTOS stuff to fit in the Arduino directory tree, but I don't use Arduino (just bare GCC on Linux). Do you have a version of your code that would fit as a subdirectory under FreeRTOS's Demo tree (maybe something like CORTEX_M4_Teensy_GCC? Or a separate directory with a Makefile that you could point to FreeRTOS using VPATH?)

Thanks!
 
I believe the FreeRTOS company, Real Time Engineers Ltd., has a version of FreeRTOS for Arduino. It may have be done by one of their users.

I would go to their website http://www.freertos.org/ and look. If you don't find it, post a question in their forum.

Edit: That version is only going to be for AVR.

I don't plan to make a standalone version for Teensy 3.0. I don't use FreeRTOS much, I just ported it since it is so popular.

For standalone I use ChibiOS/RT on STM32 boards. ChibiOS/RT has super support for STM32 with good device driver support.
 
Last edited:
Hi Bill
I m trying using FreeRTOS (last version) and works very good
But when I try to use Flex Timer 0 the processor and tasks stuck.
Is there any compatibility issue? Or should I use another Time rfor my application?
 
"Using a RTOS for the Teensy 3 is like an automobile without tires"

Not being able to reduce the power consumption, on the Teensy 3, using a RTOS is useless!

Fortunately, help is on the way. :cool:
 
"Using a RTOS for the Teensy 3 is like an automobile without tires"

Not being able to reduce the power consumption, on the Teensy 3, using a RTOS is useless!

Fortunately, help is on the way. :cool:
Power conservation is an entirely different topic than multi-tasking.
 
Power conservation is an entirely different topic than multi-tasking.

Wow - "Real" power conservation goes hand-in-hand with "real" multi-tasking. One without the other you just wasting your time with incomplete microcontroller code
especially when you are using an ARM microcontroller. All "generic" RTOS vendors will make everyone believe otherwise so they don't have to finish their coding effort
for each specific ARM microcontroller. :cool:

What the Teensy 3 needs is a very simple to use RTOS with builtin power management.
 
Last edited:
a single task, single thread non-RTOS program can switch to low power mode and resume upon whatever criteria is chose, e.g., pin change, timer, etc.
Yes, an RTOS can do that in its idle task. But most frequently, an RTOS is an overkill. And preemptive RTOSes require an entirely different mindset in software design.
 
I don't plan to make a standalone version for Teensy 3.0.

Why published ported RTOS's on a Teensy 3 forum board? Your AVR and STM32 RTOS ports should go on the OTHER forum boards.

Yes, an RTOS can do that in its idle task

Just like the MBED's Freescale "Freedom" board.
 
I'm really curious to hear from people who are actually using FreeRTOS or other preemptive systems together with code meant for Arduino.

A lot of the Arduino code isn't really thread safe. Even AVR's malloc & free aren't thread safe. I think newlib's (on Teensy3) might be? Arduino String probably isn't thread safe. I'm not sure about Serial, SD & SdFat, Ethernet and lots of other stuff.

My USB stack might not be thread safe either? It probably isn't if 2 thread manipulate the same endpoint, but it might be ok if different threads are used... 2 threads on Serial, one only for transmit and the other only for receive might work reliably?

I hear a lot of people talk about RTOS usage. Some people certainly have a lot of experience using them, but most of the comments I hear sound much more like very unrealistic expectations. An RTOS does give you some really nice capabilities, but it carries a tremendous cost, not just in RAM for extra stacks, but in dealing with difficult thread synchronization issues.

Still, I've heard almost no solid bug reports about thread safety issues in code that I'm pretty sure isn't really safe for multiple threads. I would like to improve the thread safety of all the common Arduino functions and data streams.... but it's a long process that's ultimately going to be driven by real users reporting issues.
 
I've heard people sing praises for RTOS, I don't see the benefit vs. the potential for trouble and/or the system overhead vs. performance, at least in the applications I have worked on.

Interrupts (timed or external) that set flags are as close as my puny systems come to being RTOS's - but then again I am a sub-MechE not a EE/CS genius. Oh well. :p
 
In the old days I used to do defense projects for big systems using multiple processors with lots of memory. When they came along we started using VME boards instead. These processors had lots of memory compared to embedded processors like the Teensy and were sort of completely different beasts. We pretty much always used an RTOS on them because they had to do many things at once in terms of monitoring multiple async devices and controlling many others. If you have the memory, an RTOS does make a lot of things easier. But, as Paul mentions, things like task stacks do suck up memory that just isn't really available on these small embedded processors.

And writing an RTOS to work right in terms of things like thread safety is tough. Back in the day I was one of the "OS experts" for Raytheon. I did source level work on workstation OSes like Solaris (SUN) and Irix(SGI). I had source code for VxWorks and knew the founder quite well and helped fix a lot of issues and was involved in designing their multiprocessor support. As everyone else has mentioned, getting RTOSs to work reliably can be quite tricky. In fact, I'm working this weekend to get low power operation going on the Teensy and having problems. But I've only been at it a day or two. I was telling my wife (who was wondering why a retired person was getting up at 5am to work on code) that this was nothing like the old days where we might spend many weeks on fixing a single tricky bug. Of course, many times bugs were tied to HW problems which is why I always study errata sheets religiously these days.

Anyways, my typical advice is that if you don't have a lot more code and data memory than you really think you need then don't bother with an RTOS. And if your project only involves one or a few independent tasks then it's easier just to skip the RTOS and do a little judicious interrupt processing if needed. But, if you do need an RTOS then you want to make sure to get one that is really reliable and was ported to your processor by someone who really knew what they were doing. Because, even if they knew what they were doing, there will still be bugs that will pop up occasionally. Just fewer of them.

Well that's my $.02. Now I have to get back to figuring out how interrupts really work on the T3 since this thread doesn't address that issue and I thought it might.
 
Last edited:
I've heard people sing praises for RTOS, I don't see the benefit vs. the potential for trouble and/or the system overhead vs. performance, at least in the applications I have worked on.

Interrupts (timed or external) that set flags are as close as my puny systems come to being RTOS's - but then again I am a sub-MechE not a EE/CS genius. Oh well. :p

Thrust me. That because you never needed an application which must be really RTOS, where time constrains and priorities between different tasks are the most important thing,
I asked me thosund time why should I need FreeRTOS for my Arduino and Teensy applications. Then I had to learn for my university the basic of RTOS in general and since that I think RTOS is better in many applications than simply using time functions and interrupt capabilities. However in FreeRTOS you use interrupt as in your normal applications

Bye bye
 
One good/common need for RTOS on micro: doing IP sockets, where incoming packets on any of several open sockets can occur. Even with TCP, IP, ICMP, ARP offloaded to an outboard microprocessor, such as the WizNet 812/820 (a very smart way to go), there are still needs for managing these data arrival and data send-complete events, plus timeouts, etc. If you don't use some sort of interrupt-event driven tasker, then you have a very messy polling scheme to do, and if there are other real tasks to do such as data acquisition from sensors, driving displays, etc., it gets hard, without an event driven scheduler.
If preemption is used in, say FreeRTOS, you have to design from the get-go for preemption, mutual exclusion, atomic access. Or, as I often have done, use FreeRTOS but disable preemption, and have each of your tasks yield by doing an event wait of some sort in its task loop. This eliminates lots of risks of deadlocks and and so on. But some apps need preemption.
 
Status
Not open for further replies.
Back
Top