29-11-2012, 03:50 PM
Basic Design using RTOS
basicdesign.ppt (Size: 901 KB / Downloads: 30)
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
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
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
Design
Resolving a timing problem
Deciding to use an RTOS
Dividing the work into Tasks
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