Does Arduino need a real-time scheduler?

[fat16lib]

Do Arduino users even want multitasking?  I would be interested in any feedback.

Recently there have been many proposals for an "Arduino Scheduler".

One of the latest, SCoop, even claims to be an "Android Scheduler".  I find this claim to be amazing if the Linux scheduler with cgroups has been implemented on Arduino.

Each proposal claims to have a "simple powerful multitasking solution". 

It's not clear what problem these schedulers intend to solve.  Some proposals claim to be for "real time operating systems".  Other proposals are for schedulers with weak real-time capabilities.

So what is the requirement for an Arduino scheduler?  Only Arduino users can answer this.

You don't need a scheduler unless you want multitasking.  So do you, as a user, want multitasking?  I say "want" not "need" since you can always invent your own solution starting with "bare metal".

If you want multitasking do you need soft real-time?  Soft real-time optimizes resource use hoping to improve quality of service in systems like Android, Mac, and Windows.

Do you need hard real-time?  Hard real-time uses less than 100% of computing resources but guarantee response within strict time constraints.

Performance is not the only reason to use a given scheduler/RTOS.  A RTOS can help simplify a system's architecture by allowing a system to be decomposed into independent tasks and using OS services such as message queues, mutexes, semaphores, event flags, etc. to communicate & synchronize, the system.

A common misconception is that a preemptive RTOS adds an unacceptable amount of overhead.  In fact, a preemptive RTOS will only require between 1 and 4% of CPU time in exchange for valuable services.

A cooperative scheduler is often very inefficient since many unnecessary context switches occur as the result of yield calls.

So what is your opinion about Arduino multitasking and schedulers?

[retrolefty]

So what is your opinion about Arduino multitasking and schedulers?

As a pure hobbyist with mostly a hardware background I have no idea if any of my typical or future projects would benefit from having access to a multitasking and scheduler environment to work inside of.

Most of the beginners questions about needing or wanting multitasking seems to me to be more just a mental block on their part because of not understanding basic C/C++ program structure ability and that one just normally needs to address avoiding blocking functions so that their main loop function can handle all the independent tasks they wish to accomplish in their sketch in a timely matter. Then add pretty simple to understand user and pinchange interrupt capabilities and I just haven't seen the need to have or learn a more complex environment to work with.

So I guess I would certainly be interested from a learning perspective but I suspect if it gets too complex to understand or actually implement, I would probably never get around to actually trying it, not unlike the gazillion arduino libraries I've downloaded, looked at quickly and said "nope, it's over my head". 

Lefty

[fat16lib]

retrolefty,

I suspect you're in the majority and few will use true RTOS features.

Reality is a good thing, I often expect Arduino users to do what young students do here in introductory embedded systems courses.  Edward A. Lee recently modernized the introductory EECS 149 course. 

Here are some example projects. This video starts with a face tracking project.  A camera on a quad-copter tracks the student's face, stays at the same level about four feet away.

http://www.youtube.com/watch?v=VqLlvrMsWc0

The lectures for this course are on youtube http://www.youtube.com/playlist?list=PL62BE418C34C3B2BD.  Slides are here http://chess.eecs.berkeley.edu/eecs149/lectures/index.html

The book for this course is somewhat theoretical but is a good reference and free http://leeseshia.org/releases/LeeSeshia_DigitalV1_07.pdf.

Here is another version student projects videos:
https://www.youtube.com/channel/UCS7MdBus8jygYZy76rIO0pw?feature=watch

[westfw]

So what is the requirement for an Arduino scheduler?  Only Arduino users can answer this.

I doubt that.  I would guess that at least 80% of professional software engineers working in embedded systems would do a poor job in specifying "requirements for a scheduler" for their platform.  50% probably confuse "real time" with "fast."  Arduino users are nearly by definition less aware, and aren't interested in being aware of those issues.

Their answer is probably "I want to be able to do several things at one time."  That's probably what their answer should be.  That's the way most desktop users think of things as well.
If you can get some quantitative answers for the value of "several", and the limitations (timewise) of "at once", you'd be doing really well.  Consider:

Code: [Select]

task foo1 {at noon digitalWrite(1, HIGH);}
task foo2 {at noon digitalWrite(2, HIGH);}
  :
task fooN {at noon digitalWrite(N, HIGH);}
What's an appropriate value for N, and how many milliseconds after noon do all the N pins need to be high?
Is it more important for that number of milliseconds to be small, or to always be the same?
THIS kind of question you might be able to get answers for.

