lurchman
Member level 4
- Joined
- Dec 6, 2010
- Messages
- 69
- Helped
- 30
- Reputation
- 60
- Reaction score
- 28
- Trophy points
- 1,298
- Location
- UK South East.
- Activity points
- 2,267
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.
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: