Author Topic: FreeRTOS or other OSes for MCU, practicalities of it  (Read 18723 times)

0 Members and 1 Guest are viewing this topic.

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17814
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
FreeRTOS or other OSes for MCU, practicalities of it
« on: September 15, 2014, 08:27:22 am »
I'm looking to use larger MCU's for speed mainly. As projects get more complex I am wondering if some sort of operating system will help, maybe freeRTOS ? basically my question is what does the OS do, does it help setup the chip or would it be a peice of code that runs alongside mine and manages the timing of it ?

Basically what OSes should I consider and will they give me any simplicity in my projects ?
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19494
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #1 on: September 15, 2014, 10:17:12 am »
I'm looking to use larger MCU's for speed mainly. As projects get more complex I am wondering if some sort of operating system will help, maybe freeRTOS ? basically my question is what does the OS do, does it help setup the chip or would it be a peice of code that runs alongside mine and manages the timing of it ?
Those questions will be answered in general by reading any standard introductory text (on a manufacturer's website or a magazine/web article) about RTOSs. For individual RTOSs, you will have to RTFM.

It will be easy to determine whether a specific CPU/MCU is supported; if so I would expect it to configure the memory, timers, and other low-level hardware. But a CPU/MCU is only part of a system.

Questions that you might like to focus on:
  • does the RTOS support the peripherals in your hardware; e.g. having "ethernet support" is insufficient since you also need drivers that support the particular ethernet chip/core
  • characterise your application in terms of how many tasks/activities are asynchronous w.r.t. each other, and any necessary synchronisation between tasks/activities
  • characterise your applications computational and i/o timing constraints
If you can't do that then you are not in a position to use an RTOS.

Given time and the ability to learn through experience, you might like to implement your project, and then reflect on the pain points. Then use 20:20 hindsight to assess whether what features of an RTOS might lessen the pain next time around.

Quote
Basically what OSes should I consider and will they give me any simplicity in my projects ?
They will simplify some aspects of your code at the expense of complicating others; typically small simple projects will not benefit. Where the tradeoffs lie will depend on your application, your hardware, and your experience; a general answer is not possible.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17814
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #2 on: September 15, 2014, 10:38:26 am »
I've been reading the FreeRTOS website and not got far as it talks a lot about the code used in the RTOS and how it works in itself but nothing about how it interacts with my code and hardware which is what I'm trying to understand. I'll keep digging around.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19494
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #3 on: September 15, 2014, 11:19:17 am »
I've been reading the FreeRTOS website and not got far as it talks a lot about the code used in the RTOS and how it works in itself but nothing about how it interacts with my code and hardware which is what I'm trying to understand. I'll keep digging around.
That website assumes you know what an RTOS is. It states its features and presumes you can understand them in terms of standard RTOS terminology, operation and use.

That's quite reasonable, but you want/need an "RTOS for dummies" intro. ( Sorry, I don't have time to find one for you now.) You wil best be able to learn from such an article if you have an understanding of the pain points in systems without an RTOS - and hence what RTOSs do and don't do.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6460
  • Country: nl
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #4 on: September 15, 2014, 11:30:32 am »
HW eng. going SW, I do encourage the effort but tggzz is right you need to start with reading first, you also do not ask a question on this forum about a specific chip without at least having read its datasheet now do you?  ;)

http://en.wikipedia.org/wiki/Real-time_operating_system

 


Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17814
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #6 on: September 15, 2014, 11:40:37 am »
I think I was relatively clear that I'm not expecting to implement an RTOS in a project tomorrow and that I'm just looking about at the minute trying to understand implications and if i should really use one. Thank you for your suggestions, I was starting to wonder if there was something I was missing as the FreeRTOS website does seem to go over my head, I'll step back and start again.
 

Offline eurofox

  • Supporter
  • ****
  • Posts: 873
  • Country: be
    • Music
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #7 on: September 15, 2014, 11:55:41 am »
I think I was relatively clear that I'm not expecting to implement an RTOS in a project tomorrow and that I'm just looking about at the minute trying to understand implications and if i should really use one. Thank you for your suggestions, I was starting to wonder if there was something I was missing as the FreeRTOS website does seem to go over my head, I'll step back and start again.

Simon,

