FreeRTOS or other OSes for MCU, practicalities of it

[Kremmen]

@Kremmen: if I want all that I use an embedded Linux board.

Sure, go ahead then I would'n for a second consider Linux any kind of alternative or competitor to a true RTOS. There are realtime extensions to Linux such as used in the popular LinuxCNC machine controller. But by that time all resemblance to an embedded small system are totally lost. And good luck porting Linux to a random HW platform you design into the latest project.

I really suggest, if you really want to work with RTOSes, than cook your own RTOS.

Jesus, NO! That is like saying that if you want to drive a car, a good way to begin is by building one from iron ore. Writing a good, bug free (sic) OS is anything but an exercise to do at your leisure.
Granted you will learn a lot if you do write one but that is absolutely not necessary or even desirable if you actually mean to produce a working application before the end of the century. I did it first time in the 80s but only because at that time practically none existed in the world and there were these complex manufacturing centers to program.
Instead you should understand the principle of scheduling but that can be accomplished without implementing one.

[...]
There is a golden line where the RTOS is needed, some never have to cross it. I've seen people cross it, and then fail miserably, because they didn't adopt. You will know this, when you hear the programmer code monkey say, that they need weeks to implement this new function, because they did not think about it when they made the software architecture. Implementing it in RTOS is starting a new task. In a hard-coded timing environment, it is indeed, more difficult.
I put that fine line somewhere at the axis of 40Mhz, Ethernet, touchscreen, printing, more than one programmer. If any of these is present, I would go for an RTOS.

My practice is, if the hardware at hand will take it, then always use an OS. So the logic goes the other way around - only in exceptional cases where you are desperately short on something that really prevents you from reasonably fitting in a RTOS, then don't. In all other cases just use it and be done. The applications tend to adopt similar high level structure, similar ways to handle similar things and there is predictable logic in how things are handled due to the OS guiding the implementation into a repeatable pattern. All big bonuses for debugging and later code changes or extensions.

I think...  If you want to use a multitasking OS on a MCU, you should first become familiar with the issues of multitasking by working on some multi-process desktop or server applications.  "Real time" is a distraction that you shouldn't worry about at first (and maybe not ever.)

Well, maybe the "real time" is not strictly measured in nano- or microseconds in all cases. What _is_ important is that the OS has a deterministic response time or as close to one as possible. In that respect the desktop OSes suck. They may be like greased lightning only to suddenly fail miserably when they get stuck in a disk I/O exercise or something similar.
And if you ask me, there is nothing to gain from rehearsing on a desktop machine. They obfuscate the multiprocessing behind so many veils of unnecessary stuff that i say the opposite: if you wish to quickly understand multitasking, then implement a toy app on an embedded platform and debug the hell out of it. All of the code sits directly there instead of being encased in some opaque device drivers or protected kernels.

P.S. Pay attention to tggzzz, he has got it right.

[miguelvp]

There is such a thing as OS-9 for ARM but Microware has lost so much ground since the 68000 VME boards and their site and distributors can be counted with just one hand.

But it was a great RTOS, maybe still is but no one uses it that I know of, and apparently they support x86 and some other chips.

Then again being now so small I wonder if their price went down accordingly.

[Kjelt]

I really suggest, if you really want to work with RTOSes, than cook your own RTOS.

The only valid reason I can think off to write your own RTOS is if you study RTOS or it is your job.
For the rest there are only good reasons NOT to write it your self such as that the code has been around for years, is tested and proven on millions of devices and users.  If there were significant bugs they have been found and solved. Your own code could take years to become as mature.

Most important the freeRTOS is open source software, you can learn by stepping/reading through it and if you come across something you do not like
you can even change it, now that's programmers heaven and it does not become any better than that.

If your micro is tiny and has not the capabilities of running an RTOS then I can imagine (and did it myself) that instead of using a superloop you write a small scheduler. Nothing wrong with that and you learn a lot from that too.

I put that fine line somewhere at the axis of 40Mhz, Ethernet, touchscreen, printing, more than one programmer. If any of these is present, I would go for an RTOS.

Agreed with the first two, maybe three. But more than one programmer is IMHO not a requirement for a RTOS but for configuration management, using good tools and communication between the programmers can solve that easily. You can even let each programmer work on seperate branches and integrate as a final task for a single person.

