RTOS Examples

[BlogRahul]

I am trying to find some real use case for RTOS. Blinky LED's is not a RTOS application and does not require an RTOS. What are the good learning examples of RTOS that really require RTOS. 

[nctnico]

I am trying to find some real use case for RTOS. Blinky LED's is not a RTOS application and does not require an RTOS. What are the good learning examples of RTOS that really require RTOS.

I beg to differ.  Seriously: create an application with 3 threads that each blink a LED. Start simple and go from there.

[westfw]

In theory, I can make a SAMD21 (Seeed Xiao or Adafruit QT Pi, etc) into a three-port USB-Serial converter.The code would be a lot easier/simpler with an RTOS (not counting the RTOS itself, of course.)For each port, one task would read from Serial and Write to USB, and one task would read from USB and write to Serial.  Three ports, six (rather trivial) tasks.  Piece of cake (aside from the fact that many RTOSes probably don't have very good USB support...)


Another example would be to add a "debug command processor" to any program.  Open an extra USB CDC channel and process commands to look at the status of whatever else is going on.  Or use the serial port.  I have this implemented using careful mostly-nonblocking code (dump the peripheral register content, look at memory, etc); it would be trivial and less invasive on top of a RTOS (non-blocking output to a CLI channel is pretty annoying to do manually.)

Implement multiple servos or stepper motors, each with speed control.  (Stepper 1 moves at 10 steps per second, Servo 0 goes from 0 to 45 degrees in 10 steps over 1 second, etc.)

Go ahead and implement that 80s-like computer that runs a BASIC interpreter while bit-banging a video display and PS/2 keyboard.  Driving the video is probably closer to "real time" than most examples.  Video at highest priority, keyboard next, actually interpreting the BASIC program last.

[rstofer]

One of the advantages of RTOS projects is the way in which tasks interact. Each major component of a project can be written as a separate, standalone, task that runs from time to time.  There is no complex logic as might be required in a super-loop approach.  Communications between tasks is handled in a standardized and predictable way.  Entire tasks can be added/removed/changed without the other tasks being affected.

Tasks can wait for things to happen.  They don't consume compute cycles testing for input that may never come, they simply get scheduled when something is posted to a semaphore or queue.

None of this stuff actually requires 'real-time' but if you extend it to the flight controls of an F-22, things get real interesting, real quick.  The plane is inherently unstable and the flight controls make it flyable.

Given some kind of memory management, the code to respond to an event doesn't even need to be resident in memory.  Loading the code impacts latency and some tasks are more urgent than others.

There's no point in dealing with incoming characters, other than to put them in a queue, until a message is known to be complete.  Maybe the interrupt routine puts characters in a queue and sets the 'message received' semaphore when it sees carriage return.  If it's not done this way, handling a console can get complex.  And you still need a queue...

One of the nice things about ST's STM32CubeIDE is that it will emit code to create a FreeRTOS framework.  Most of the heavy lifting is done by auto-magic and all the user has to do is create the tasks and link them in.

There's no absolute reason an RTOS needs to be used as long as there is some concept of scheduling in some kind of priority order with some scheme for message handling.  But that's exactly what an RTOS does!

[rstofer]

The 3 blinking LED example with different periods is really a good idea.  Expand it such that the frequency is changed with each push of a button.  Maybe implement an interrupt for the button, post to a semaphore from the interrupt routine and then, when it is time for a particular LED task to run, look at the semaphore and adjust the period for this and subsequent blinks of that LED.  On the next operation of the button, revert to the original timing.

Meanwhile, the other 2 LEDs are merrily blinking along.

Something like that...

It serves no good purpose whatsoever except for creating and scheduling 3 tasks, getting a button interrupt to operate and working with a semaphore and an RTOS.  Although, a dual rate LED might be a handy error indicator...

Of course this stuff can be done in a super loop.  It has been for decades.  But using an RTOS is easier and the code is a lot cleaner.

[tggzzz]

I'd take it one stage further...

Three blinking LEDs, each at a different rate.
The rate of each light can be changed at any time by an operator issuing a text command over whatever comms channel is available, e.g. USB, ethernet, etc.
Record the instant at which each LED is turned on/off, transmit that to a host PC, to verify that the periods are indeed unaffected by communicating with the PC/operator under all circumstances.

That could be done by one task per LED, one task for comms, and one task to tie the other tasks together.

It could, of course, be done other ways (e.g. an enormous switch(){} statement in a mainloop), but it will be more difficult to convince someone else that it will work correctly in all circumstances.

[NorthGuy]

It could, of course, be done other ways (e.g. an enormous switch(){} statement in a mainloop), but it will be more difficult to convince someone else that it will work correctly in all circumstances.

Sure. Without RTOS, LED blinking code would be a mess - something like this

Code: [Select]

typedef struct {
  uint32_t timer;
  uint32_t half_period;
  reg_t mask;
  volatile reg_t *reg;
} led_t;

led_t leds[NUMBER_OF_LEDS];

void init_led(int idx, volatile reg_t *reg, reg_t mask) {
  led_t *led = leds + idx;
  led->reg = reg;
  led->mask = mask;
  led->timer = led->half_period = 0;
}

void set_led_half_period(int idx, uint32_t half_period) {
  leds[idx].half_period = half_period;
}

void process_leds_within_the_timer_interrupt() {
  led_t *led = leds;
  for (int i = 0; i < NUMBER_OF_LEDS; i++, led++) {
    if (led->half_period == 0) continue;
    if (--led->timer) continue;
    led->timer = led->half_period;
    *led->reg ^= led->mask;
  }
}
or even worse.

[SiliconWizard]

Fun.

While some reasonable points have been raised in this thread, I haven't really seen any straight answer to the OP's question, about "real applications" for an RTOS, instead of just learning exercises. It's fun to see people giving more LED blinking examples answering the OP's "I don't care about a blinky LED example".

Of course there's a large number of real applications, but for someone not in the know - or working in some particular fields - those are not necessarily obvious to find. For instance, a search with "FreeRTOS" in github yields a huge number of projects - most of them being forks of FreeRTOS, ports, additional libraries, or very simple example projects...

So yes, rstofer talked about flight controls. Thing is, modern firmware for avionics stuff often uses some kind of OS indeed. Rarely the open-source ones though. Oh, and in that area (avionics/aerospace/...) the use of the Ada language is not uncommon, and Ada has "native" support for multitasking - which means that you're not necessarily using a third-party OS either - you may just be using the task management provided in the language and its runtime (sure you could consider the Ada runtime as an "OS" of some form...)

Applications where you are likely to find open-source RTOSes, in particular stuff like FreeRTOS, are IoT devices. No wonder Amazon is now the active project leader. There's of course a number of benefits of using an RTOS, some of which have been mentioned above by others, but I'm just saying - if you want to know what's the majority of commercial applications using FreeRTOS or equivalent - that will be mostly IoT / "connected" devices. One of the reason is that a number of vendors of RF SoCs -  such as TI I think - have adopted FreeRTOS and provided drivers and ready-to-use modules for it, so developing a "connected" device is much faster this way than going bare metal.

Again, not saying RTOSs do not have uses and benefits outside of this, just that it's likely those are not going to be the same kind of OSs that you are going to use as a hobbyist. Or even as a small company.

[westfw]

Without RTOS, LED blinking code would be a mess

Nah.  Here's an Arduino example I did a long time ago...

Code: [Select]

boolean delay_without_delaying(unsigned long &since, unsigned long time) {
  // return false if we're still "delaying", true if time ms has passed.
  // this should look a lot like "blink without delay"
  unsigned long currentmillis = millis();
  if (currentmillis - since >= time) {
    since = currentmillis;
    return true;
  }
  return false;
}


void loop() {
  static unsigned long ledtime = 0;
  static unsigned long atime, btime, ctime, nltime;
  static int ledstate = false;
  if (delay_without_delaying(ledtime, 500)) {
    ledstate = !ledstate;
    digitalWrite(13, ledstate);
  }
  if (delay_without_delaying(atime, 100)) {
    Serial.print("A");
  }
  if (delay_without_delaying(btime, 200)) {
    Serial.print("B");
  }
  if (delay_without_delaying(ctime, 30)) {
    Serial.print("C");
  }
  if (delay_without_delaying(nltime, 1000)) {
    Serial.print("\n");
  }
}


[westfw]

One of the advantages of RTOS projects is the way in which tasks interact.

That's an interesting perspective.  I would normally feel like the big advantage of an RTOS is the way it can simplify tasks that (mostly) DO NOT interact.  "Timesharing", so to speak.

[tggzzz]

It could, of course, be done other ways (e.g. an enormous switch(){} statement in a mainloop), but it will be more difficult to convince someone else that it will work correctly in all circumstances.

Sure. Without RTOS, LED blinking code would be a mess - something like this

Code: [Select]

typedef struct {
  uint32_t timer;
  uint32_t half_period;
  reg_t mask;
  volatile reg_t *reg;
} led_t;

led_t leds[NUMBER_OF_LEDS];

void init_led(int idx, volatile reg_t *reg, reg_t mask) {
  led_t *led = leds + idx;
  led->reg = reg;
  led->mask = mask;
  led->timer = led->half_period = 0;
}

void set_led_half_period(int idx, uint32_t half_period) {
  leds[idx].half_period = half_period;
}

void process_leds_within_the_timer_interrupt() {
  led_t *led = leds;
  for (int i = 0; i < NUMBER_OF_LEDS; i++, led++) {
    if (led->half_period == 0) continue;
    if (--led->timer) continue;
    led->timer = led->half_period;
    *led->reg ^= led->mask;
  }
}
or even worse.

Now add in the other bits mentioned. Define the strategy that will ensure all timing requirements will be met. Show that the implementation doesn't violate them.

Then add a completely new requirement, e.g. a front panel interface. Rinse and repeat.

N.B. an RTOS can be simple: there is no requirement for it to be a commercial product.

The point about an RTOS is to discipline and structure thinking, design construction and testing.

[Benta]

The central task of an operating system, real-time or not, is managing resources. At its most basic:
- processing power
- memory
- time
- basic I/O
This setup is what some people call a microkernel.
Typical RTOS examples are/were OS-9 (68k), Nucleus, etc.
On top of themicrokernel you can then add drivers, networking, file system etc.
And on top of that are your applications.

UNIX/Linux use a different approach, where everything (networking, drivers, graphics etc.) are all bundled into one big  system called a monolithic kernel. But this is not suitable for real time, as there's no real resource control.

I won't go into Windows, which is basically just a 30-foot container with software pieces accumulated over the last 30+ years.

[Benta]

One of the advantages of RTOS projects is the way in which tasks interact.

That's an interesting perspective.  I would normally feel like the big advantage of an RTOS is the way it can simplify tasks that (mostly) DO NOT interact.  "Timesharing", so to speak.

I'm a hardware guy, but I've worked with RTOS.
The nice thing about an RTOS is, that you can partition a design the same way you'd do it in hardware. When I first got this idea, it made everything immensely easy, and it was a real fun experience.

Think about a design that needs to be split into blocks:
1: an input section where all the pushbuttons are. It's on the front panel left side = separate PCB.
2: indicator lamps, all on the top side of the front panel = separate PCB.
3: interfaces, all on the back of the box = separate PCB.
4: an LCD display on the front panel right side = separate PCB.

Designing each of these in hardware isn't that hard. And defining the wiring between the PCBs is also not that hard.

Same thing with RTOS tasks. Each task is a PCB, and the signalling between tasks is the inter-PCB wiring.

The RTOS takes care of the rest.

[David Hess]

Motion control, especially when the computer system is inside of the feedback loop measuring sensors, calculating, and then adjusting actuators and motor speeds.  A drone application is a good example.

[Siwastaja]

Applications where you are likely to find open-source RTOSes, in particular stuff like FreeRTOS, are IoT devices.

You hit the nail, too  .

Typical to IoT devices is,
* They are developed quickly, by inexperienced enthusiastic folks (nothing wrong with that)
* They use a lot of reused, copypasted, code
* Said reused code is developed as multithreaded, blocking code often originally on desktop/server
* Code is not developed by folks experienced working with microcontrollers, or even know what "interrupt" means. No, they come from a general purpose computing background.
* The results tend to be buggy, but of course have to Just Do The Job somehow in order to sell.
* Total lack of thinking about proving anything, including safety, functionality, or timing

Contrast the IoT gadget with, say, a 3-phase industrial VFD inverter. Latter has to prove safety, functionality, and timing, and does not run an RTOS. IoT gadget does not have to, and it will likely run some kind of OS. "RT" here actually means just lightweight more than realtime.

These projects just need an OS because of how they are developed. And if it's a small cheap microcontroller, it practically can't be linux. It doesn't need to be fully POSIX, but it has to have enough of the familiar interfaces so that porting code is not too big of a task. So it's one of the popular free RTOSes.

There is absolutely nothing wrong with all that. Products are made in quick cycles, they are fun to buy and use, and they make money.

But the contrast is just hilarious because said developers then get on the high horse on the internet and start spewing "oh, we use this thing called RTOS which is what aviation uses and our development patterns make our products super high reliability and good for safety critical applications because that's what RTOS is all about" BS.

And then the story always evolves into how difficult it is to blink LEDs or communicate through UART without RTOS because you have to write a scheduler from scratch and implement mutexes and semaphores and whatnot.

What I personally do (in addition to spewing critique on forums)? Well, I tend to separate the computing part and the real-time embedded part in two physical parts, and use a general purpose computer (such as Raspberry Pi, or one of the more professionally packaged Teltonika products) to do the computer stuff, on linux, and then do the low level control stuff on the MCU, of course bare metal. This way the "computer" side exposes all the fancy interfaces, not just a limited subset, with minimum effort. I can SSH in immediately, or plug in a monitor and keyboard. I have Ethernet, Wifi and so on with minimum development effort. And then I spend most of the effort to make the microcontoller side work well. Depending on the project, it's even possible to disconnect the computer part during normal operation, then, and let it do the control.

The fact people struggle with giving any actual example but instead give the typical marketing speech is very revealing, though.

I especially love rstofer's arguments how simple it is react to an external event because you don't have to consume "computing cycles" waiting for it and can just configure an interrupt, where you post a semaphore, which the scheduler then dispatches to your task, which is written to wait for the semaphore. If it is already this complex on RTOS, it must be total pain in the ass without one! 

[rstofer]

I especially love rstofer's arguments how simple it is react to an external event because you don't have to consume "computing cycles" waiting for it and can just configure an interrupt, where you post a semaphore, which the scheduler then dispatches to your task, which is written to wait for the semaphore. If it is already this complex on RTOS, it must be total pain in the ass without one! 

I think I was trying to discuss the idea of modularity.  The UART interrupt handler receives a char (say) and stuffs it in a queue.  It is a producer and doesn't know about, or even care about, the consumer.  As long as the queue doesn't overflow, everything is great.

The consumer (waiting on a posting or otherwise polling the queue) just wants to grab data from time to time.  It doesn't care what produced the data, it just looks in the queue and reacts accordingly.  It knows absolutely nothing about the internals of the producer.  With an RTOS, we wouldn't even test the queue.  When it gets posted, the consumer task will be scheduled.  Otherwise, it is just waiting and inactive.

Neither task knows anything about the other.  I can replace the UART producer with a similar SPI gadget without a single change in the consumer.  Similarly, I can replace the consumer without telling the producer anything.

All of the interconnection is done through the queue.

Producer-consumer modularity has been around a long time and certainly doesn't require an RTOS.  What the RTOS brings to the dance is a standard for queue operations (pointer protection and such) which can be a PITA for super-loop programs.  And scheduling!  Why test the queue when the queue operation can schedule the consumer directly.

Still, it's a choice.  The work still gets done...

[Doctorandus_P]

I once had a job in maintaining software for an RTOS. (Nucleus)
It had 30+ tasks running in about 500kB of compiled code.

Once we had a bug that nobody could pin down, but the bug was reproducible in a particular version of the software. It was my task to throw away bits and pieces of the code while still being able to keep the bug reproducible. I managed to get it down to about 20kB, and that took about 7 work days. After that a colleague managed to pin it down to a pointer overflow in the RTOS kernel.

That's not a good environment for learning to work with an RTOS.

A few blinkenlights, combined with a bit of uart stuff a keyboard matrix and some display is a much better and gentler way to learn.

You can run an RTOS on an AVR, but it's not a good fit.
* Too limited in RAM.
* Too many registers that need to be saved for a task switch.
* Lack of different ISR priorities.

Some ARM cortex microcontroller is a much better fit for working with an RTOS.

[nctnico]

Producer-consumer modularity has been around a long time and certainly doesn't require an RTOS.  What the RTOS brings to the dance is a standard for queue operations (pointer protection and such) which can be a PITA for super-loop programs.  And scheduling!  Why test the queue when the queue operation can schedule the consumer directly.

Still the OS will do some polling (iterating through a list with tasks) on whether a task needs to be run or not under the hood.

Still, it's a choice.  The work still gets done...

Indeed the choice isn't that black and white. It is not like an RTOS is only to serve mediocre programmers. In a super-loop every task needs to be non-blocking. However if one task blocks due to a bug or suddenly starts to take a lot of time, the other tasks will be starved from processing time in a super-loop system. An RTOS which does pre-emptive multitasking will divide processing time equally according the process priorities so a tasks which misbehaves is not halting the entire system. It also allows to have a watchdog task which checks the other tasks to see if one is hanging and then restart the particular task or the entire system.

Another solution to blinking 3 LEDs (as an exercise to have 3 parallel tasks!) is to use 3 hardware timer channels and use an interrupt to blink a particular LED. I like to see the interrupt controller as a task manager to have tasks run in parallel even when the application is implemented as a super-loop. Actually, you can have several super-loops this way. A main loop which runs a bunch of tasks and a timer interrupt from which another set of tasks is run.

All in all I don't think there is much difference in complexity between using an RTOS or super-loop. Each have their pitfalls; in the end you'll need a competent programmer to write robust code.