I wrote from scratch an RTOS in assembly long time ago when this kind of tool was not available.

When you have an application where you can manage all control in one main loop (all inputs and outputs) you don't need an RTOS and sometimes help with interrupts

When you program start to be to complicated and that you need to manage several task in background then you better use an RTOS
eurofox
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #8 on: September 15, 2014, 01:15:37 pm »
I never used an OS on a microcontroller. I did look into it but when running several tasks in parallel using timeslicing causes all kinds of thread synchronisation issues for shared data. Those are difficult to control without planning an application properly.

I usually run high priority processes from a timer or hardware interrupt. An interrupt does more or less the same (save the state and go to a different process) as when an OS halts a process and hands over the next timeslice to a different process.

Many realtime OSses can be configured to do scheduling which means running a process until it decides it no longer needs the CPU. This makes it easier to do thread synchronisation for shared data but it still needs attention. So far calling a run function from a loop in main for each software module has served me well. The only time I could have used an OS was when a particular calculation too long and I was not able to divert some of the CPU load into an interrupt.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17814
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #9 on: September 15, 2014, 01:19:16 pm »
My thinking is sort of along the same lines
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #10 on: September 15, 2014, 02:29:43 pm »
me, too  :D
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6460
  • Country: nl
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #11 on: September 15, 2014, 03:03:28 pm »
If you have only a few simple tasks or a slow microcontroller (8 bits) you can use a superloop and ISRs.
If you have a powerfull 32 bits microcontroller that has a lot of tasks or apps to run and some can take a long time to run an RTOS is the (only) smart way to go.
All in between suit yourself.
I personally think it is a waste if you are using fast 32 bit microcontrollers and do not (want to) know about RTOSs.
We have a saying here in the Netherlands: "a farmer won't eat anything he does not know", so at least take some good bites of it and see how it tastes.
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 8643
  • Country: gb
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #12 on: September 15, 2014, 03:04:55 pm »
Go for the clear market leader - NoOS!
 

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17814
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #13 on: September 15, 2014, 03:08:23 pm »
Go for the clear market leader - NoOS!

haha, well at the moment that seems best but there may come a time.
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6720
  • Country: nl
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #14 on: September 15, 2014, 03:14:21 pm »
The OS probably won't help much, the code to access the peripherals might if it's good quality.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19494
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #15 on: September 15, 2014, 03:47:43 pm »
I never used an OS on a microcontroller. I did look into it but when running several tasks in parallel using timeslicing causes all kinds of thread synchronisation issues for shared data. Those are difficult to control without planning an application properly.
An RTOS will be of zero help there, and at best might allow you to believe the problems have gone away.

A key is to get the very high level application structure stable and predictable. There are many real time "design patterns" which have stood the test of time - use them and don't reinvent a (square) wheel.

Good starting points are to consider
  • all inputs as discrete events,
  • inter-task communication consisting of one task depositing a discrete message in a queue (with capacity=1 is called a mailbox), and another task (or tasks) pulling messages from the queue as they become available
  • each task takes an event from a queue/mailbox, processes it, then goes back to sleep until there is another event in the queue
  • when the RTOS detects a queue/mailbox contains an event then it schedules the task waiting for the event
Quote
I usually run high priority processes from a timer or hardware interrupt. An interrupt does more or less the same (save the state and go to a different process) as when an OS halts a process and hands over the next timeslice to a different process.

Rule of thumb: if correct (albeit untimely) behaviour depends on high/low priorities, then there's almost certainly a problem lurking and waiting to be discovered. Beware "priority inversion" e.g. http://en.wikipedia.org/wiki/Mars_Pathfinder#On-board_computer

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.

Quote
Many realtime OSses can be configured to do scheduling which means running a process until it decides it no longer needs the CPU. This makes it easier to do thread synchronisation for shared data but it still needs attention. So far calling a run function from a loop in main for each software module has served me well. The only time I could have used an OS was when a particular calculation too long and I was not able to divert some of the CPU load into an interrupt.
Too simplisitic. You need to understand the relative advantages of cooperative multitasking and preemptive multitasking.

Curiously hardware bods are usually in a better position to "think in parallel" than traditional software weenies.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4078
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #16 on: September 15, 2014, 04:51:06 pm »
An operating system might help modularise your application. However, the lines between the modules become more complex.

