Basic Design using RTOS

Write short interrupt routines, but not too short large number of tasks - pros: - better control of the priorities and by this of the relative response times, better modularity - cleaner code, more effective encapsulation of data large number of tasks - cons: more data sharing, more semaphores, more time on handling them and more bugs, more time on message passing between tasks

Basic Design using RTOS

large number of tasks - cons: - more stack space and more memory, - more time lost to context switching, moral - use as few tasks as possible add more tasks to your design only for clear reason. Reasons for adding more tasks: - for better response time through manipulating priorities; - for better sharing of hardware; - for better protection between different functions sharing data; - for simplicity of separate tasks; - for works that needs to be done in response to different stimuli

Basic Design using RTOS

Avoid creating and destroying tasks while the system is running, because: - it is time consuming; - it may be difficult to destroy a task without leaving something behind; - it may be better to create all the tasks at system startup and leave them. Consider turning time-slicing off, because: - fairness is not an issue; - tasks are not equally urgent; - if they of equal priority than it does not matter which completes first; Consider restricting use of RTOS: - to its minimal necessary subset; - by reducing number of different IPC mechanisms; - by restricting number of data formats; - by putting a shell around RTOS;

An Example Underground Tank Monitoring System Preliminary requirements

Specification - Refinements of requirements

How often do we need to read floats levels? Several times per second How quickly the system should respond to pushing a button? No more than 0.1 second How fast the printer print? 2 to 3 lines per sec What microprocessor to use? cheap but slow 8 bit microcontroller

Specification - Refinements of requirements

How long takes calculation of a number of gallons in a tank? By experimentation - 4 or 5 secs How long will it take to recognize a leak or potential overflow in a tank? By experimentation - several hundredths of a secs Is it possible to read the level from more than one tank at once? No How difficult is it for software to turn the alarm bell on and off? Easy by writing 0 or 1 to a memory location

Design
Resolving a timing problem Deciding to use an RTOS Dividing the work into Tasks

Design
Moving the System Forward - interrupts are sending signals through the system , telling tasks to do their work Dealing with the shared data - the gasoline levels data is shared by several tasks : - should we protect that data with a semaphore or should we create a separate task responsible for keeping the data consistent? - 1st question - how long any one task will hold on to the semaphore - not very long - 1or 2 msec. - 2nd question - can every task wait that long - Yes. So we do not need a separate task