Go Down

Topic: Multithreading on Arduino? (Read 19587 times) previous topic - next topic


Oct 13, 2011, 05:35 pm Last Edit: Oct 13, 2011, 06:02 pm by westfw Reason: 1
Almost nothing you say about modern preemptive kernels is true.

I said that they're inconvenient in conjunction with critical timing sections of non-OS based code, and that they tend to be RAM hungry, and that they're not necessarily major wins over non-preemptive or non-real-time kernels.  You didn't contradict any of those statements, and I'll stand by them.  They're not necessarily deal-killers; I'm just trying to point out issues and alternatives.

For one-off hobby projects a RTOS can be a good tool to accomplish more with less code and time.

OK.  Less user code, and less programmer time, anyway.  It all depends on how much of your resources you can dedicate to the overhead of the OS.  It's ALWAYS non-zero.

I decline to discuss cisco's internal development efforts.  But it's a good thing that the high end routers do most of their speed-critical work "in hardware."
Even I was surprised when Procket (another competitor) explicitly decided to implement a run-to-completion OS in the same timeframe that cisco was working on trying to get rid of theirs...

FreeRTOS can do a context switch on a m328 in about 50 us.

Is that the (external) time from external event till the task blocking on that event runs, or just the (internal) time to switch tasks?  (the former would include ISR latency plus ISR-related context switch and execution, plus IPC latency and execution fro ISR to sheduler. etc.)  Still, 50us would mean that naive serial code would be limited to about 38400bps, rather than the 2Mbps some people are doing with bare AVR code...  (though I don't see anyone claiming that UART buffering should be handled in a task in FreeRTOS, the way they imply you might do in in QNX.  Feh.)


RTOSes are also good for very large projects.  I was involved with the LHC project at CERN.

The Large Hadron Collider (LHC)  sits in a circular tunnel 27 km in circumference. The tunnel is buried around 50 to 175 m. underground. It straddles the Swiss and French borders on the outskirts of Geneva.

The LHC is designed to collide two counter rotating beams of protons or heavy ions. Proton-proton collisions are foreseen at an energy of 7 TeV per beam.

The control system for this accelerator uses over 1000 computers with most running LynxOS.  LynxOS has 2 us task context switch time and 1 us interrupt latency with modern processors.

This project could never have been done without modern RTOSes.

This control system is totally object oriented with device access code written in C++ and higher layers written in Java.


LHC - so many computers with 1usec latency - now I understand where those missing 60ns come from.. :D.p.


Actually it was the injector for the LHC that created the neutrinos sent 732 km from CERN to the Gran Sasso National Laboratory in Italy.

Here is the paper with about 200 authors: http://estaticos.elmundo.es/documentos/2011/09/23/cern.pdf

I wouldn't bet on the 60-70 ns too soon.  It is an amazing effort but there sure are doubts.

If neutrinos travel faster than light, we should have detected the neutrinos from Supernova 1987A before we saw the explosion itself.

The CERN neutrinos travel faster than light, by about 1 part in 40,000. The neutrinos from SN1987A traveled so far they would have arrived here almost four years before the light did if the CERN result is correct.  However, we saw the light from the supernova at roughly the same time as the neutrinos.

Of course there may be something different about the neutrinos created in the CERN/Gran Sasso experiment.


Oct 13, 2011, 09:32 pm Last Edit: Oct 13, 2011, 10:08 pm by pito Reason: 1
..gravitational sling shot caused by Earth, as the neutrinos posses a mass..
When coming from sn1987a the gravitational influnces of galaxies cancel out.. :smiley-mr-green:

PS: for all arduinists concerned with millis() precision here is a good introduction to timekeeping (look for pdf there):



It's not that hard to use FreeRTOS.  I downloaded FreeRTOS and did a few edits to make it compatible with Arduino.  I made FreeRTOS an Arduino library, AvrFreeRTOS.  It took about an hour.

This sounds interesting.
Is this available somewhere for download?



Brad Burleson

Don't forget to take a look at BeRTOS (http://www.bertos.org/).

Has a few nice demos too and supports a wide array of (fairly cheap) hardware including the Atmega328.

I've played with the APRS demo (works great) and the GPS code as well (not quite as great with the AVR, but it does work).

Just a thought,



I have been looking at BeRTOS and it seems like a good option if you use it's framework.  I haven't been able to take the BeRTOS core and make a library in the Arduino IDE.  I will try a bit more before giving up.

I like the idea of a library since you can use other Arduino libraries and software with the RTOS.  Also you can use the Arduino IDE.

I have made libraries for FreeRTOS and ChibiOS/RT.  You can download them here http://code.google.com/p/beta-lib/downloads/list.  A number of examples are included and they run on 328, 1280, and 2560 Arduinos.

I like ChibiOS/RT since it is very fast, faster than BeRTOS or FreeRTOS, and uses little RAM.


For the most part, the Arduino community is made of people who've never programmed in their lifes before, and I would never suggest an RTOS or any other type of software platform where one must deal with multithreading and synchronization - come on, its already difficult for many professionals, let alone art or VB people. A non-preemptive event driven model is the model for this community.
The "pros" using the Arduino platform will know when to use, and where to get and how to use preemptive OSs, and I doubt it's the best solution for 99.9% of the projects.



It is likely true that 99.9% of Arduino projects don't need a RTOS. 

There are still a large number of projects that can benefit from a RTOS. 

I hear from many people who want to use my SD libraries to log data at rates that are not practical with a simple loop.  This is because there may be an occasional delay of up to 200 milliseconds for an SD block write.  This is a characteristic of SD cards and the way their flash controller works.

I tried writing some examples that used timer interrupts to read sensors in an ISR but these examples were very difficult for users to modify.

I ported FreeRTOS and ChibiOS/RT as Arduino libraries and implemented data logging examples using a high priority task to read sensors and queue the data for the SD write task.  These examples are much easier to modify.

The Arduino has become very popular so a small percentage of sophisticated users is still a substantial number.

If Arduino ARM becomes popular I expect to see more high end projects and a RTOS would be useful.

If the RTOS is packaged as a library it is much easier to use and of course easy to abuse. 


0.01% of Arduino users is still a big number at least compared to others!

Have a look at my article http://www.eeweb.com/blog/robert_berger/arduino-for-mere-m0rtals-part-2 and scroll down a  bit to google trends.

If you do a google search for arduino you get about 15,700,000 results (0.26 seconds).

Let's see what the future brings and also how well arduino will be accepted by "professionals" who know how to program. Besides, as you say, once you understand the concepts of multi-threading it's much easier than poking around in ISR and re-inventing semaphores, mutexes and message queues...




"If you do a google search for arduino you get about 15,700,000 results (0.26 seconds)."

That really doesn't tell you that much about how many users are there; and furthermore, "99.9%" is just a figure of speech. And I don't remember anyone talking about re-inventing mutexes and the like. But nevermind, that's not the point. The point is, as a general programming model, multithreading is very hard for the majority of programmers, let alone non-programmers. Period. Sure you can have some ready to use libs to access SD card or X or Y and that are written on top of an RTOS or any kind of multithreading platform, but that's not the same thing, that is a "lib" and not a general (conceptual) programming tool.


as a general programming model, multithreading is very hard for the majority of programmers, let alone non-programmers.

Yes, and no.  Having beginning programmers write multi-threaded code would not be a great idea.  However, as the processing power grows and users would like to get more and more services from the "core", it becomes convenient for the "core" to become a multi-threaded environment (especially for networking, multi-endpoint USB communications, and stuff like that.)   You don't need to be able to be a multi-threading expert to write "hello world" for a unix or windows system, and yet you have a (rather necessary) multithreading kernel underneath all that to make it easier.
The trick is to standardize on the way that kernel operates so that the the services can be expanded easily by "real programmers" without impacting (so much) the sort of sketches that are written by everyone else.
We don't want so much multi-threaded applications as we want 'time sharing" or simple multiprocessing.  I should be able to write my "blink LED 13 at 1Hz" and "blink LED 12 at 5Hz" "programs" and run them at the same time.
It probably requires changes at the "sketch" abstraction layer as well as infrastructure.  Multiple "loop" functions that can execute "at the same time" as long as they don't interfere with each other.  Or something.  Not trivial, but probably not so bad as teaching the world mutex...  I guess a key factor to consider is to what extent the user is protected from shooting themselves in the foot; what happens when their supposedly independent programs DO conflict with each other?


I'd just like to state I would not want Arduino to have an(RT)OS running by default.  I say this after having used RobotC for vex, which has an underlying RTOS, which runs even when you only write one task.  When I use a microcontroller, I expect to have full control (meaning the kind of control we have now with Arduino) over timing.

I don't see (RT)OSs as necessarily bad, even on an Arduino.  But I would definitely not want it running unless needed, and then only as an externally #included library.  If having a library (RT)OS would require a slower version of the Arduino core, then I would prefer the unmodified core, and a separate version of the IDE/Core with the required changes, such that I don't have to use them.

This is of course my personal opinion.  My RTOS experience comes from RobotC running on a PIC18F (Vex microcontroller), and I specifically remember critical timing not working well, with the random 20ms pause here and there.  You might say I had a bad experience.  I also learned how to program without using multiple tasks, and for most projects done on a 8bit microcontroller, they are not necessary.


I would not want Arduino to have an(RT)OS running by default.

Agreed, for most of the current Arduinos.  When you look at the next generation, running 256k+ of flash at 100MHz, with 1000+ documentation pages worth of on-chip features, I think I want/need something a lot bigger than the current Arduino core, just to handle all the parts that I don't care about.

Perhaps something like the old 8086 MSDOS; providing a lot of infrastructure, but not much in the way of limitations on what the user apps can do.  (DOS was widely denigrated as being a "glorified program loader."  Maybe that's what I want?)

(OTOH, given the problems (mainly WRT security) that largely unprotected program environments have created in the last half-century, maybe what is needed is a really protective environment.  There's a PhD thesis or two there to figure out how to wrap protection around an environment designed to manipulate hardware rather than higher level abstractions.  If .Net Micro and Java ME haven't already done it (and I don't think they have.))

Go Up