RAM is a big constraint though, I would myself use RTOS on devices >= 32 kB RAM not less, but it is an arbitrary line and depends on what has to be done.

[Kremmen]

[...]
RAM is a big constraint though, I would myself use RTOS on devices >= 32 kB RAM not less, but it is an arbitrary line and depends on what has to be done.

I won't argue against that but let me offer a datapoint: A lowly Mega328 with just 2kB of RAM will do 4 simple tasks and 3-4 queues on FreeRTOS with no issues whatever. Sure, the task stacks were relatively tight but not unresonably so, and the queues were only supposed to handle a few simple messages at a time. Still the system hums along rock solid. Some care is advisable to predict the stack depth based on local variables and control nesting but that is doable (or traceable at least) if only you avoid purposeful deep recursion algorithms.

[nctnico]

All an interrupt should do is respond to the input stimulus and deposit the corresponding event in a queue/mailbox, so that a task can act on it.

Which is great way to spend a lot more time context-switching than you would have if you had a slightly more complex ISR.  Complex ISRs interfere with "real time" latency, but not with the amount of overall processing that needs to happen. 

It isn't just about speed. It is also about the ability to:

• mentally think through what is and isn't going to happen when an interrupt occurs
• tracably mapping the higher-level application models and abstractions into code
• simulating application and operation in a hosted environment before the hardware and device drivers are available
• easy non-intrusive instrumentation, logging and debugging of the application running in a live system
• instrumentation: monitor the queue lengths
• logging: keep record of key bits of messages put and taken from queues
• debugging: display and/or halt when messages put and taken from queues

All that is a damn sight more difficult if the ISRs can contain arbitrarily complex code with arbitrarily complex coupling with other system components.

Since interrupts are nothing more than asynchronous processes debugging them is just as easy. See interrupts as seperate processes and all the problems you describe go away.

I see many programmers go through this cycle:
- make simple programs
- make more complex programs
- divide programs into many seperate parallel processes and chase race conditions forever
- go back to single threaded programs because they are easier to debug & maintain

@Kremmen: Linux in a realtime environment: been there, done that. With Linux it is pretty easy to make a user application wait until a hardware interrupt occurs. You can make a device driver between hardware and a user application extremely thin.

[Simon]

Right so let me get this bit straight, is an RTOS more useful when you need human interaction and need that to be real time to humans or does an RTOS make sense for applications where there is virtually no human interaction but it needs to be rock solid and easy to develop a large system.

As an example my last project (well current) is to control a motor, I have a speed i want it to achieve and maintain with varying loads and i have a tacho output from the motor. So my program structure involves 2 interrupts. I have the chip running on 8MHz and I have one of the counters running at 1MHz and firing an interrupt every 50 counts and counting up a variable up so that I have a "clock" that ticks every 50uS. So every time a tacho signal is received it looks up the current "time" and stores it, so I have 2 variables storing tacho "times" and at each time the tacho interrupt fires I shift the current value into a "last time" variable and store the new value in the current one so that at any time i can with a separate function called from my main program loop do the math to work out the time between pulses and deduce motor speed and decide what to do about it.

Does an application like this benefit from an OS of any sort or am i already doing the best I can do ?

unless i can find an ARM based chip that will run at low and high temperatures (125+C) I'm stuck with something like atmels AVR32 which has only one part that is automotive rated.

[nctnico]

I'd put all the code for controlling the speed inside the timer interrupt. In that case there is only one variable that needs to be transferred from one process to another: the required speed. If you put that variable in an integer (declare it volatile just to make sure) which is equal to the size of the registers of the CPU then you don't even need to complicate things with using a mutex. This way your project is a no-brainer.

[Simon]

Well either way I need to share data between interrupts and I have 100-400 instruction cycles between each tick of my clock, during that time my tacho will also go off so I've tried to keep as much code as possible out of the interrupts.

[tggzzz]

Right so let me get this bit straight, is an RTOS more useful when you need human interaction and need that to be real time to humans

No, although that is a perfectly reasonable application domain for an RTOS.

or does an RTOS make sense for applications where there is virtually no human interaction but it needs to be rock solid and easy to develop a large system.

Yes, but there are many other perfectly reasonable application domains for an RTOS.

