Wether or not to use an RTOS

[Noway2]

Hi All,

I have a question, that is really more of a curiousity than anything else. I am wondering what everyones opinion and experience is with regards to using an RTOS on embedded applications. I have worked with groups that think an RTOS is the only way to go and with groups that wouldn't touch one with a 10' pole. Personally, I have a slight bias away from them as most of my experience has been with applications that haven't used them and my thinking as an EE is more towards direct hardware control rather than desiring to abstract the hardware by turning it into a "file".

The arguments for using them seem to be that they make developing and expanding an application easier and more straight forward and also provides a form of hardware abstraction. While the arguement against them is that they aren't always necessary, especially for embedded systems and that they can consume a lot of precious processor resources.

Anyway, like I said, I am curious as to what others think?

 

[Skogsgurra]

I have never used an RTOS in a small embedded system. We have always built our little finite state machines by ourselves and with that we have been able to do measurements, triac trigger control, HMI and more at the same time within the smallest of processors. That seems to be why we got the jobs; the other guys needed costlier processors and that counts a lot when you are producing small appliances in millions.

But, I have used RTOS in larger systems. One particular system with DSP and several teams working together around the Globe used a graphical input and test RTOS they was very good. Needed in a system that was supposed to live 20 or 30 years and where maintenance would have been a problem otherwise.

And then, there's FORTH! A wonderful OS/Language/philosophy - anything. Just love it. Use it as often as I can.

Gunnar Englund

http://www.gke.org

 

[IRstuff]

It really depends on what types of hardware you're building/buying. And that's the nub.

If you're building your own processor boards, then an RTOS may be a luxury and probably unnecessary.

However, you buy a PC-104 or other OTS processor board, then a targeted RTOS makes sense, particularly if you plan to re-use the board elsewhere, since most of the device drivers, if not all, are already written.

For something like single board Power PC or DSP subsystem, not getting an RTOS might probably be suicidal.

TTFN

 

[itsmoked]

Nice point IRstuff. I have always skipped them because they add a level of uncertainty just like using a chunk of someone elses code. Always that nagging feeling like what was that sound from under the bed.

Also trying to wring the most out of the smallest processor is not conducive to dropping in a RTOS.

Hey skogsgurra you know of any forth implimentations for PICs? I used to ask Forth vendors and they always complained that the PIC12X55 and 56 didn't have any stacks but now they have pretty good stacks but I haven't run across any vendors lately. Lots of Forth for 8051s.

Forth is so cool because its whole premise is based on how you should develop all programs. Get the base/hardware functions going then add them together for the intermediate functions. The whole pyramid thinggy.

 

[Noway2]

I have never used Forth or worked any place that does (industrial and commerical embedded systems), where is it typically used?

I see IRStuff's point about being a requirement for a PC-104 type application, but more of an unnecessary luxury when you are designing your own system. The place that I worked that liked to rely heavilly on an RTOS also liked to develop around SBC (single board computers) based on an I486.

In this particular case, though I wasn't trying to make this part of the discussion, I am investigating and trying to decide if I wish to base an application I am developing on the TI DSP/BIOS (a small RTOS) or if I wish to develop it using the control loop approach.

I was hoping to spawn some generalized discussion of the subject with my post as I am very curious about how others have approached this subject.

 

[Skogsgurra]

smoked,

Stephen Pelc at MPE (

http://www.mpeltd.demon.co.uk/

) probably has a PIC Forth. I thought that I had used one of his systems - but cannot find it anywhere. Stolen? Probably, they are nice little creatures.

I like the MPE slogan: "More real - less time"

Gunnar Englund

http://www.gke.org

 

[itsmoked]

Thanks skogsgurra I will look into that.

Noway2 I'm not sure what you mean by "control loop approach"? Please define...

 

[MikeHalloran]

I think the last big FORTH design win was the air traffic control system for Saudi Arabia. The whole thing.

Professional Programmers (I use that as a pejorative) scoff at FORTH and will fight it tooth and nail for one reason; it would put 90+ percent of them out of work.

Which would be a huge cost savings, of course, but it would also put 90+ pct of software managers out of work, and that will _never_ happen.

Widespread adoption of 'C' and its offspring has resulted in full employment for programmers, with a buglist backlog extending decades into the future. What Professional Manager would give that up?

