Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Basic Design using RTOS

VIEWS: 13 PAGES: 12

									                   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

								
To top