VIEWS: 13 PAGES: 12 POSTED ON: 4/8/2010
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
"Basic Design using RTOS"