;---

Oh. Yeah. Back to the original question. I've put 'em in and ripped 'em out. My take is that most embedded stuff doesn't really need an RTOS, but if you are at the point where you are thinking about writing one, you should be buying one instead. Search on "Therac-25" to understand why.

;---

May the FORTH be with you.

Sorry; puns are obligatory in the world of FORTH.



Mike Halloran
Pembroke Pines, FL, USA

 

[Noway2]

I misquoted the term "control loop" from a document I read this morning. I should have used the term "infinite loop" otherwise known as a while(1) { ... do something }; which holds the system in a loop forever performing sub taks in round robin fashion.

My experience with embedded software design has relied on a variation of this approach by implementing a state machine design with a number of "states", each of which is a function call. The method I have used is as follows:

The main() function utilizes a couple of global variables called present_state and next_state which are nothing more than pointers to the "state" functions (state1, state2, etc). Each state can do its thing and before it returns, it sets next_state to wherever it needs to go in response to conditions. For example, if we are in an idle() state and somebody presses a start button, idle() can set next_state to start(). Then when the idle state issues a return call, returning to main(), main() starts execution at the routine pointed to by next_state which in this case would be start().

I am trying to compare this approach with that of using a prioritizing scheduler, provided by an RTOS. I have also seen code that creates a number of while(1) {}; loops and context switches between them on timer interrupts, though I am not planning on using this approach.

While I am thinking that I will try the RTOS approach for the application I am working on, I am curious as to what approaches that some of the regulars of this forum have been using in their experience and why they prefer one method over the other. I anticipate that there is no right or wrong answer, but I thought that a discussion of this topic might prove enlightening for everyone.

 

[Skogsgurra]

Mike. Make that "the latest" not "the last"!

BTW, FORTH is for small teams working efficiently without overhead. Or for large teams working under effiecient managers*. I think that the latter fact is what makes FORTH less popular in big companies.

*Efficient and knowledgeable managers are needed to set up the strict rules that a large team needs. There are very few rules in FORTH. Sometimes a drawback - but very good for little embedded applications - or an air fraffic control system...


Gunnar Englund

http://www.gke.org

 

[itsmoked]

I thought Saber, the airline ticketing system, was all Forth.

Noway2; That correction is way better. Whew!

Your round robbin scheduler gives me the total creeps... I have not used one and would never use one. Let me explain why. I worked for 10 years at a company whose "chief technical" officer only used your exact method for programming a complex product for an FDA application. This guy was no slouch, probably the smartest individual I have ever worked with. He would sit there writing code for a month or two.... Then it would take him 2 or 3 months to debug this huge mass of phlem!!

He would turn the thing on and wah-law nothing. Whereas we would all write conventional assembly and eventually C and the first day we would have 'something' running. The next day we would have most the hardware running. Third day all the hardware proven. Then we would start the "real" programming. This allowed immediate "oh damn!" stuff relating to the hardware to be delt with in a timely manner by the hardware guys. And not a month or two later when it's almost due and the hardware guys have started forgetting the little details that help deliver quick details.

His bugs would be insanely subtle and often based on dropped semifores or tokens due to the totally non-deterministic running of the programs. Because of this you could never actually ever test the program fully! Why? Because a year after you deliver the product the user asks the program to do something in a different order than has ever been done before... and pow! In a whiney voice on a scratchy phone: "Why did the temperature setpoint change after I did a date change?" ARGHHHH!!@!*&^*%!)!!!

Either write your code in a "foreground" "background" manner or if you really want the scheduling get an RTOS..

That would be my take.

I believe the Therac-25 exterminator was a round robin scheduled device.

 

[Noway2]

itsmoked,

It sounds like our thinking is very similar. Memories of working on that system with a round-robin scheduler STILL give me the creeps. The system was a static transfer switch that was used in very high profile applications...and that voice on the phone .... could it whine!

This application could be done quite well in a forground / background manner but I am thinking about using an RTOS to gain the experience of developing with one.

 

[itsmoked]

Noway2 I am a sound believer in trying new things ESPECIALLY if you are interested in trying it, as apposed to: forced to try it.

It may be a good idea to try it on a "lite" project that doesn't need it, so you are more easily able to dabble than in the next project that demands it and requires knowledge every feature too.