a preemptive RTOS will only require between 1 and 4% of CPU time in exchange for valuable services.

*will* required, or *could* require?  I find that number hard to believe, depending on what it is measuring.  Although... CPU time is probably not the bottleneck resource, so it probably doesn't matter.

[fat16lib]

westfw,

Their answer is probably "I want to be able to do several things at one time."  That's probably what their answer should be.  That's the way most desktop users think of things as well.
If you can get some quantitative answers for the value of "several", and the limitations (timewise) of "at once", you'd be doing really well.  Consider:

Your almost certainly right.

I have experience with two types of users, research physicists, and EECS students from UC Berkeley.  Both groups are comfortable using a RTOS.  Older EEs not so much.

I am a PhD physicist and I have done architecture and design of control systems for many large experiments.  We started using RTOSs about 40 years ago.

I did some work on LHC, the big experiment at CERN looking for the Higgs Boson.  CERN has used LynxOS in control systems for over twenty years.

Some of my colleagues left the lab to develop VxWorks.  NASA JPL uses VxWorks in all Mars rovers.

I find it hard to understand the resistance to use of RTOSs.

Maybe a tutorial with more realistic example application would help Arduino users understand the value of RTOSs.  Cortex M clearly was designed for use of an RTOS.

On the other hand, unless you understand things like reading an ADC at relative slow rates, like 100 Hz, requires a time jitter on the order of one microsecond if you want low SNR in the signal.  The SNR of an ideal 10-bit ADC is about 62 dB.  At 100 Hz, 4 microseconds of jitter in the reading time reduces the SNR to about 52 dB.  A coop scheduler just won't schedule a thread with low jitter and reading a sensor in an OS thread is easier than setting up a timer driven ISR. 

*will* required, or *could* require?  I find that number hard to believe, depending on what it is measuring.  Although... CPU time is probably not the bottleneck resource, so it probably doesn't matter.

The measure generally means CPU time.  A RTOS has no extra overhead unless you call a OS function or an event causes a context switch.  You don't do a context switch for every interrupt and many fast interrupts can be handled just like the bare metal approach without any OS overhead. For example a serial driver puts bytes in a queue just like the Arduino drivers.

On a chip like a 72 MHz STM32, a context switch with ChibiOS costs just over one microsecond.  A well designed application should not have more than a few thousand context switches per second so the overhead will be a few percent. 

A preemptive RTOS responds to an important high priority event with the handler thread running in one microsecond but with a coop scheduler, who knows.

[pito]

I find it hard to understand the resistance to use of RTOSs.

That is not about the "resistance" but the need. Most arduino users do not work for LHC or NASA and their designs work just fine with a superloop
With more demanding applications they will certainly consider an rtos..

[fat16lib]

That is not about the "resistance" but the need. Most arduino users do not work for LHC or NASA and their designs work just fine with a superloop

pito,

Given a choice of a supperloop or two simple tasks, scientists who write device code choose the simpler more reliable task model.  A RTOS provides better partitioning of an application even in simple cases.

Old EEs make the funny spaghetti supperloop that mixes timing and code for two distinct operations.

I think experimental physics groups adopt things like RTOSs more readily because the learning overhead is shared.  Members help each other, the first person to learn the system helps the next person.

A RTOS is not like learning a new programming language.  It requires a different architecture for embedded systems.  That's why modern embedded systems text books don't emphasize details of the OS.  These books cover things like why preemption is required for rate monotonic scheduling and why this is important for reliable systems.

[westfw]

I find it hard to understand the resistance to use of RTOSs.

Well, there's one set of people who doesn't understand what an RTOS is, what it would give them, or how they'd choose between multiple options.  They have enough problems figuring out how to divide a program into functions, much less into concurrent "tasks."

There's another set that understands, but is worried about the complexities that you know or suspect comes with it.  Perhaps they've been burnt by a negative experience with an existing RTOS.  Or they're worried that they don't want to increase latency to get certainty.  Or they're just comfortable, given the size of Arduino, that they can get along without it.  Case in point:

CERN has used LynxOS in control systems for over twenty years.
Some of my colleagues left the lab to develop VxWorks.

So given 20 years of experience with an RTOS, your coworkers were so frustrated with it that they went to work on a different RTOS ?  :-)

A RTOS is not like learning a new programming language.