It's quite easy to share a GUI task from a control loop task since they only produce and consume data one way relative to each other.
But, what happens when you want both tasks to write data to the serial bus?

In general, using an os with plenty of time in idle-loop is not that hard, but whenever a task requires (or is able to consume) more than 100% of the assigned cpu time, your software design, priorities and preemption are all that sit between hanging and running. Here is were the RT (realtime) part of an RTOS moves in.
With an RTOS you are able to guarantee (by design) that an action will be performed at least x time from the event. Such as:
- An ADC conversion event will be given to the DSP task who will complete calculations within time for the output stage to react.
- A user input event will reach the GUI task within a second.
- A pin interrupt event (which are usually of the utmost importance) will be given to the safety task the at the next schedule or immediately if preemption is allowed.

For example, in your average threaded blinky example. Replace in one of the threads the "sleep" function for a for-loop delay and increase the priority with 1.
 

Offline Kremmen

  • Super Contributor
  • ***
  • Posts: 1289
  • Country: fi
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #17 on: September 15, 2014, 05:38:34 pm »
I'm looking to use larger MCU's for speed mainly. As projects get more complex I am wondering if some sort of operating system will help, maybe freeRTOS ? basically my question is what does the OS do, does it help setup the chip or would it be a peice of code that runs alongside mine and manages the timing of it ?
Some OSes will include a HAL (Hardware Abstraction Layer). ChibiOS is one. They will help you operate some or all of the MCU peripherals as abstract entities on the OS level without messing with the actual iron.
As to timing, all RTOSes have some kinds of timing functions, at least various non-busy waits.
The OS code does not really "run alongside" your code, instead the OS provides a library of functions managing creation and manipulation of what is usually called tasks, and communication between those tasks. Simple as it sounds, it is a very powerful concept when done properly.
Basically your code is divided into tasks, each one handling a specific feature or function of the application Thus there might be input and output tasks, a user interface task, various communication tasks to connect the application to the outside world, and signal processing tasks doing the number crunching or similar stuff. All of these tasks need to exchange information with each other and sometimes control the execution of things by putting tasks to sleep or waking them up. For this purpose all OSes implement a set of intertask communication methods such as queues, semaphores and mutexes and there are others.
A decent RTOS will also definitely include interrupts in the supported features such that communication from interrupt context to the scheduler is possible. A scheduler is the "core" of the RTOS, and it is the scheduler that grabs control from an executing task, switches the processor context to some other task and restarts (or continues) that task from where it left off last time. As a rule control is given to the highest priority non-blocked task or, if there are multiple such tasks then they are alternated round robin or some other "fair" priority rule.
The context switch can be either cooperative or pre-emptive. In the first case a task must explicitly yield either directly or by issuing an OS call that results in a context switch. A pre-emptive scheduler has a master clock ticking at a predetermined rate. Each tick wakes the scheduler that will then switch context all by itself if the switching conditions are met.

The end result is that you implement the app as a set of procedures that become the tasks under the OS once they have been "created". Usually you also create a set of OS queues and hand them to the tasks so they can talk to each other. Upon task creation (usually but not necessarily in the main program) the OS core allocates a stack for each task an initializes that stack (creates the initial running context in that stack). This way the tasks are allocated one by one and when the scheduler is started it switches the running context to the first task and the application proper starts from there.
Additionally, OSes always have functions to allocate and free dynamic memory (yes yes, but let's not go there). Some understand about memory protection and so on and so on.
While you can get a long way with the NoOS option, getting to know at least one common RTOS is decidedly a clever move if you ask me. Basic usage is if not trivial then entirely easy and produces predictable results as long as certain minimum sanity measures are kept in place (stack size for tasks and similar)
Quote
Basically what OSes should I consider and will they give me any simplicity in my projects ?
FreeRTOS and/or ChibiOS. There is a learning curve (reasonable). The code complexity and size will start at some nonzero level but the growth rate will be slower than for the NoOS option. In the end yes, they do give you simplicity but not at the trivial low end. The blink-a-led app won't get that much from an OS.
« Last Edit: September 15, 2014, 05:45:19 pm by Kremmen »
Nothing sings like a kilovolt.
Dr W. Bishop
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #18 on: September 15, 2014, 05:50:17 pm »
@Kremmen: if I want all that I use an embedded Linux board.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4078
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #19 on: September 15, 2014, 08:52:36 pm »
I'm not familiar with freertos (due to it being free with *'s).
But I have with ChibiOS. Which is a quality piece of C code. It's hard to follow at first, because of the highly portable and objectified implementation. And the inheritance method it's using. Yes, class inheritance in C. A real challenge for your IDE to follow as well.
But when you're used to the style used, it is a high quality versatile tool to put in your toolbox. And your inspiration box.
Note that you're not obligated to use the HAL (hardware drivers). You can work with only the kernel.

