Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Multitasking in the microcontroller

Status
Not open for further replies.
There appears to be a misunderstanding in many peoples minds about what an Operating System (OS) is and consiquently what a Real Time Operating System (RTOS) is.

An Operating System supplies services to one or more programs in a standard way. To do this it puts "software shims" between the program and the hardware. The shims abstract the differences in hardware to a standard interface usually called an Application Programing Interface (API). This interface is often two level, that is you have the kernel or OS / BIOS hooks (often via software interupts) which are standard to the OS and above this are "wrappers" that give you. your standard programing interface such as the Standard C Library (Clib).

Most OS's are designed against two bench marks, (1) user responsiveness, (2) CPU Utilisation. This give the illusion to many people of having the CPU all to themselves whilst also making efficient use of the CPU. This works because most of the time a user is actually doing nothing and the CPU on a single user system simply sits there and spins waiting for a user key press etc.

However for some tasks such as industrial control the overriding emphasise is on response time. That is on your ABS you want the brakes to come on when you put your foot on the peddle not 100mS later.

There are two basic ways to do Real Time, the first is to put the real time asspects in Interupt Service Routiens (ISR) the second is to have a round robin approach where each task takes a very short period of time such that all tasks can run in less than the desired response time.

Neither method is even remotly efficient in CPU utilisation. One solution is to mix together the various OS design goals and you see thit with the varios Unix Real Time Extensions (Originaly Posix 4). One way to do this is to use fast and slow interupts and relagate non time critical functions to the background (non ISR). The fast interupts provide very low latency between an input and an output simply because the slow interupt (usually run on a timer interupt) has pre-schedualed the action and is just waiting for an external trigger to bring it into action.

Whole books have been written on just some small aspects of OS's and how to best acomplish certain design requirments (google Stallings, Bach, Labross and others).

As I and others have said an OS is no more than a software program, at it's most fundemental level an OS is a simple state machine and can be easily written that way. As the complexity rises tasks need to be run out of sequence so the state machine gets a scheadular in the idle task to decide which task is the next to run on the CPU. You can see how to do this by looking at any of the "light weight threads" libraries.

However to be of use in most embedded systems you need a way to switch tasks faster than some tasks take to run. To do this non premptively makes the state machine overly complex as tasks have to be broken down into sub tasks etc. To allow tasks to be preempted the CPU must be capable of performing a context switch as a minimum and in most cases the ability to switch stacks as well. Nearly all CPU's alow context switching through their ISR structure but quite a few low cost 8bit CPU'shave fixed stacks making preemption somewhat fraught.

Contary to what many people claim a Memory Managment Unit is not required for an OS it just makes life a lot lot simpler in general purpose OS's such as WinDoze and *nix (incidentaly non NT MS WinDoze was not preemptive and thus hung easily this is because MS-Dross was little more than a BIOS extension for a single user single task environment, the first "multi-tasking" it got was via a Terminate and Stay Resident (TSR) program called "sidekick").

Even CPU's that lack "software interupts" can be coaxed into doing them by a hardware cludge whereby writing to a specific address causes a hardware interupt. It's messy but it works OK.

It is important when designing your system to work out what it is you are doing. And this ranges from little one off's to control a simple non time critical bit of hardware (such as a keypad and caps lock led) through to very exacting and highly time critical functions in process control equipment or safety systems in vehicles.

As always a meet in the middle aproach is best whereby you have three program levels which are, (1) at the top the main program control loop, (2) beneath this the main tasks, (3) sub tasks and IO interface. This sits ontop of your BIOS or OS.

You can either "buy in" or "roll your own" BIOS / OS and often if you are using a bought in control board this code is available (often gratis).

If you are "rolling your own" the important part to spend time on is the API specification by which the program uses it. Mistakes at this point will cost you very dearly down the road. As inefficient as it might sound a simple "message passing" interface via pointers is probably best as it gives you great flexability and easy interfacing to high level languages. Have a look at the way some Forth and early versions of TCL do their API's. I tend to go for a "streams" type aproach using a text only interface, yes it involves quite a bit of work BUT it pays dividends in debuging time and in code re-use as well as simplification of program writing...

Beneath this API is the abstraction layer that talks to the device drivers, again try to come up with a general purpose API for this level and where you can avoid binary interfaces except where talking directly to the hardware.

Have a look at the way the various *nix's do this you will be reaping 40years of experiance. Remember the first Unix boxes where less powerfull and had less memory than most 16bit single chip microcontrolers.

Most of all DONT JUMP INTO RT SOLUTIONS until you have to. that is keep the RT aspects to the absolute minimum and keep them absolutly minimal. The main reason for this is getting the code to work and maintaining it. I have yet to work on a project that did not get "feature creap" either during the design or afterwards, and if you have tied up your RT resources you are very very limited in what you can do.

As a rough rule of thumb in a non RT system keep CPU utilisation below 70% in a RT system keep CPU utilisation down to 50%. Ensure that fast ISRs are less than 0.1% utilisation and slow ISR tasks no more than 50% of a "tick" (Timer interupt time).

Remember to use buffers between fast ISRs and slow ISRs and buffers between slow ISRs and the kernel and buffers between the kernel and background tasks.