As an example my last project (well current) is to control a motor, I have a speed i want it to achieve and maintain with varying loads and i have a tacho output from the motor. So my program structure involves 2 interrupts. I have the chip running on 8MHz and I have one of the counters running at 1MHz and firing an interrupt every 50 counts and counting up a variable up so that I have a "clock" that ticks every 50uS.

Pet peeve: do you really mean microSiemens, or informally microSamples? I suspect you mean "us".

So every time a tacho signal is received it looks up the current "time" and stores it, so I have 2 variables storing tacho "times" and at each time the tacho interrupt fires I shift the current value into a "last time" variable and store the new value in the current one so that at any time i can with a separate function called from my main program loop do the math to work out the time between pulses and deduce motor speed and decide what to do about it.

Does an application like this benefit from an OS of any sort or am i already doing the best I can do ?

If that is the entire specification and your solution is sufficient, then the added complexity of an RTOS would not have a benefit. OTOH, if you also have to receive commands and report status to another system, then an RTOS might just help. In general any system which has multiple activities that are asynchronous w.r.t. each other is a candidate for an RTOS.

Fundamentally, you need to define the pain points in your current (and, if relevant, future) solution. Then consider whether an RTOS might be able to help.

One non-functional pain point might be that complex communication libraries and/or device drivers are available, but cannot easily be merged with your current application structure. Another pain point might be debugging, logging and monitoring - see my earlier post.

[nctnico]

Well either way I need to share data between interrupts and I have 100-400 instruction cycles between each tick of my clock, during that time my tacho will also go off so I've tried to keep as much code as possible out of the interrupts.

The problem with that method is that it won't work. You only have X time and you can only do one thing at a time. Giving more priority to one process automatically means you are eating time away from another process. I think a different approach is better for what you try to achieve:
1) use a timer capture interrupt when the tacho signal 'hits' and process the result in an interrupt
2) use interrupts based on the tacho signal and calculate the time between interrupts with a free running timer

I think 1 is better because it relaxes the latency between the tacho signal and the actual processing. The actual measurement is done in hardware. And remember: life really gets a lot easier if you let go of the 'interrupt handlers should be short' dogma. If you transfer the events to your main loop then the main loop which probably also does some housekeeping must be fast as well; the entire software becomes time critical.

[Jeroen3]

one part that is automotive rated

Does the software need to be automotive as well? If so, you're probably entering a world of certifications if you want an OS. Even worse when you prepend RT.

1) use a timer capture interrupt when the tacho signal 'hits' and process the result in an interrupt
2) use interrupts based on the tacho signal and calculate the time between interrupts with a free running timer

3) sample the tacho signal with at least twice the maximum tacho speed and derive the time from the buffer once every x samples. Fully dma-ed until dma-finish event, which will go into an interrupt or an rtos event queue.

Notice both method 1 and 2 require approximately equal time in interrupt state. Unless the timer has a buffered capture.
- Interrupt prologue
- Validate if timer value is within acceptable range.
- Put a timer value into a filter.
- Interrupt epilogue

An os is only useful with option 3, or with the further processing. option 1 and 2 are all interrupts, and operating systems tend not to interfere between them on small embedded systems. However, you can use the os the schedule the interrupt to a better time. If you want it to. For example, I don't care if the RTC alarm is a second later, but I do care if the motor current overload interrupt triggers.

[Kremmen]

Right so let me get this bit straight, is an RTOS more useful when you need human interaction and need that to be real time to humans or does an RTOS make sense for applications where there is virtually no human interaction but it needs to be rock solid and easy to develop a large system.

An OS lets you (for example) isolate human interaction into a single task hygienically separated from the rest of the system. That task then communicates with other tasks depending on what needs to happen based on human input.
But equally a completely automated solution benefits from an OS because a human is only an input/output "device" same as any nonliving actor. The key is that you identify the activities of the application and the channels of comunication they need agaist each other. In this kind of thinking the point is to largely avoid global variables that only create access conflicts.

As an example my last project (well current) is to control a motor, I have a speed i want it to achieve and maintain with varying loads and i have a tacho output from the motor. So my program structure involves 2 interrupts. I have the chip running on 8MHz and I have one of the counters running at 1MHz and firing an interrupt every 50 counts and counting up a variable up so that I have a "clock" that ticks every 50uS. So every time a tacho signal is received it looks up the current "time" and stores it, so I have 2 variables storing tacho "times" and at each time the tacho interrupt fires I shift the current value into a "last time" variable and store the new value in the current one so that at any time i can with a separate function called from my main program loop do the math to work out the time between pulses and deduce motor speed and decide what to do about it.