Our university let us play with lubuntu, threading ,forking and semaphore stuff etc.. and "nice" values. Which is difficult at first, but essential to know.
Oh, and never go Dining with Philosophers.  ;)

Please also note that an RTOS isn't by default realtime. You're design must provide this, the OS is just the tool.
« Last Edit: September 15, 2014, 08:57:01 pm by Jeroen3 »
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7377
  • Country: nl
  • Current job: ATEX product design
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #20 on: September 15, 2014, 09:55:04 pm »
I really suggest, if you really want to work with RTOSes, than cook your own RTOS. It is really not that much science. Just take the features that you want. Code them or use someones code snippets. You are done, it can take maybe a few weeks. But if you spend that time writing the scheduler, the messaging system, the memory allocation, the hardware allocation, starting tasks, making coherent memory... You will understand it.
Without it, you will be like the newbee standing in front of a power supply, not understanding how it works. "But I always use batteries, they work fine". Sure.
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #21 on: September 15, 2014, 10:35:44 pm »
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.)

For basics OS principles, there are lots of books and classes. and stuff.   There are fewer specifically aimed at small microcontroller RTOSes (other than those aimed at specific implementations.  I have a big set of Micrium uC/OS books that were given away (previous edition/version?) at a trade show a few years ago.  It was claimed to be meant as coursework as well as describing the specific OS.  (Um... http://www.amazon.com/MicroC-OS-II-Kernel-CD-ROM/dp/1578201039/ref=la_B001ITVJ02_1_1?s=books&ie=UTF8&qid=1410820124&sr=1-1 )

Quote
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.  Which is one of the reasons that paying too much attention to "real time" may be a mistake for many systems.  (I remember when BBN proudly announced that their Butteryfly packet switch could guarantee packet switching in less than 1ms.  At the time, we were switching more than 10000pps, and I was very unimpressed.  It wasn't until later that I understood that we were FAR away from guaranteeing ANY maximum switching time.  (and others; someone got a thesis out of measuring/analyzing the variance.)  (and guess which method, "fast" or "guaranteed", turned out to be a more useful/profitable product.)
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19494
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #22 on: September 15, 2014, 11:30:15 pm »
Quote
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.

But hey, if the code doesn't have to be correct then it is trivial to make it arbirtarily fast.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #23 on: September 16, 2014, 02:22:34 am »
[...] if you really want to work with RTOSes, than cook your own RTOS. It is really not that much science. Just take the features that you want. Code them or use someones code snippets. You are done, it can take maybe a few weeks. But if you spend that time writing the scheduler, the messaging system, the memory allocation, the hardware allocation, starting tasks, making coherent memory... You will understand it.
Uh, I'll take the other side of that argument. The problem with rolling your own RTOS is that you may end up with something that works on simple examples, but contains bugs that cause more complicated things to fail. Writing code against a known working RTOS (e.g., ChibiOS) is a great way to learn how they're supposed to work without hitting a brick wall of debugging too early.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: FreeRTOS or other OSes for MCU, practicalities of it
« Reply #24 on: September 16, 2014, 04:19:45 am »
Writing your own primitive OS is a great way to learn more about them (and get an appreciation of how much overhead is involved) (and how much work they are to write/debug.)  After you've gotten somewhere, you'll certainly be able to have a better idea how to evaluate commercial or OSSW offerings.

Some operating systems are essentially just kernels, around which you have to build nearly everything.  Other OSs feature standard drivers for popular peripherals and major features (TCP/IP, USB, Displays, graphics, etc)...
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf