Designing User Interfaces Spring 1999

1
SE 746-NT Embedded Software Systems
Development Robert Oshana Lecture
18 For more information, please
contact NTU Tape Orders NTU Media
Services [phone]
oshana_at_airmail.net
tapeorders_at_ntu.edu
2
Software architectures 2
3
Agenda

• Function-queue scheduling architecture
• Real-time operating system architecture
• Choosing an architecture

4
Function queue scheduling
5
Function queue scheduling

• Interrupt routines add function pointers to a
  queue of function pointers for the main
  function to call
• main routine just reads pointers from the queue
  and calls the functions

6
Function queue scheduling

• No rule says main has to call the functions in
  the order that the interrupt routines occurred
• Any priority scheme that suits the purpose
• Takes some clever coding in the functions that
  queue the function pointers

7
Function queue scheduling

• Worst wait for the highest priority task code
  function is the length of the longest of the task
  code functions
• Plus execution times of any interrupt routines
• Based on worst case task phasing
• Round robin worst case includes ALL tasks
  (possibly)
• Lower priority functions could starve

8
Function queue scheduling architecture
!! Queue of function pointers void interrupt
vHandleDeviceA (void) !! Take care of I/O
device A !! Put function A on queue of function
pointers void interrupt vHandleDeviceB
(void) !! Take care of I/O device B !! Put
function B on queue of function pointers
9
Function queue scheduling architecture
void main (void) while (TRUE) while( !!
Queue of function pointers is empty) !! Call
first function on queue void function_A
(void) !! Handle actions required by device A
10
Function queue scheduling architecture
void function_B (void) !! Handle actions
required by device B
11
Real-time operating system
12
Introduction to OS

• An operating system is a computer program that is
  initially loaded into a processor by a boot
  program
• It then manages all the other programs in the
  processor
• The other programs are called applications or
  tasks

13
Introduction to OS

• The applications make use of the operating system
  by making requests for services through a defined
  application program interface (API)
• A task is a basic unit of programming that an
  operating system controls
• Each different operating system may define a task
  slightly differently

14
Introduction to OS

• Task is a unit of programming that may be an
  entire program or each successive invocation of a
  program
• Programs may make requests of other utility
  programs and these utility programs may also be
  considered tasks
• Many of today's widely-used operating systems
  support multitasking

15
Introduction to OS

• Allows multiple tasks to run concurrently
• Each task takes turns using the resources of the
  computer

16
Services an OS provides

• In a multitasking operating system where multiple
  programs can be running at the same time, the
  operating system determines which applications
  should run in what order and how much time should
  be allowed for each application before giving
  another application a turn

17
Services an OS provides

• It manages the sharing of internal memory among
  multiple applications
• It handles input and output to and from attached
  hardware devices, such as hard disks, printers,
  and dial-up ports
• It sends messages to each application or
  interactive user about the status of operation
  and any errors that may have occurred

18
Services an OS provides

• It can offload the management of what are called
  batch jobs (for example, printing) so that the
  initiating application is freed from this work
• On computers that can provide parallel
  processing, an operating system can manage how to
  divide the program so that it runs on more than
  one processor at a time

19
What makes an OS an RTOS

• An operating system must have certain properties
  to qualify it as a Real-Time operating system
• Most importantly a RTOS must be multi-threaded
  and preemptible.
• The RTOS must also support task priorities

20
What makes an OS an RTOS

• Because of the predictability and determinism
  requirements of real-time systems, the RTOS must
  support predictable task synchronization
  mechanisms
• A system of priority inheritance must exist to
  limit any priority inversion conditions

21
What makes an OS an RTOS

• Finally, the RTOS behavior should be known to
  allow the application developer to accurately
  predict performance of the system
• An example is the interrupt latency (i.e. time
  from interrupt to task run). This has to be
  compatible with the application requirements and
  has to be predictable

22
What makes an OS an RTOS

• Real-time operating systems do very little
  explicit resource management to provide
  acceptable predictability of task completion
  times.
• An RTOS will provide only more or less tightly
  upper bounded services, clocks and timer
  services, and some resource reservation
  functionality

23
What makes an OS an RTOS

• Almost all the responsibility for real-time
  performance rests on all the application
  programmers (who usually greatly outnumber the
  RTOS programmers!)
• A good RTOS is not only a good kernel!
• should also have good documentation
• should also be delivered with good tools to
  develop and tune the application

24
What makes an OS an RTOS

• Even if some figures like the interrupt latency
  and context switch time are important, there are
  many other parameters that will make a good RTOS
• RTOS supporting many devices will have more
  advantages than a simple kernel

25
Types of Real-Time Tasks

• Periodic executes regularly according to a
  precomputed schedule
• Sporadic triggered by external events or
  conditions, with a predetermined maximum
  execution frequency

26
Types of Real-Time Tasks

• Spontaneous optional real- time tasks that are
  executed in response to external events (or
  opportunities), if resources are available
• Ongoing tasks fair-share threads

27
RTOS

• A real-time operating system (RTOS) is a type of
  operating system that guarantees a certain
  capability within a specified time constraint
• If a certain calculation, for example, could not
  be performed for making an object available at a
  designated time, the operating system would
  terminate with a failure

28
RTOS

• Some real-time operating systems are created for
  a special applications such as DSP or even a cell
  phone
• Others are more general purpose operating systems

29
RTOS

• Some of the existing general purpose operating
  systems claim to be a real-time operating systems
• In some respects, almost any general purpose
  operating system (Microsoft's Windows NT for
  example) can be evaluated for its real-time
  operating system qualities

30
RTOS

