ECE 532 Embedded Systems Winter 2005

1
ECE 532 Embedded SystemsWinter 2005

• Session 7

2
Foreground/Background System
3
Aperiodic Tasks

• Discussions to date focused on periodic tasks
  with hard deadlines
• Handle aperiodic tasks when we have time
• Either foreground or background
• Some issues
• Aperiodic tasks spawned by events
• Event may have time critical response associated
  with it
• e.g errors, operator inputs, etc.
• Sooner it runs, the more response the system
  appears
• Periodic tasks must fit within the deadline
• Cant overrun time boundary
• No advantage to running more often than necessary
• No advantage to completing earlier than required

4
Approaches Discussed

• Handle in foreground
• Works if task can complete before time expires
• Handle in background as FIFO process
• Works as long as more important task not waiting
• Handle in background as priority queue
• Minimizes wait for highest priority tasks

5
Possible Implementation Approaches

• Event detection in foreground
• Enable after periodic tasks complete but before
  returning to background
• Queue aperiodic tasks in FIFO or priority order
• FIFO Approach
• Process task at head of queue in background after
  current background task finishes
• Table update routines insert at end of queue
• Background scheduler processes the FIFO table in
  order
• Task removed from table once it is released to
  run
• Priority Approach
• Process highest priority task queued in
  background after current background task finishes
• Background scheduler works on priority based
  table
• Table update routines must insert task according
  to priority order
• Task removed from top of table when it is
  released to run

6
Consider the following

• What conditions must be met
• Suppose that there are na aperiodic tasks that
  occur at random but with an average rate of ri
  and have an average execution time of ei
• gt processor load for any aperiodic task is
  ei/ri
• gt total processor load for aperiodic tasks is A
  ? ei/ri
• gt average load per periodic frame is A/Nm ,
  where Nm is the number of minor frames
• For a foreground/background system with np
  periodic tasks each with period tj and with an
  average execution time of ej , the processor load
  for periodic tasks is P ? ej/tj
• gt average load per periodic frame is P/Nm ,
  where Nm is the number of minor frames
• Clearly P A lt 1 for the system to handle all
  tasks
• Note this condition does not guarantee that hard
  deadlines will be met
• If k is the minor frame number, Pk Ak lt 1 for
  all k will guarantee that hard deadlines are met

7
Response to APeriodic Tasks

• Worst case
• Assume task event occurs at start of kth frame
• gt response delay tr Pk Ak for ei lt Ak
• gt tr Pk ei ? Pl , where l k1, k2 k?
  such that the ? Al gt ei
• gt average response time Tave may be estimated
  by
• Tave ei ei/(ATm) PTm where .
  indicate round up to nearest integer and Tm is
  minor frame period

8
Project 5

• Use system and data from project 4 but modify
  data to use the signal periods as the periodic
  task rates and increase the task durations by a
  factor of 10. (This will allow you to use the
  same schedule tables and maintain the same
  performance scaled by a factor of 10)
• Examine the spreadsheet posted on the web site.
  This sheet contains the definition for the
  aperiodic tasks shown below and allows you to
  generate task occurrences by pressing function
  key 9 (each press is 100 frames).

9
Project 5 (cont)

• Modify your project 4 to adjust the periodic rate
  and the execution time of the periodic tasks.
  Delete any background tasks you may have used and
  add the background tasks from the table on the
  previous slide.
• Select one of the high rate, periodic tasks and
  modify as follows
• In each frame, draw a random number to determine
  if the task occurred.
• If the task occurs, set a variable for use by the
  aperiodic task handler which will be invoked at
  the end of the periodic task execution in each
  frame.
• The aperiodic task handler will detect the tasks
  that have occurred and place them in a FIFO queue
  (schedule table) in the background
• The background scheduler must remove the task
  from the table when it is invoked.

10
Project 5 (cont)

• Get Project 4 Running and then make the following
  measurements
• Estimate the load per frame and the total
  processor load based on the data in the
  spreadsheet and your scheduler code.
• Determine the time spent in each frame for the
  periodic task execution
• Determine the time spent in each frame for
  overhead for periodic and aperiodic task
  scheduling
• Determine the average time/frame and the total
  time for periodic task execution
• Determine the average time/frame and the total
  time for aperiodic task execution
• Determine the average response time for each
  aperiodic task
• You may wish to build a modified NIOS using
  multiple timers for this project.
• Project due 19 March 2005.

11
Event Driven System

• Extending the Foreground/Background approach to
  event driven systems
• Tasks run in the back ground
• Event handlers run in the foreground
• Key issues
• Critical operations performed by ISRs to ensure
  timely action
• Extends ISR execution time
• Task execution locked out by ISR
• Impacts task level response
• Task execution time non-deterministic
• Code modifications can result in timing impacts

12
Real-Time Operating System (RTOS)

• Provides standard set of services to help manage
  task execution
• Avoids many of the problems of applying
  foreground/background to aperiodic systems

13
RTOS Program Structure
14
Some Definitions

• Critical Section of Code
• Code which must not be interrupted
• Typically disable interrupts while it is
  executing
• Task
• Simple program which thinks it is executing alone
  in the CPS
• Can be considered a thread
• Each task has a priority, its own set of
  registers, and its own stack area
• Resource
• Any entity used by a task (I/O device, variable,
  array, memory, etc)
