1 / 12

Basic Design using RTOS

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

wood
Télécharger la présentation

Basic Design using RTOS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. 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

    2. 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

    4. 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;

    5. An Example Underground Tank Monitoring System Preliminary requirements

    7. 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

    8. 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

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

    11. 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

More Related