That is a background (non ISR) task for talking to a human via a terminal or keyboard/display deals with "strings", user input editing of the string is done by the kernel, high level line disapline (ie RS232 XON/XOFF etc) is done by the slow ISR, low level timed activity such as a line break and moving data in and out of the UART is done by the fast ISR.

I hope that helps people get their head around what you have to do oh about half the time with embedded systems.
 
Last edited:
hi ...

multitasking is not possible in micro controller... you cannot do 2 process at a same time... cos it is a serial exceptional device...
RTOS will support multitasking also u can give the priority level for ur task..

my suggestion is u can go for FPGA it is a parallel processing device... where u can generate a 2 clock at same time....period
 

Sorry to disagree , for this complicated task you will have to borrow the IBM Roadrunner (1026 TFlops) form Los Alamos National Laboratory and build an nuclear plant next to it in case of power failure.
Or you can choose to write at most two code pages for an 1$ low range microcontroller to do this job that doesn't even need multitasking.
 
I can only suggest you all read lurchmans explanation and think about it.
While I might take exception to the "suggestion" that clib is anything to do with operating systems the rest of his post is accurate and very informative.

It is also nice to see someone who understands a little of the history of computing. A topic so lacking on todays so called training courses.

I remember being at a trade show when Microstuffed were shocked by
the emergence of IBM's OS2 and how far advanced it was (and still is) over
windows.

They were so desperate to combat this they created an OS that looked almost
identical and said "look this does the same job but faster" (Win95)

In fact it didn't and they then made the mistake of claiming windows (like OS2)
was "pre-emptive". Both myself and 2 other jouralists attacked the M$ spokesman shamelessly. Essentially they maintained the lie for marketing purposes and microstuffed have been crippling our desktops ever since.

From reading this thread it seems to me that some people are a bit confused
about what a multi-tasking OS is.

All you need to remember is a computers PROCESSOR and support buses can only do one thing at once. Compters are science - not magic.
If you still dont get it - go look up "von Neuman bottleneck" and expand it to the whole processor/bus system as it is designed.

Multi-tasking is the job of pausing one task in order to do something considered more important and then, perhaps, returning to the original task.

The point being - this is done so fast that people can't see the switch.
All the hows and why's are just design considerations.
Perhaps the term "multitasking" is a misnomer that has confused people so much it should be dropped entirely..

jack
 
  • Like
Reactions: lurchman

    V

    Points: 2
    Helpful Answer Positive Rating

    lurchman

    Points: 2
    Helpful Answer Positive Rating
From reading this thread it seems to me that some people are a bit confused
about what a multi-tasking OS is.

All you need to remember is a computers PROCESSOR and support buses can only do one thing at once. Compters are science - not magic.
If you still dont get it - go look up "von Neuman bottleneck" and expand it to the whole processor/bus system as it is designed.

Multi-tasking is the job of pausing one task in order to do something considered more important and then, perhaps, returning to the original task.

The point being - this is done so fast that people can't see the switch.
All the hows and why's are just design considerations.
Perhaps the term "multitasking" is a misnomer that has confused people so much it should be dropped entirely..

jack

Fully agree. It can be done by a RTOS, by a piece of FW you wrote or, more interestingly, by an interrupt driven system (I think thats what Dora was trying to say). In any case, only one task will run at any time.
 

Hmm, I would have said you can do some multi-tasking with a PIC, although its architecture probably isn't ideal for it. I see that is also the opinion in reply to your question elsewhere.

forum.allaboutcircuits.com/showthread.php?t=46486

If you write a complex program with a lot if interrupts going on then in a way it is multi-tasking i.e. doing more than one thing at once, although not strictly simultaneously.

Keith

For example, you have PICOS18 fo the Microchip PIC 18 family. Works pretty well for small applications.

Christian
 

I just want to share this RTOS for PIC16

www(dot)microchipc(dot)com/sourcecode/#tiny_threads
 
Can u plz tell me the microcontroller with RTOS???
is it possible to install jvm on a microcontroller to run J2ME???
plz help??
 

If Multi-Tasking is not possible in Micro controllers then it should not be possible in 8088/8086 too.
What is multi tasking??? -> The system executes more than one task , But in reality it isn't.
so how single core processors do execute simultaneous tasks? Well changing the stack of each task.

RTOS is not a magic which does multitasking. RTOS is first an OS(Operating System) which is RT(Real Time).

If RTOS can do Multasking On a Micro-controller, Then Definitely we can do it.
Well the key lies in task switch for the most simple task switch you can see GeekOS
It is for 386 and above processor but you can understand basics of multitasking.

Even YOu can look into My own small OS NanoOS
even it is also for the 386 and above processor. as it is written in C++ I hope any one can understand the logic of multitasking.
 

Can u plz tell me the microcontroller with RTOS???
is it possible to install jvm on a microcontroller to run J2ME???
plz help??

If you refere the freerots site you will be amazed by the number of controllers it supports. even it has partial suport for PIC18.

Regarding JVM Well there are Java VM which takes very small memory and space, But As I am not from Java background I can't say which is good.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top