OK, just some quick thoughts, your mileage may vary.
1. Get rid of the timer interrupt in this form. Do the counting in a hardware counter and only interupt on overflow. Maintain overflow count in SW but the rest of the count in HW that you read only when you actually need the count.
2. You only need the tacho count when you are going to also do something about it. So in principle you should decide on the speed controller cycle time and get your input in sync with that cycle. Anything faster is busy work that gets you nowhere.

I don't wish to design this thing for you but assuming you have a regular PID type speed controller, then this task is reduced to something like this:
- The RTOS scheduler clock is a natural base for the controller cycle time. At least in FreeRTOS you can hook up a tick procedure to run at every scheduler tick regardless of what task is otherwise selected to run. The tick procedure is a natural place to put your PID controller(s) so they run once every tick without exception. Thus your controller cycle time is the same as your OS tick time.
- set up one HW counter to be your timebase for the speed measurement. That counter can increment _real_fast_ to provide good time resolution (in a recent rev counter project i had the timebase at 50 ns, i.e. counting the 20MHz xtal straight). Use counter overflow interrupts only to update a RAM variable to maintain the high word of the count when tacho speed is slow. The low word count is incremented in HW directly.
- tacho pulses you can either count in SW or HW depending on the max pulse frequency and what HW you have available (some AVRs have HW event pipelines and DMA channels that could dramatically speed up processing by delegating stuff to HW). Also some MCUs such as Atmel XMega have a quadrature encoder input built in. You can decrease the interupt load by reading the counts mainly synced to the scheduler ticks but also by interrupting on a tacho pulse and only then reading the timebase counter. There are various ways to do it and to trade off processor load to accuracy or the other way around.
So you will be using interrupts, OS or no OS, but the usage will perhaps be a bit more coordinated and definitely supported by the OS if you know how to do it "right".

Does an application like this benefit from an OS of any sort or am i already doing the best I can do ?

I hope you got from the above that the way you do it now is far from optimal whether you have an OS or not. Again it is just me but i would definitely consider one of the OSes i have mentioned.

unless i can find an ARM based chip that will run at low and high temperatures (125+C) I'm stuck with something like atmels AVR32 which has only one part that is automotive rated.

Good news is that an official FreeRTOS port exists for AVR32 MCUs, at least UC3A.

[Kjelt]

I won't argue against that but let me offer a datapoint: A lowly Mega328 with just 2kB of RAM will do 4 simple tasks and 3-4 queues on FreeRTOS with no issues whatever.

wow, ok I stand corrected then, I never imagined it working properly with those low resources.

[Kjelt]

unless i can find an ARM based chip that will run at low and high temperatures (125+C)

STM32L051C8 and STM32L053R8 have an operating temp of -40^oC to +125^oC but they are cortex M0, still could do the job,

[dannyf]

I never imagined it working properly with those low resources.

It depends on what you mean by "OS" - the simplest would be a switch-case statement.

I think there exists an OS for PIC16 chips - published by Microchip?

[Kjelt]

It depends on what you mean by "OS" - the simplest would be a switch-case statement.

He said "FreeRTOS" not a simple scheduler 

[Kremmen]

I won't argue against that but let me offer a datapoint: A lowly Mega328 with just 2kB of RAM will do 4 simple tasks and 3-4 queues on FreeRTOS with no issues whatever.

wow, ok I stand corrected then, I never imagined it working properly with those low resources.

Info on FreeRTOS resource consumption as well as other FAQs here: http://www.freertos.org/FAQ.html

[...]
It depends on what you mean by "OS" - the simplest would be a switch-case statement.

Well, call it a microkernel then if OS is too grand a word... Scheduling and intertask comms is the point however.
A switch case is not a scheduler because it all runs in one context with no concept of priority or other scheduling rules/methods.

[dannyf]

He said "FreeRTOS" not a simple scheduler 

That's probably dicey -> most due to its ram space. You probably don't have much mips left, either.

[Kremmen]

He said "FreeRTOS" not a simple scheduler 

That's probably dicey -> most due to its ram space. You probably don't have much mips left, either.