The hell it isn't.  Especially if the product is already intentionally blurring the lines between "language", "library", and "run time environment."

[fat16lib]

westfw,

So given 20 years of experience with an RTOS, your coworkers were so frustrated with it that they went to work on a different RTOS ?  :-)

Wrong!  They didn't work on a different system, they commercialized the open Berkeley system as VxWorks and NASA started using it.  CERN picked LynxOS in Europe at about the same time.   CERN and LBNL are happy with their systems.

VxWorks now has over a billion copies in products.  Several other commercial RTOSs also claim over a billion copies in products.

RTOSs aren't that different in basic functions.  Almost all commercial RTOSs have a fixed priority preemptive scheduler.  They have similar synchronization/communication primitives. I find it easy, almost mechanical to convert a program from one to another.

You can't choose an RTOS because you don't understand the associated theory.  That's what engineers learn in courses like UC Berkeley's EECS 149.

You comments are valuable.  I get the message that you will never use a RTOS. 

At least you are not like the old engineer I knew who programmed a ROM for one of the first micro-controllers by filling in squares on a engineering pad and then entering them in switches in his home made programmer.  I never got him to use an assembler.  That was around 1971 or 1972 and it might have been a 4-bit 4004.  We quickly moved to the 8008 but left the old EE with his pad behind.

[pito]

What kind of rtos did you use with 8008?

[PaulS]

Given a choice of a supperloop or two simple tasks

I know which a Hobbit would choose.

[fat16lib]

PaulS,

Sorry, I depend too much on seeing red for spelling errors but it doesn't work for superloop/supperloop.

pito,

We did some prototyping on the 8008 and decided it wasn't flexible enough.  We were in contact with MOS Technology which was formed in 1972 so we moved to the 6502.

We built a little kernel and attached lots of RAM since there was no flash then.  We didn't name the system.

Of course Apple used the same chip for the Apple I in 1976 and Apple II in 1977.

We attached these systems to a serial port on a terminal server and downloaded programs from a CDC 6600 supercomputer.  We programmed in PL/M, not assembler.  The cross compiler ran on the 6600.

One reason I find Arduino interesting is that its technology is so much like what I was doing 40 years ago.

By 1980 commercial kernels like VRTX were available for chips like the 68000 and we moved beyond Arduino style systems.

[ddmcf]

I'm probably not a typical Arduino enthusiast, but I almost immediately looked for a scheduler for my first project. Maybe out of preference because I know I could do my project with a super loop, and even an RTOS, but all I really needed was a scheduler with inter-process communications. I say "need" because that is my preference for this particular project.

In my retirement I'm building a smart toy for my granddaughter that will have up to 8 I/O's that need to be handled asynchronously in "real time". I could not find a simple scheduler (and I did ask on the forum as well) so I adapted the Quantum Leaps code and built what I call an asynchronous (non pre-emptive) device framework on top of it. It is more than adequate for my project needs, and is scalable for future projects. I admit that I had fun building the framework, but I would have easily used something already available.

Because I feel strongly that a scheduler is a good tool for solving specific problems, and I was unable to find one, I wrote about how I adapted QF to make it easier for others to do the same:

http://wizmoz.blogspot.com/2012/12/quantum-leaps-arduino-state-machine.html

There are a wide range of user skills and project complexities in this forum. The hobbyist that needs to blink some LED's isn't going to need a full blown scheduler or an RTOS, and someone writing code for particle collisions probably doesn't want one; but there are some of us here in the middle that would benefit from such a scheduler, whether a kid toy project or something more demanding. Absolutely, yes.

[fat16lib]

ddmcf,

I agree, the Quantum Leaps state machine framework is an excellent type of scheduler for applications like your project.

What kind of feedback have you received?  Is your tutorial sufficient to get people started?

I am curious how Arduino users react to state machines. 

Students are introduced to finite state machines early in introductory embedded systems courses.

[westfw]

I get the message that you will never use a RTOS. 

I wouldn't go that far.  I can't see filling up the memory of a MEGA or DUE without more structure (in the form of SOME sort of OS.)  I doubt whether I'd ever need the "real time" aspects, but that seems to be what is available; I can't see writing my own, especially when the existing rtoses are getting pretty favorable reviews.

Most of my professional career was spent programming under a proprietary, non-preemptive, not real-time OS.  OTOH, that company's experiments with real RT kernels was less than spectacularly successful.   When your uart ISR starts sending messages instead of just reading the chip, something has "jumped the shark."