Multi-tasking

At the best of times, I am not much of a multi-tasker.  Let me concentrate on finishing one task well and I will be happy.  Give me six things to do at once and inevitably I will forget something.  Just thought that you should know that.

Today’s lesson was on programming in a multi-tasking environment.  Specifically within the framework of a real time operating system, or RTOS for short.

Windows is probably the operating system that most people are familiar with.  At its heart, the main thing that Windows does is co-ordinate the execution of all of the different programs (or tasks more correctly) that I might want to run. 

If I have my e-mail program running, and then I open my internet browser along with my media player, the operating system needs to ensure that each program is permitted access to the limited resources of the processor. 

Since generally there is only one processor and this processor can only do one thing at a time the operating system needs to decide how best to divide up the processors time.

Though it may look like each program is running at the same time, in reality this is an illusion.  The operating system actually divides time into slices and allows each program to run for the duration of a time slice, before switching to a different program.  The programs appear to be running concurrently because this time slice is so small that within a given second every program gets a chance to run many times.  Now this is an over simplification but I think you get the idea.

In the desktop software world you are probably aware of a few operating systems, Windows, Mac OSX, and Linux are far and away the most popular.  In the world of embedded programming things get more complicated.  Depending on the complexity of the embedded system a developer may or may not need an operating system.  Your smoke detector probably doesn’t use an operating system, but most assuredly your TVs and DVD players do.

When is an operating system required?  Well it is not a cut an dry question but certainly as the complexity of the device increases and the number of things it is required to do increases an operating system starts to become a necessity.

So is my DVD player running Windows?  Uh, … no.

Most embedded devices have an additional requirement that desktop computers generally do not have.  A real-time constraint.  Specifically when I want to do something, it needs to be done absolutely within a certain period of time.

Have you ever tried to do something in Windows and waited many seconds for it to respond to your command?  You sit there twiddleing your thumbs while Windows is busy doing something else in the background.  You have to wait for Windows to finish doing what it wants to do before you get any joy.

Now think about this.  How would you like it if the ABS braking system in your car were like that.  You press the brakes and your car decides that it is doing something more important at the time being and that it would get back to you when it was good an ready.

I think you can imagine the consequences.

In the embedded world very often there are hard time constraints for the system to perform a function.  In our example the user presses the brakes, so the ABS system had better be monitoring for wheel lock-ups hundreds if not thousands of times each and every second without fail.

As an aside this is another unique characteristic of embedded systems.  They have to be much more reliable then your typical desktop computer.  Have you have ever heard of a TV having a blue screen of death?  When was that last time you had to reboot your smoke detector?  Embedded systems need to work day in and day out for years on end without ever crashing.

So since embedded systems often have real time constraints, they usually can’t rely on the same operating system that is running your computer.  This is where a real time operating system comes in.

I mentioned the big 3 desktop operating systems, so what are the equivalent big 3 RTOSs for embedded systems?  Well it really isn’t that easy.  Since each and every embedded device has such differing requirements there are many different operating systems available.  Far too many to list here, and even if I did you probably would not have heard of them.  Also in many cases embedded programmers will write their own operating system, a feat unheard of in the desktop world, but quite doable by a single programmer on a small embedded device.

Now all that to get to this.  In today’s lecture we covered the following topics using the uc/OS-II operating system:  task creation, assigning task priorities, understanding how task switching works and guarding against race conditions between tasks.  I won’t go into the details but needless to say today was another interesting day at the embedded software boot camp.