Just read the link i gave and think again.
At the risk of becoming labeled as a RTOS fanboy, let me ask: how come not much mips left? Where would they go then?
Seriously - this is one of the most typical gripes coming from those who are not really in the loop. I'm not saying you aren't, this is a generic observation. What these guys fail to get is that one way or the other you end up doing the same things anyway. In specific cases hand coding may result in somewhat faster or otherwise optimized code but generally there is no penalty and more often than not the benefit goes to the OS. A RTOS is not the end-all of program control but neither is it a black hole sucking all available resources. Like fire, it is a good servant but you don't want it to be your master. So use it where it makes sense and skip it were it doesn't. When exactly that is depends on what you want of it.
OS newbies should use it in a non demanding test case whether a toy or a real application, to get the hang of it and get first hand experience of the strengths and weaknesses of each particular product.
@Simon: if you decide to give it a try, you won't find yourself alone. Plenty of people able to lend a hand here & elsewhere.

[eurofox]

He said "FreeRTOS" not a simple scheduler 

That's probably dicey -> most due to its ram space. You probably don't have much mips left, either.

Just read the link i gave and think again.
At the risk of becoming labeled as a RTOS fanboy, let me ask: how come not much mips left? Where would they go then?
Seriously - this is one of the most typical gripes coming from those who are not really in the loop. I'm not saying you aren't, this is a generic observation. What these guys fail to get is that one way or the other you end up doing the same things anyway. In specific cases hand coding may result in somewhat faster or otherwise optimized code but generally there is no penalty and more often than not the benefit goes to the OS. A RTOS is not the end-all of program control but neither is it a black hole sucking all available resources. Like fire, it is a good servant but you don't want it to be your master. So use it where it makes sense and skip it were it doesn't. When exactly that is depends on what you want of it.
OS newbies should use it in a non demanding test case whether a toy or a real application, to get the hang of it and get first hand experience of the strengths and weaknesses of each particular product.
@Simon: if you decide to give it a try, you won't find yourself alone. Plenty of people able to lend a hand here & elsewhere.

I fully agree and add a few points:

1) Most programs in a CPU from 8 bits to 32 bits CPU/Applications spend time waiting, looping but not really doing something useful unless you and a lot of math or other very demanding process power.

2) It is wrong to think that a RTOS is taking most on the CPU resources unless it is very badly coded

3) When people start writing interrupt routines to create tasks and checking in the main loop the status of the task they already duplicate one of the features of an RTOS, all those features are build in a ways it is strutured and easy to manage if you understand how it work

4) Again since I aleady write it for a simple application you don't need an RTOS but as soon task need to run in the background it will make the code better and more transparent to develop and maintain

eurofox

[dannyf]

how come not much mips left? Where would they go then?

To the overhead? task switching? mailbox management? ....

A simple way to test it would be if you open up 10 identical jobs blinking an led, compare that vs. blinking an led without OS.

The difference goes to the RTOS.

[tggzzz]

An OS lets you (for example) isolate human interaction into a single task hygienically separated from the rest of the system. That task then communicates with other tasks depending on what needs to happen based on human input.
But equally a completely automated solution benefits from an OS because a human is only an input/output "device" same as any nonliving actor. The key is that you identify the activities of the application and the channels of comunication they need agaist each other. In this kind of thinking the point is to largely avoid global variables that only create access conflicts.

Precisely.

This kind of issue has been around for over half a century, and many useful and practical techniques have evolved. I  hope the OP has time and inclination to read and understand such realtime "design patterns". (Yes, that's a suitable search term!)

If the OP has neither time nor inclination then posts on this forum won't help.

[Kjelt]

To the overhead? task switching? mailbox management? ....
A simple way to test it would be if you open up 10 identical jobs blinking an led, compare that vs. blinking an led without OS.
The difference goes to the RTOS.

There is little to no difference if your blinkrate is a multiple of a ms (usual RTOS timetick).

[dannyf]

That's the time slot allotted to each task. If the N tasks are blinking the same LED, over a given period of time, the numbers of times the LED is blinked in a naked environment vs. the RTOS environment would tell you the cost of the RTOS.

[dannyf]

would tell you the cost of the RTOS.

More precisely, it would tell you the lower bound of the RTOS cost -> such a simple set-up does not need information to be transmitted from one task to another. Costs associated with messaging / mailbox management would not be reflected in this test.
Only task switching is.