• Shared Resource
• Resource that can be used by more than one task
• Task should gain exclusive use of the resource to
  prevent data corruption
• Exclusive use is called mutual exclusion

15
Some Definitions (cont)

• Multitasking
• Process of scheduling and switching the CPU among
  several tasks
• Only one task is running at any given time
  instant although many may be executing
• The OS task switching mechanism allows each task
  to have the illusion that it has the CPU to
  itself
• May also be considered multithreading
• Task States
• Task is typically an infinite loop than can be in
  any of five states
• Dormant
• Residing in memory but not available to the OS
• Ready
• Task is ready to execute but has a lower priority
  than the currently running task
• Running
• Task has control of the CPU
• Waiting
• Task requires the occurrence of an event (I/O
  operation to complete, shared resource available,
  etc.)
• Interrupted
• The task was running and an interrupt
  occurredCPU is servicing the interrupt

16
Some Definitions (cont)

• Context
• Current Tasks CPU registers
• Context Switch
• Saving one tasks context and restoring anothers

17
Multiple Tasks
18
Task States
19
Kernel

• Responsible for task management and inter-task
  communication
• Kernel provides services to support context
  switching
• Requires extra code space, additional data space,
  and additional task space
• Requires additional CPU time

20
Scheduler (Dispatcher)

• Responsible for determining which task will run
  next
• Since most R-T Kernels are priority based, this
  is priority scheduler
• Control of CPU is given to highest priority task
  that is ready to run
• When task gets control of CPU is dependent upon
  type of Kernel used
• Non-preemptive
• Preemptive

21
Non-Preemptive Kernel

• Requires task to explicitly give up control of
  the CPU
• To maintain illusion of concurrency, this process
  must be done frequently
• Aperiodic tasks handled by ISR
• ISR may make higher priority task ready to run
  but ISR always returns to interrupted task
• Higher priority task gains control of CPU only
  when the current task relinquishes it

22
Preemptive Kernel

• Highest priority task ready to run is always
  given control of the CPU
• When a task makes a higher priority task ready to
  run, current task is preempted (suspended) and
  higher priority task given control of CPU
• If ISR makes higher priority task ready, when ISR
  completes, the interrupted task is suspended and
  the higher priority task runs

23
Reentrancy

• Reentrant Functions
• A reentrant function may be used by more than one
  task without fear of data corruption
• May be interrupted at any time and resumed later
  without loss of data
• May use local or global variables
• If using global variables, function must protect
  global data
• Place arguments on task stack to preserve
• Non-Reentrant Functions
• Cannot guarantee integrity of data in
  multitasking system

24
Task Priority

• Assigned to each task
• Higher priorities given to most important tasks
• Priority may be static or dynamic
• Static Priority
• Assigned at compile time
• Doesnt change during execution
• Dynamic Priority
• Assigned at run time
• May be changed during run

25
Assigning Task Priorities

• Alternatives
• Static or fixed priority
• Similar to what we did in the foreground/backgroun
  d approach (highest rate first)
• Rate-Monotonic Algorithm
• Highest Rate is given highest priority
• Assumptions
• Periodic tasks
• Tasks do not synchronize with each other, share
  resources or exchange data
• Preemptive scheduling must be used
• RMS Theorem
• Given n tasks, all task hard real-time deadlines
  will always be met if
• (Ei/Ti) lt n(21/n 1) , where Ei is maximum
  execution time of the task
• Ti is the execution period

26
RMS Theorem (cont)

• Hence, Ei/Ti corresponds to fraction of CPU time
  required to execute task i.
• Allowable CPU utilization based on number of tasks

27
RMS Theorem (cont)

• If CPU utilization is less than 70 for all time
  critical tasks, we can meet all the required
  deadlines.
• For design, a better approach is to design
  critical task load to use a maximum of
  approximately 50 of the CPU
• This leaves some room the non-critical tasks and
  growth

28
Mutual Exclusion

• Shared data structures provide easiest inter task
  communication scheme
• Simplifies exchange of information
• Must ensure each task exclusive access to data to
  avoid contention and corruption
• Exclusive access methods
• Disabling interrupts
• Test and set operations
• Disabling scheduling
• Semaphores

29
Disabling and Enabling Interrupts

• Shared resource access example pseudo code
• Disable interrupts
• Access the resource (read/write from/to
  variables)
• Reenable interrupts
• OS may provide macros to support disabling and
  enabling interrupts
• For Example, uC/OS-II macros
• OS_ENTER_CRITICAL()
• OS_EXIT_CRITICAL()
• Caution disabling interrupts for too long
  affects interrupt latency of system

30
Test-And-Set (TAS)

• Define a global variable to be checked
• To access a resource, function tests the global
  variable
• If zero, function sets variable to one and begins
  using resource
• If one, function knows the resource is in use and
  must wait to access it
• Function using resource must clear the global
  variable when finished with the resource

31
Disabling and Enabling the Scheduler

• Temporarily creates a non-preemptive situation
• Interrupts are enabled but always return to the
  interrupted task independent of priority
• Method works but probably should avoid
• Defeats purpose of having a scheduler and a kernel

32
Semaphores

• Used to
• Control access to a shared resource (mutual
  exclusion)
• Signal occurrence of an event
• Allow two tasks to synchronize activities
• Think of semaphore as a key that the code
  acquires in order to continue execution