When to make the switch to Realtime OS?

Hey all-
First time caller. I am pretty new to Arduino\embedded systems and have already caught myself thinking about when is the right time to upgrade to a single board computer\realtime OS?

I've got a project that may need to scale up when it comes to processing power and being new, have not fund a clear path for doing this.

Maybe I should ask my question a different way. When do you guys find yourself moving to a single board computer on projects?

Thanks,
Doug

when is the right time to upgrade to a single board computer\realtime OS?

Never, they are a total waste of time on a simple controller like this.

I have had software engineers working for me totally cripple an system by putting a RTOS on it. Then they winger about needing a more powerful processor and more memory. When if they were true professionals they could have done without and made a decent project.

I move up to an SBC+RTOS when:

  • There is a "lot" of RAM and FLASH (megabytes, not kilobytes)
  • There are a lot of subsystems that need to be managed simultaneously
  • Processing power needs to be in the hundreds of MHz, not <100MHz

But frankly, this is becoming more and more rare (for me). A 72 MHz ARM processor can do a lot of stuff without an RTOS these days.

--
The MegaRAM shield: add 128 kilobytes of external RAM to your Arduino Mega/Mega2560

Yep, no OS for me. I design and build simple single purpose projects that allow me to control all aspects of what the microcontroller is doing, no OS to get in the way or suck off raw performance.

To me a microcontroller is a programmable component doing something specific to my requirements, not a general purpose computer meant to be able do all things for all purposes. Not sure that 32 bit controllers will ever fit for my type of projects as they are not easily convertable to standalone construction and one must dedicate the whole development board to the completed application, and then buy another development board. I find that a $5 328p DIP chip and a few support components is the 'hardware platform' I want to build from and design projects around, not complete development boards let alone ones running a RTOS as a starting point.

Lefty

And if one Arduino cannot handle it, you can easily use two or three (etc) that work together

robtillaart:
And if one Arduino cannot handle it, you can easily use two or three (etc) that work together

Good point. I think 8 bit controllers have a long future, at least for the hobbyist. Now if they could step up the 328p to clock at say 400Mhz, that could be something to get behind. :wink:

Lefty

Now if they could step up the 328p to clock at say 400Mhz

What would you make ?

robtillaart:

Now if they could step up the 328p to clock at say 400Mhz

What would you make ?

Not sure, but it would be faster! :wink:

..he can use 16 or 32 of them working together and build a general purpose PC.. :slight_smile: :slight_smile: :slight_smile:

together and build a general purpose PC

I think the point is we don't want to do anything general purpose with an embedded processor, it is going to be dedicated. Besides we had general purpose PC with 8 bit processors in the 80s no need to go back.

Not sure that 32 bit controllers will ever fit for my type of projects as they are not easily convertable to standalone construction

I'm designing a tiny project based on the LPC1224, at 48 pins it's the same size (physically) as the Mega328 but it runs 2-3x as fast (that's just the clock speed, who knows about code execution but that could double things again depending on the code), and with the 1% tolerance internal oscillator NO external components are required for most applications apart from the usual decoupling caps etc.

Add to that 4x RAM and flash, real debugging support, built-in bootloader that cannot be bricked, RTC, proper FIFO support for UART and SPI, DMA, two UARTs, all 32-bit counters etc so no frigging around accumulating counter overflows, most functions can be MUXed to other pins, and about the same price as the Mega328. Also const strings/data do not take up any RAM, they stay in flash where they belong, no more PROGMEM.

On the down side most of the pins can't drive quite as much current, no EEPROM (but there are instructions to write into flash) and it's 3v3 only.

For me 32-bit will definitely fit into any future projects, if they made 8-20 pin sizes I would never look at an AVR again :slight_smile:

What they don't have is a great support community :frowning: although the LPC Xpresso forum is not bad.

As for using an RTOS, I've never seen the need.


Rob

As for using an RTOS, I've never seen the need.

The typical Arduino user doesn't need a true RTOS (Defined interrupt latency, preemptive multitasking etc), but they sure do need an organized framework they can understand for gluing several functions together in apparent (actually polled) concurrency.

That's true. I had a simple system a while back that was basically just software timers with call back functions. It was pretty primitive but something like that would be nice.

Hasn't there been a couple of similar things presented here?


Rob

So without an RTOS, is there a way to perform concurrent processes with Arduino? The simplest example I can think of is having several LEDs blinking, each at a different rate. In reality, though, I'm doing something more involved - and instead of running several processes as the same time, I have to do things serially... which is the only way I know how. From the little that I've read, one of the things that RTOS proponents praise is this "multi-tasking" capability.

I'm glad to have stumbled upon this thread, as I was leaning towards the RTOS route. Now I'm not so sure... any feedback is appreciated!

The simplest way I can think of is something like this.

loop () {
   process1();
   process2();
   process3();
}

void process1 () {
// do stuff, maybe read pushbuttons
}

void process2 () {
// do stuff, maybe write LEDs
}

void process3 () {
   if (millis() - last_millis() > some-time) {
      //do other stuff
   }
}

The next level up is probably what I said before, a system of software timers with callback functions.

But the right approach depends a lot on what you actually need to do.

Note that technically nothing will be "concurrent", but it may appear to be so depending again on what you need to do.


Rob

The concept of protothreads is interesting:

http://www.sics.se/~adam/pt/index.html

These bring the appearance of threading to your program without actually threading. It has limitations (e.g., local variables do not persist in a thread) but it can produce a nice illusion of multithreading without the overhead of an RTOS or true threads.

--
BeatVox: inexpensive sound shield for Arduino, 3.5mm stereo output, 512Kbyte FLASH

Nicman the point is that anything an operating system can do for you you can do for yourself. When you do it for yourself you only implement the bit of an RTOS that you want, in the way you want it. That means it is faster and more efficient that carrying the baggage of being able to do everything. Also because you have written it you don't get bogged down trying to make it do what you want. In practice you spend a lot of time fighting the RTOS, so the initial advantage it appears to offer is often illusory. There is no such thing as true multitasking on a single core machine, there are just several techniques of making it appear there is. Any RTOS gives you one technique but when you write the code yourself you get the one that suites your task.

Well, thanks for the input, guys. For now, I will continue with what I know... which is not RTOS. The fact is (as you've already mentioned) that I've been able to make my programs do what I want them to do without an OS. I just wanted to know if there was something more elaborate than interrupts. So instead of simply monitoring the state of an I/O pin in the background... the ability to execute a simple function in the background (while executing the main loop).

I'll take a look at what protothreads are... sounds interesting.

Thanks, again.

I just wanted to know if there was something more elaborate than interrupts.

Fundamentally no, multitasking from an RTOS is implemented by using interrupts. These are set to go off at a certain regular time and the ISR looks at what task needs running next and swaps that in. This is called preemptive multitasking.
The cooperative multitasking technique involves the tasks all calling the multi task supervisor regularly to give up their CUP time and send it to another. The snag with this is there is nothing to stop a task from hogging the CPU and not letting other get in.

However it is done it is all software on a single core machine.

Thanks guys. I was kind of thinking the same thing. However, there is a general performance concern and not sure how to handle a problem should one arise. Maybe I should of asked the question a different way...

What do you do when the performance is not fast enough? We just invested XX amount of time and come to find out the performance is not there? MY thought is with a RTOS, we can move it over to a larger machine with more computing power and not worry about porting too much. With a microcontroller and specifically the Arduno - what do you do? Rewrite the software for a different platform?

Thoughts?