What generally is your present sw project?

 

[Noway2]

itsmoked,

This application is a diesel engine driven firepump controller. The controller will be responsible for monitoring a handfull of analog and digital signals which are used to decide if it should start the engine, or shut the engine down if it is running. The controller will also monitor the engine sensors and display them for the operator.

In addition to the engine functions, the controller will handle a small keypad for accepting user commands and setpoints, update a character display panel, respond to any communication requests from a building management system, and perform datalog functionality.

The primary focus of the project is to revamp the hardware to reduce cost compared to the present product by reducing (expensive) assembly labor time through smart hardware choices.

For the project, an RTOS really isn't necessary as the application is pretty simple. I agree with your statement that it may better to dabble with the RTOS concept on a 'lite' project like this that doesn't really need it as opposed to one that is more complex. It was this kind of reasoning that was paritally responsible for my choice to implement the controller with a DSP as opposed to a microcontroller. The other two reasons for the choice of a DSP in this application are that the cost was comparable to a lot of microcontrollers and I do believe that many applications can benefit from the mathematical capabilities that a DSP provides, especially if any analog interfacing is required.

As far as the RTOS goes, I have been spending some time these past few days investigating the API that is provided by the Texas Instruments RTOS. I am discovering that thinking through (not implementing yet) the application in terms of prioritized threads and tasks that can block and resume to be rather enlightening - certainly different than how I am used to looking at the application.

 

[itsmoked]

Thanks for the info. Does seem like an RTOS is not called for in this case. If you are going for "cheap" ur..um.. I mean inexpensive. I would expect that you want a no royalty RTOS which I presume the TI one is.

How do you handle the keyboard with the proposed RTOS since you usually need pretty snappy response there to prevent the common sluggish, problematical, keyboard syndrome?

Otherwise these tasks look like you could take eons to service without impacting the product in the least, as I see nothing like ignition[diesel] or fuel injection control both of which obviously need serious on-time realtime response.

It actually looks like a middle of the road PIC kinda job to me. Something like a PIC18F252 or 452 level. (8) 10bit A/D, 8X8 hardware multiply, 40Mhz, 3.8K ram, 25mA pins, serial port, watch dog!, 32K prgm flash, 256 EEPROM, SPI/IC2, 5 ports. Has cheap debug with ISPrgmin. Under $7. Grab the HTSOFT C PICC18 compiler. Turn on 32bit floating point and math yourself silly!

 

[IRstuff]

I'd assume that you can plagiarize ISRs from public domain sources for lots of these things. Most of the CPM ISRs for peripherals exist in the public domain.

TTFN

 

[Noway2]

itsmoked,

You are correct, the only time driven functions on this controller are keys and to some extent the display.

As far as the keys go, .... you are really going to say this is overkill ... and it is except for the fact that the device handles other functions too ... the keys will be debounced in a Cyclone FPGA and this will generate a hardware interrupt into the processor. The hardware interrupt handlers have the highest priority of any thread in TI's RTOS. The handler can in turn activate either a software interrupt or do a "put" operation on a semaphore to unblock a high priority task that can handle the IO.

After this controller is sucessfully integrated into the diesel platform, I intend to port it over to its electric motor driven brother. Since one of the key functions of the electric controller is power quality analysis to control a transfer switch (generator) I hope to get a leg up on that design implementation by already having a similar product based on a DSP which should be capable of the power analysis.

IRStuff,

Your thinking is correct in that there are already volumes written on implementing device drivers with this RTOS and whole working class examples - all free of charge and fully supported by TI.

These libraries and the abstraction interface they provided appeals to me because the person who will likely do most of the application programming is a computer science person who tends to give me "Doe Eyed Looks" when I try to explain how the hardware he is trying to control works. So, my thinking is that an abstraction interface will make things easier for team in the long run.

 

[itsmoked]

That! Is really overkill...

Just use a larger FPGA and drop in an ARM IP...program the whole thing in VHDL... That would only take a few years.

Those "Doe Eyed Looks" shudder...

This does not sound like the way to cut ALL the cost out of this project to meeee?

But it sure sounds like fun to test!! Nothing makes me happier than controlling pumps/pipes/valves/and lots of gushing water.