• In general, real-time operating systems are said
  to require
• Multitasking
• Process threads that can be prioritized
• A sufficient number of interrupt levels

31
RTOS

• The purpose of a RTOS is to manage and arbitrate
  access to global resources
• CPU
• memory
• peripherals
• The RTOS scheduler manages MIPS and real-time
  aspects of the processor

32
RTOS

• The memory manager allocates, frees, and protects
  code and memory
• The RTOS drivers manage I/O devices, timers,
  DMAs, etc

33
RTOS

• Real-time operating systems are often required in
  small embedded operating systems that are
  packaged as part of microdevices
• Some kernels can be considered to meet the
  requirements of a real-time operating system
• since other components, such as device drivers,
  are also usually needed for a particular
  solution, a real-time operating system is usually
  larger than just the kernel

34
RTOS

• More than general purpose operating systems, RTOS
  should be modular and extensible
• In embedded systems the kernel must be small
  because it is often in ROM and RAM space may be
  limited
• Some systems are safety critical and require
  certification, including the operating system

35
RTOS

• That is why many RTOSs consist of a micro kernel
  that provides only essential services
• scheduling
• synchronization
• interrupt handling
• Multitasking

36
RTOS

• A RTOS for an embedded CPU is somewhat
  specialized in itself
• A typical embedded application with consist of
  two general components, the application software
  and the system software
• The operating system is part of the system
  software layer

37
Embedded S/W Components
Application software
System software
I/O
Micro
Timers
DMA
Memory
peripherals
38
More on RTOS

• The function of the system software is to manage
  the resources for the application
• peripherals like a DMA, HPI, or on-chip memory
• The CPU is a processing resource to be managed
  and scheduled like other resources

39
More on RTOS

• The system software provides the infrastructure
  and hardware abstraction for the application
  software
• As application complexity grows, a real-time
  kernel can simplify the task of managing the MIPS
  efficiently using a multitasking design model

40
More on RTOS

• The developer also has access the a standard set
  of interfaces for performing I/O as well as
  handling hardware interrupts
• A RTOS also provides the capability to define and
  configure system memory efficiently

41
More on RTOS

• Overall structure of a multitasking design
  paradigm adds to the application and makes it
  easier to scale and maintain larger applications
• Migration to next generation processors is also
  easier because of the hardware abstraction
  provided by a real-time kernel and associated
  peripheral support software

42
More on RTOS

• RTOSs have very low interrupt latency
• Because many embedded systems interface with the
  external environment, they are event or interrupt
  driven
• Low overhead in handling interrupts is very
  important for embedded systems

43
More on RTOS

• RTOSs also ensure that the amount of time
  interrupts are disabled is as short as possible
• When interrupts are disabled (context switching,
  etc) the CPU cannot respond to the environment
• A RTOS also has very high performance device
  independent I/O

44
More on RTOS

• This involves basic I/O capability for
  interacting with devices and other threads
• This I/O should also be asynchronous, have low
  overhead, and be deterministic in the sense that
  the completion time for an I/O transfer should
  not be dependent on the data size

45
More on RTOS

• A RTOS must also have specialized memory
  management
• Capability to align memory allocations and
  multiple heaps with very low space overhead is
  important
• The RTOS will also have the capability to
  interface to the different types of memory that
  may be found in an embedded (DSP) system,
  including SRAM, SDRAM, fast on chip memory, etc.

46
Adopting a new design paradigm

• In the early days of real-time, much of the
  software written was low level assembly language
  that ran in a loop performing a relatively small
  set of functions
• Several potential problems with this approach
• The algorithms could be running at different
  rates. This makes scheduling the system
  difficult using a polling approach

47
Adopting a new design paradigm

• Some algorithms could overshadow other
  algorithms, effectively starving them
• With no resource management, some algorithms
  could never run
• There are no guarantees of meeting real-time
  deadlines
• Polling in the fashion described is
  non-deterministic

48
Adopting a new design paradigm

• The time it takes to go through the loop may be
  different each time because the demands may
  change dynamically
• Non-deterministic timing
• No or difficult interrupt pre-emption
• Unmanaged interrupt context switch
• Super loop approach is a poor overall design
  approach

49
Traditional approach
50
Adopting a new design paradigm

• As application complexity has grown, the
  processor is now required to perform very complex
  concurrent processing tasks at various rates
• A simple polling loop to respond to these rates
  has become obsolete
• Modern applications must respond quickly to many
  external events, be able to prioritize
  processing, and perform many tasks at once

51
Adopting a new design paradigm

• These complex applications are also changing
  rapidly over time, responding to ever changing
  market conditions
• Time to market has become more important than
  ever
• Developers must now be able to develop
  applications that are maintainable, portable,
  reusable, and scalable

52
Adopting a new design paradigm

• Modern system are managed by real-time operating
  systems that manage multiple tasks, service
  events from the environment based on an interrupt
  structure, and effectively manage the system
  resources

53
Multithreaded approach
54
Priority levels for RTOS
Real-time Operating system
High-priority processing
Round-robin with interrupts
Round-robin
Device A ISR
Device A ISR
Device B ISR
Device .. ISR
Device C ISR
Device Z ISR
everything
Device .. ISR
Task Code 1
Device Z ISR
Task Code 2
Low-priority processing
All task code
Task Code 3
55
Characteristics of various S/W architectures
56
Characteristics of various S/W architectures
57
SE 746-NT Embedded Software Systems
Development Robert Oshana End of
lecture For more information, please
contact NTU Tape Orders NTU Media
Services [phone]
oshana_at_airmail.net
tapeorders_at_ntu.edu