EMBEDDED SOFTWARE

1
EMBEDDED SOFTWARE

• A Whirlwind tour of Embedded Software
• Rajesh Gupta
• University of California, San Diego.

mesl . ucsd . edu
2
Outline

• Introduction
• Programming in the large
• Programming language support for time, space
• Programming in the small
• Scheduling, real-time OS
• Software performance estimation and optimizations
• Key TakeAway Messages

3
ESW is diverse with different tools and styles

• Portable cassette player Cost
• Easy to describe functionality, limited RAM,
  assembler
• Use 4-bit or 8-bit mc with on-chip RAM, ROM, IO
• hand-coded assembly single task, plus may be
  some interrupt service routines 1K-8K bytes of
  code
• Handheld remote terminal Functionality
• More functionality, require some documentation,
  debuggers and simulators
• Use 16- or 32-bit mc w/ on/off-chip memory and IO
• mixture of C and assembly gt1 task, some
  time-critical, 64KB to 1MB

4
Some more examples

• Air-traffic control Security, reliability
• Functionality is often formally (legally)
  specified, ADA code development with standards
• Most are derivatives of desktop systems (32, 64
  bit)
• Full OS, distributed environment multiple and
  redundant tasks many mega bytes of code
• Wireless modem Performance
• Simple but demanding functionality, abstract
  specifications, custom development environment
  (integration with HW design tools, co-design)
• Custom ASIP processor
• Custom software development and RT environments.

5
Changing Mindset in ESW

• A CAD state of mind 1990s
• Automated software synthesis from specifications
• Synthesis tools generate implementation
• Global optimization of the program.
• One-time compilation costs.
• Optimization used to achieve design goals.
• Code compression
• Optimization for power
• Instruction-set generation
• Static memory allocation
• Analysis and verification tools for feedback.

6
Changing Mindsetscontd.

• The Need for Abstractions Y2K and continuing
• At pretty much all levels language, OS,
  middleware, (even firmware)
• Consider languages
• Interpreted, compiled, semi-compiled
• Consider compilers a 3-step learning process
• Compiled code is too slow
• Machines are fast
• Compiler does it better anyway

Now consider sensor nodes 1. Still manually
programming 2. Step 2 is still ways away energy,
size
7
Performance of semi-compiled languages beating
out expectations

• Java ? bytecode ? JVM
• .NET ? MSIL ? CLR
• Compelling reasons to take this route
• Distributed resource management, type safety and
  yet extensibility, virtualization, dynamic
  deployments and updates

Java virtually identical to Visual C, GCC
C Interpreted slower by 60x
http//www.osnews.com/story.php?news_id5602
8
Notable attempts at ESW Abstractions Sensor Nets

• TinyDB
• use queries as programming interface
• Abstract regions
• Program collections at a higher layer than
  sending messages
• Reliable Multi-Hop State Sync
• Publish and update structures over lossy nets
• An attempt to move away from the need to ship all
  the sensor data
• Adaptive networks and in network processing
• Example Self-healing networks -- nodes localize
  themselves within 1m, MOVE to fill in gaps

9
But the new world is harder!
Real-World Sensor Inputs
Distributed Robotics
Robotics
Sensor Networks
Timing- Dependent Data
OS Kernels/ Device Drivers
TCP
Data Uncertainty
Squid
MS Word
MPI/Linda
cat
Text
Distributed, Timing Dependent System
Single- or Few- Threaded
Multi-Threaded
System Uncertainty
Jeremy Elson, Microsoft
10
Multiple Shifts In Progress Programming with Time

• E. G., Computing at the intersection of two
  different time topologies

/ monitor temperature / do forever measure
temp if (temp lt setting) start
furnace else if (temp gt setting delta)
stop furnace
/ monitor time of day / do forever measure
time if (600am) setting 72
else if (1100pm) setting 60
/ monitor keypad / do forever check
keypad if (raise temp) setting
else if (lower temp) setting--
11
Programming with Location

• Enabled by technology advances
• Outdoor, indoor, absolute, relative, assertive
• Infrastructure for location
• Dynamic resource discovery and binding
• Transparent location updates
• Monitor resources in their environment
• Virtual resource naming, that is, resources
  referred to based on their expected location
• Reactive to changes in the resource availability
• Control resource usage access timeouts.
• Programming with location
• Spatial programming how to use the location
  information in spatial references

12
Consider Time Example 1

• Goal
• Maintain a given flow set point (rate of flow)
  despite changing environmental conditions.
• Varying level of the liquid in the vessel.
• temperature of the fluid (affecting its
  viscosity)
• The computer controls the plant by setting the
  position of the control valve.
• Flow sensor is used to determine the effect of
  the control.

13
Real Time Control

• Dynamics Stability of the control is the main
  issue.
• When the control valve must be activated, and by
  how much influenced by
• Valve takes 10 seconds to go from 0 closed
  (open) to 100 closed (open).
• Flow sensors precision is 1. Sampling interval
  100 msecs.
• Output action by the controller will effect the
  environment after a delay (?1).
• Observing the effect on the environment will
  involve a delay introduced by the sensor (?2).
• Embedded Control Software Measure or derive
  these delays to implement the temporal control
  structure..
• (not only control theory but also PL issues)

14
Engine Control

• Goal
• Calculate the amount of fuel and the moment at
  which this fuel must be injected into the
  combustion chamber of each cylinder.
• Fuel amount and injection time depend on
• Intentions of the driver (position of the
  accelerator pedal)
• Current load on the engine
• Temperature of the engine
• The position of the piston in the cylinder
• Many more conditions.

15
Engine Control

• The dynamics
• the position of the piston indicated by the
  measured angular position of the crankshaft.
• Precision required 0.1 degree
• At 6000 rpm, 10 millisecs for each 360 degree
  rotation.
• temporal accuracy (sensing when the crankshaft
  has passed a particular position)
• 3 ?secs.

16
Engine Control

• Fuel injection by opening a solenoid valve
• Delay from the time open command issued by the
  computing system and the time at which valve
  opens
• hundreds of ? seconds!
• Changes depending on environmental conditions
• Temperature, .
• This delay is measured each cycle and used to
  compute when the next open command to be issued
  so that fuel is injected at the right time.
• Precise temporal control is required.
• Incorrect control can damage the engine!
• Upto 100 concurrently executing software tasks
  must run in tight synchronization.

17
Generalized Embedded Computer Another View
Real Time Clock
Interface
Engineering System
Algorithms for digital control
Data logging
Remote Monitoring System
Database
Data retrieval display
Display
Operator interface
Operators console
18
Outline

• Introduction
• Programming in the large
• Programming in the small
• Programming language support for time, space
• Scheduling, real-time OS
• Visions

19
Programming in the large

• Programming Language support for embedded systems
• Take three different example language to present
  different approaches ADA, C and OCCAM2
• Major PITL issues
• Modularity and Abstraction
• Fault tolerance and error recovery exception
  handling
• Provable correctness and validation

20
Programming Languages w/ Time

• Sequential systems implementation languages
• Assembly languages
• RTL/2, Coral 66, Jovial, C.
• these require support from the operating system
  for RT modeling
• Concurrent languages
• Ada (Ada95), Modula, C/C extensions, RT POSIX,
  Occam2
• RT programming languages include facilities to
  interact directly with the underlying hardware
• unlike general purpose programming languages that
  rely on OS abstractions.

21
OS Interaction
Burns and Wellings
22
Programming Issues by Examples

• We shall consider three different languages to
  highlight important aspects of RT programming
• Ada
• Used in safety critical systems
• A language in which concurrent programs can be
  written
• C
• Because it is C (popular)
• A sequential language, concurrency through OS
  processes
• OCCAM2
• Language no one uses, (but should?)
• Modeled after CSP
• A concurrent programming language

23
Style

• All three are block structured
• Description consists of blocks
• What blocks represent varies
• For instance, a block in ADA consists of
• Declaration of objects
• Sequence of statements
• Collection of exception handlers
• A block in C consists of
• Declarations
• Sequence of statements

24
Ada

• An Ada program consists of one or more program
  units
• a subprogram (procedure or function) -- can be
  generic
• a package (may be generic) used for encapsulation
  and modularity
• a task -- used for concurrency
• a protected unit - a data-oriented
  synchronization mechanism
• Library units package, subprogram
• Subunits subprogram, package, task, protected
  unit.

25
Blocks

• declare
• - definitions of types, objects
• - subprograms etc.
• begin
• - sequence of statements
• exception
• - exception handlers
• end
• a block can be placed anywhere a statement can be
  placed.

26
Scopes

• Objects declared in a block may only be used in
  that block
• any statement in the sequence of statement may
  itself be a block
• exception handlers can be used to trap errors
• function Largest(X Vector) return Integer is
• max Integer 0
• begin
• for I in Xrange loop
• for X(I) gt Max then
• Max X(I)
• end if
• end loop
• return Max
• end Largest

27
C

• Sequential, main structuring through functions (
  files)
• Block structured (called compound statements)
• ltdeclarative partgt
• ltsequence of statementsgt
• declarative part can not contain functions
• sequence of statements can contain compound
  statements

28
Occam2

• Process oriented instead of statement oriented
• Sequence of process is equivalent to sequence of
  statements
• Syntax
• each process on a separate line
• declaration terminates with a colon ()
• indentation is important

Last two lines make sure that IF does not become
STOP when A is 0.
29
Data Types

• All three languages (Ada, C, Occam2) manipulate
  objects abstracted from their actual hardware
  implementation.
• Ada constants, types, variables, subprograms,
  packages
• C constants, types, variables, functions
• Occam2 INT, INT16, INT32, INT64, BOOL, BYTE
• more restrictive, since user-defined types are
  not allowed.
• Ada, Occam2 are strongly types, C is a bit
  loose
• Enumerated types
• C constants must be uniquely defined
• Ada names can be overloaded
• both languages allow manipulation of enumerated
  types
• C by the standard integer operations
• Ada by use of attributes

30
Types Continued

• Real Numbers
• can be represented either as a floating-point
  number
• M x RE
• divergence between a fp number and its real value
  is relative error (related to the size of the
  number)
• single or double precision (built in)
• or as a scaled integer
• a product of an integer and a scale
• scales are known at compile time
• divergence between a scaled integer and its real
  value is an absolute error
• user defined arithmetic (i.e., left to the
  programmer)
• Ada, C use float for implementation dependent
  (sp) fl
• Occam2 reals are REAL16, REAL32, REAL64 that
  explicitly specify the number of bits

31
Example Ada

• FP numbers
• type New_Float is digits 10 range
  -1.0E18..1.0E18
• A subtype of this type can restrict the range or
  the precision
• subtype Crude_Float is New_Float digits 2
• subtype P_New_Float is New_Floa range
  0.0..1000.0
• Fixed point numbers as scaled integers
• type Scaled_Int is delta 0.05 range
  -100.00..100.00
• defines absolute error bound delta of 0.05
• the number of bits can be calculated from the
  range and delta
• five bits for the fraction (1/20) (nearest is
  1/32)
• eight bits for the range (including sign)

32
Structured Data Types

• Ada, C arrays and records
• Occam2 arrays
• INT Max IS 10
• a constant
• Max REAL32 Reading
• Reading is an array with 10 elements.
• Dynamic Data Types
• requires a memory allocation facility at runtime,
  has overheads
• Occam2 does not provide any dynamic data
  structures
• C allows pointers to objects
• Ada an access type is used (similar to
  pointer)

33
Example Access Type in ADA

• type Node
• type Ac is access Node
• type Node is
• record
• Value Integer
• Next Ac
• end record
• V Integer A1 Ac
• begin
• A1 new Node
• A1.Value V
• A1.Next null
• ...

34
Building ES Software Systems

• Decomposition
• systematic breakdown of a system into smaller
  parts
• supported by modules, packages, separate
  compilation
• top-down design
• Abstraction
• allows detailed consideration of components to be
  postponed yet enables the essential part of the
  component to be specified
• bottom-up design

35
How to decompose large systems?

• Decompose them into Modules
• a collection of logically related objects and
  operations
• use encapsulation
• Encapsulation
• technique of isolating a system function within a
  module with a precise specification of the
  interface
• With modules, one can support
• information hiding
• separate compilation
• abstract data types

36
1 Information Hiding

• A module structure supports reduced visibility by
  allowing information to be hidden inside the body
• The specification and body of a module can be
  given separately
• Ideally, the specification should be compilable
  without the body being written
• e.g., in Ada, there is a package specification
  and a package body and a formal relationship
  between the two. (Compile time error detection)
• In C, modules are not so well formalized.
• Use separate header (.h) files to contain the
  interface to a module and a .c file for the body.
  No formal relationship, therefore errors are
  caught at link time.
• Modules are not first class language entities.

37
Module Specification and Body

• Specification
• Only objects declared here are visible externally
• May also be a place holder to verification checks
• Assertions, invariants (a la, passive process in
  VHDL)
• Ada uses Open Scoping
• All identifiers visible at the point of the
  package declaration can be accessed within the
  package
• For access outside the package, use prefixing by
  the package identifier (MyPackage.Function)
• Can simplify it by using use declarations.
• Even though important, Modules are not first
  class entities
• Module types can not be defined pointers to
  modules can not be created, and so on.

38
2 Separate Compilation

• Modules can be compiled separately (into a
  library)
• Both in Ada and C, a package (module)
  specification and body can be (pre)compiled
• A library can access another library
• Using with with clause or include
• Separate compilation supports bottom up
  programming
• Useful in a top down design as well
• Ada supports it further by is separate clause
  (that allows a procedure to be added later)
• In Ada, separate compilation is supported by the
  language
• That is, its typing rules apply equally across
  libraries
• In C, comprehensive type checking is not possible
• Though one can lint it.

39
3 Abstract Data Types

• A module can define both a type and the
  operations on the type.
• Details of the type must be hidden from the user.
• As modules are not first class, the type must be
  declared
• and instances of the type passed as a parameter
  to the operation.

40
ADT and Separate Compilation

• ADT is complicated by the requirement for
  separate compilation of a module specification
  from its body
• Since the structure of the ADT is meant to be
  hidden, it is logically in the module body
• But then the compiler would not know the size of
  the type when using only its specification
• Remedy force the programmer to use a level of
  indirection
• To ensure the user is not aware of the details of
  the type, it is passed as a pointer (as in C).
• An incomplete declaration of the type is given in
  the .h file.

41
Example A Queue module interface in C

• typedef int element
• struct queue_t
• typedef struct queue_t queue_ptr_t
• queue_ptr_t create()
• int empty(queue_ptr_t Q)
• void insertE(queue_ptr_t Q, element E)
• void removeE(queue_ptr_t Q, element E)

include queue.h struct queue_node_t
element contents struct queue_node_t
next struct queue_t struct queue_node_t
front struct queue_node_t back queue_ptr_
t create()
42
ADT and Separate Compilation

• While forcing a pointer to the structure of an
  ADT type in the module body works, it is not
  always clear
• Ada also allows part of the implementation to
  appear in the specification
• But it is accessible only from the package body
• It is called the private part of the
  specification.

43
Package body Queuemod is --- End Queuemod

• Package Queuemod is
• type Queue is limited private
• procedure Create (Q in out Queue)
• function Empty (Q Queue) return Boolean
• procedure Insert (
• procedure Remove (
• Private
• type Queueptr is access Queuenode
• type Queuenode is
• record
• contents processID
• next Queueptr
• end record
• type Queue is
• record
• Front Queueptr
• Back Queueptr
• end record
• End Queuemod

44
OOP and abstract data types

• OOP includes
• type extensibility (inheritance)
• automatic object initialization (constructors)
• automatic object finalization (destructors)
• run-time dispatching of operations (polymorphism)
• Ada95 supports the above through tagged types and
  class-wide programming
• C supports OOP through the use of classes.

45
PITL Key Take Aways

• Module supports
• information hiding, separate compilation, and
  ADTs
• Ada and C have a static module structure
• C informally supports modules C has a dynamic
  module structure called a class
• Both packages in Ada and classes in C have
  well-defined specifications which act as the
  interface between the module and the rest of the
  program.
• Separate compilation enables libraries of
  precompiled components to be constructed.

46
Outline

• Introduction
• Programming in the large
• Programming language support for time, space
  Programming in the small
• Scheduling, real-time OS
• Visions

47
Outline

• The notion of time in programming
• Time facilities
• access to a clock
• delays and timeouts
• timing requirements
• temporal scopes
• Language support for time

48
Real Time Facilities

• Generally RT facilities in programming are built
  on top of concurrency mechanisms
• There are three parts to handling of time in a
  programming language
• Interfacing with time
• E.g., access clock so that passage of time can be
  measured
• Delaying processes until some future time
• Programming timeouts for recognizing
  non-occurrence
• Representing timing requirements
• Execution deadlines, rates
• Satisfying timing requirements

49
The Notion of Time

• Primary purpose of time is to ensure ordering of
  events
• Temporal versus Causal Ordering
• Topology of time
• Equate passage of time with a real line
• Time is Transitive, Linear, Irreflexive, Dense

50
1 Access to a clock

• One of two ways
• Direct access to environmental time
• An internal approximation
• Direct access to environmental time
• Environment supplies a regular interrupt that is
  clocked internally
• Or use a global time UTC, IAT signals
• (GPS uses UTC service)
• From the pov of a PL, time access can be by
• A clock primitive in the language, or
• Via a device driver for the internal clock,
  external clock or radio receiver
• Let us consider some examples

51
Example ANSI C

• ANSI C provides a standard library for
  interfacing with time
• Basic time type time_t
• Several routines for manipulating objects of type
  time_t
• (Interface to ANSI C dates and time)
• tv_sec number of seconds since 1/1/1970

52
POSIX

• Allows many clocks to be supported by an
  implementation
• Each clock has its own identifier (of type
  clockid_t)
• IEEE standard requires at least one clock be
  supported, CLOCK_REALTIME
• Minimum resolution of CLOCK_REALTIME is 50 Hz or
  20 ms
• C interface to POSIX clocks

53
Example Times in OCCAM2

• Any occam2 process can obtain value of the
  local clock by reading from a TIMER
• Each process must use a distinct TIMER
• Reading from a TIMER is similar to channel read
• Except that it can not block
• Single integer for clock value

Timer Granularities
54
Example Clock packages in ADA

• Library package called Calendar and optional
  real-time facility
• This package implements an ADT for time
• Provides function clock for reading time
• Type duration is a predefined fixed point real
• Both its accuracy and its range are
  implementation dependent, though..
• Covers at least the number of seconds in a day
  with a granularity of less than 20 ms
• Library package Real_Time
• Similar to Calendar but finer granularity
• Tick less than 1 ms the range of Time (from
  the epoch that represents the programs startup)
  at least 50 years.
• Real_Time is defined to be monotonic
• Not so with Calendar (leap years etc).

55
(No Transcript)
56
(No Transcript)
57
2 Delays and Timeouts

• Processes must be able to delay their execution
  for a
• Relative time
• Or until some time in the future
• Relative delays
• Obvious thing is to busy wait
• To avoid this, language must provide a delay
  primitive
• ADA delay 10.0
• POSIX sleep system call

58
Delay guarantees

• Only that the process is made runnable after the
  period has expired
• The actual delay may vary (other processes)
• Also, the granularity of delay and the
  granularity of clock are not necessarily the same

59
Programming Absolute Delays

• If a delay to an absolute time is needed then
• Either the programmer calculates the period to
  delay, or
• An additional primitive is needed.
• Example
• But this may not achieve the desired result
• Delay will have to be an uninterruptible action
• ADA remedy delay until
• Accurate only in its lower bound.

60
Drift

• Drift is the time over-run in programming delays
• Local drift
• Cumulative drift
• While local drift may not be eliminated, it is
  possible to eliminate the cumulative drift
• Example if two Actions are 7.5 sec apart, the
  next ones will be delayed only 6.5 sec

61
OCCAM2 and POSIX

• OCCAM2 supports only absolute delays
• Use the keyword AFTER
• SEQ
• Clock ? Now
• Clock ? AFTER now PLUS (10 G)
• POSIX
• Absolute delays possible using an absolute timer
  and waiting for the signal generated when it
  expires.

62
Programming Timeouts

• A timeout is a restriction on the time a process
  is prepared to wait for a communication
• Closely tied to communication and synchronization
  schemes available
• By definition these require waiting (for
  communication, conditions)
• Two important aspects in the communication
  synchronization schemes
• Mutually exclusive access to a critical section
  (mutex)
• Condition synchronization
• Communication and synchronization (CS) based on
• Shared Variables
• Message Passing

63
Shared Variable CS and Timeouts

• Mutually exclusive access to a critical section
• When a process attempts access to a shared
  critical region, it is blocked if another process
  is already active
• But this blocking is bounded by the time taken to
  execute the code of the section and the number of
  other processes that also wish to execute the
  critical section
• Blocking time can be analyzed and estimated
• Hence, no explicit timeout associated with
  attempted entry
• On the other hand, blocking with condition
  synchronization is not easily bounded
• E.g., a process attempting to place data in a
  full buffer must wait..
• Therefore, it is important to allow a process to
  opt out of waiting for condition synchronization

64
S.V. Condition Synchronization Facilities

• The condition synchronization facilities that can
  be used for timeouts
• Semaphores
• Conditional critical regions
• Condition variables in monitors and mutexes
• Entries in protected objects
• Example a process could suspend itself on the
  semaphore CALL with a timeout value to 10 secs.
• POSIX supports semaphores but does not provide an
  explicit timeout option
• But wait is interruptible by a POSIX signal
• With POSIX condition variables, the it is
  possible to associate timeouts (through specific
  system calls)
• Protected objects in Ada can have associated
  timeouts (as with any task entry call)
• Covered in message passing based CS.

65
Message Passing CS and Timeouts

• Inherently blocking, needs explicit programming
  of timeouts
• In Ada, you can do that by programming a task
  that delays itself for the timeout period.

66
Better Alternative using Selective Waits

• Use delay as an alternative to a call
• Special form of a select statement
• A timed entry call
• A timeout specified with the call being accepted

67
Timeout Events

• A timeout can be treated as an event
• If asynchronous events are supported then these
  events can be used to change control flow in
  processes
• SIGNALs in POSIX are mainly asynchronous events
• Example
• Asynchronous Transfer of Control (ATC) facility
  in Ada to catch runaway code
• select
• delay 0.1
• then abort
• -- action
• end select
• Timeouts can also be used to support imprecise
  computations
• Compulsory and optional part
• Associate a timeout with the optional part.

68
Specifying Timing Requirements

• Types of timing requirements
• Interval bounds
• Throughput bounds
• Captured as binary relations among operations
• E.g., Timing Graph
• Timing requirements capture
• As a part of function or independently
• Types of checks
• Consistency
• Feasibility, Satisfiability
• Satisfiable by an implementation
• Transformations to ensure satisfiability
• Example Timing Graphs

69
Temporal Scopes

• A TS identifies a collection of statements with
  an associated timing constraint
• Components of a TS
• Deadline
• Min delay
• Max delay
• Max execution time
• Max elapsed time
• TS can be
• Periodic
• Sample data, execute control loop and have
  explicit deadlines
• Aperiodic
• From asynchronous events outside of the embedded
  computer
• Response time requirements

70
TS and Deadlines

• Periodic, aperiodic, sporadic
• Hard, Soft, Interactive, Firm
• Hard if it fails on missed deadlines
• Interactive strive to achieve adequate response
  time
• A non-hard process with fixed rigid deadline
  (that is, missed deadline is useless (but not
  harmful)) is firm

71
Specifying Temporal Scopes

• Often use attributes and tags
• Example hardware modeling languages
• Time constraints as
• max or min times for IDLE
• Or end of TS by some deadline
• Expressed either as absolute time
• Or as execution time since the start of the TS
• Or elapsed time since the start of the temporal
  scope
• Example a process sampling a data
• Sampling done at the start of the TS, TS contains
  processing (buffering) for this data and deadline
  at the end of TS ensures that the process can
  loop around in time.

72
TS in Aperiodic Processes

• Typically
• When a data passes through a number of processes
• Called a Real-time Transaction
• Deadlines on a RT transactions requires suitable
  partitioning of the time budget and scheduling of
  the processes
• In general, a very difficult problem.

73
Fault Tolerance and Timing Requirements

• In a hard system, a missed deadline must trigger
  error recovery mechanisms
• Source of error
• Inaccurate timing estimates
• Inadequate schedulability analysis
• Error in schedulability analysis
• System working outside its design parameters
• Some systems may be designed to anticipate such
  situations and incorporate mode changes
• Environmental change may obviate the need for
  some computation

74
Forward Error Recovery

• If the RT is aware of deadlines then
• It can recognize situations in which deadlines
  are missed
• May be able to predict such situations
• Provide mechanisms to inform the application that
  a missed deadline event has occurred
• Exceptions provide a natural means of such a
  dialogue
• The handlers must be able to make important
  distinctions in error sources
• Overrun deadlines, overrun execution times,
  timeouts on communications, other non-temporal
  error conditions
• Error recovery may require extension of the
  original deadline and continue execution of the
  original block
• Resumption is generally preferred over the
  termination model.

75
Event-based Reconfiguration

• With applications prone to mode changes, a
  process (client) may want to change the control
  flow in another (server) process while the
  computation is ongoing.
• This reconfiguration may require that the server
• Immediately return the best result so far
• Change to a quicker (may be less accurate)
  algorithm
• Forget the current computation and be ready to
  undertake new computation restart without
  reload
• These responses may be captured by the type of
  the asynchronous event (exception) raised.

76
Backward Error Recovery

• BER involves acceptance tests
• Therefore, one can include timing requirements as
  a part of the acceptance tests
• The runtime system may fail on an acceptance test
  if the deadline has been overrun
• Example dialogues
• Specify multiple alternative dialogues within a
  timeout interval
• SO a process tries these alternatives within a
  given deadline, and if it does not succeed the
  execution does not move forward

77
Example
78
Outline

• Introduction
• Programming in the large
• Programming language support for time, space
• Programming in the small
• Scheduling, real-time OS
• Visions

79
The Problem and Outline

• Problem addressed
• how do we extend/modify process and communication
  models to enable modeling and control of
  devices?
• Quick review of basic hardware input/output
  mechanisms
• Identify language requirements
• Define various ways of building device drivers
• Examples from Modula-1, Ada, Occam and C for
  device driving.

80
Start from HW Embedded Controllers

• (C/C) programmable controllers sold as single
  board computers (SBC)
• 32-bit controllers typical
• 100/133 MHz system clock
• Floating point unit
• 16/32-bit data, 32 multifunctional IOs
• 1 Synchronous and 2 asynchronous serial ports
• Real-time clock, supervisor, watchdog
• 114-byte CMOS RAM, 7 timer/counters
• 32-bit controllers low end
• 33 MHz system clock, 8/16-bit data, 64 MB memory
• 24 multifunctional IOs
• 1 synch, 2 async serial ports
• Supervisor, watchdog timers
• 512-byte serial EE, 3 timers/counters

81
Embedded Controllers

• 16-bit typical
• 16-bit CPU, 20/40 MHz system clock
• 32 multifunctional IOs
• External interrupts, DMA
• 8/16-bit mode
• 2 asynchronous, 2 PWM serial ports
• 512-byte EE, supervisor, watchdog timers
• 3 16-bit timer/counters

82
Typical Specializations

• Core controller
• Typically no memory system
• Core Data logger
• External flash, typically FAT file system support
• Embedded Engine
• Ability to add memory system
• Many digital IO lines, ADCs
• High Performance Data acquisition
• Multiple ADC channels
• Measured in terms of total ADC throughput (1
  million samples for second for 3 ADCs at 400 KHz)
• Industrial Controller
• High voltage (350 mA _at_ 50V) inputs and outputs
  for interfacing industrial switches, solenoids
  and relays
• ADCs/DACs, ethernet, 232/422/485 ports
• See for instance, http//www.tern.com/

83
Component Interfaces Timing

• Two types of CPU-Component interfacing
• Memory Interface Read/Write
• Peripheral Interface Memory-Mapped I/O or
  Separate I/O

84
Interface Timing

• Modeling
• Timing Diagram and Parameter Table
• Protocol Flowchart
• Challenges in interface design
• Fixed external behavior of off-the-shelf
  components
• Synchronous/Asynchronous/Semi-Synchronous
• Limited availability of control pins, speed
  requirement, etc.
• Min/max timing separations
• Inter-Operational Compatibility
• Optimization for area, delay, and power
  consumption

85
Interface Timing (contd)

• Typical timing problems
• Interfacing fast and slow devices
• Interfacing synchronous and asynchronous devices
• Bus contention
• Avoid indefinite waiting
• Meta-stability
• Timing Verification
• Test whether all the timing requirements are
  satisfied
• Typically, event ordering, event timing
  separation and data setup/hold time are checked.

86
Timing Diagram Protocol Flowchart

• Timing Diagram
• Shows the relationship between the signals
• Ordering, Min/Max separation
• Cause and Effect
• Parameter table for show min/max timing
  relationships
• Principal design tool to enable an engineer to
  match components of different characteristics to
  work together
• Supplemented by protocol flowchart
• Protocol Flowchart
• Abstraction of the timing diagram
• provides only the most essential information w/o
  all detail

87
An Example Timing Diagram (D-F/F)
88
An Example Protocol Diagram (Memory Read)
89
Parameter Table
90
Example

• Asynchronous Bus Control Pins in 68000
• AS the address (on addr bus) is valid
• R/W Read or Write
• normally high to avoid unintentional write
• UDS/LDS upper, lower data strobe for byte
  transfer
• when both asserted word transfer
• DTACK data transfer acknowledge
• Synchronous Control Pins in 68000
• used largely for older (8-bit) peripheral
• VPA (Valid Peripheral Addr) request for
  synchronous bus cycle
• VMA (Valid Memory Addr) 68K informs per.
  device of valid addr
• E (enable) required by all 6800 series
  peripheral, E clock

91
Synchronous vs. Asynchronous
Synchronous
Asynchronous (handshake)
92
Architectural Interfaces to Devices

• Interface using registers
• separate memory versus I/O accesses using
  separate assembly instructions (e.g., Intel x86)
• in memory-mapped I/O, a part of the memory is
  mapped to device registers (e.g., Moto M68K)
• Pros
• Rich set of addressing modes for I/O operation
  (e.g. bit manipulation)
• No overhead on special instructions
• Cons
• Processors address space is allocated to I/O
  devices (64KB in i486)
• Risk of errors due to spurious accesses
  (elaborated address decoding)
• Lack of special purpose I/O signals to control
  the I/O operation
• Interface is used
• to control device functionality
• to control data transfer to/from device
• Control (for data transfer) can be
• status driven or
• interrupt driven.

93
Programming Status Driven Control

• A program performs explicit tests to determine
  status of a device
• Three kinds of hardware instructions that support
  status-driven control
• test operations
• enable the program to determine status of a
  device
• control operations
• direct device to perform non-transfer device
  dependent actions (e.g., positioning read heads)
• I/O operations
• perform the actual transfer of data between
  device and CPU

94
Basic I/O Techniques Programmed, Interrupt, DMA
95
Interrupt-driven control

• Interrupt-driven control is more common
• Three types
• A. interrupt-driven program-controlled
• device interrupts, program suspended, handler
  performs xfer
• B. interrupt-driven program-initiated (DMA)
• though IO is initiated by the program, DMAC
  controls xfer, once complete, use (A) to transfer
  control
• C. interrupt-driven channel-program controlled
• reduces main CPU involvement even further
• devices and hardware channel, channel program, IO
  instructions channel program initiated by
  application.
• Channel program (or scripts) normally consist of
  one or more channel control words that are
  decoded and executed one at a time by the
  channel.
• DMA and Channel programs can cause cycle stealing
  from the processor.
• This may make it difficult to estimate the WCET
  of a program.

96
Elements required to support Interrupt-driven
devices

• Context switching mechanisms
• preserve the state of the processor immediately
  prior to the occurrence of the interrupt
• place processor in new state to process the
  interrupt
• restore suspended process after interrupt
  processing is complete.
• State process and processor
• Memory address of the current (or next)
  instruction
• Program status information (current priority,
  memory protection, allowed interrupts etc.)
• Contents of the programmable registers
• Support for context switching in hardware ranges
  from
• basic (only PC)
• partial (PC and PSW, to other status registers)
• complete (full context is saved).
• It may be necessary to supplement the HW actions
  by explicit SW support
• E.g., partial context switch may be ok for an
  interrupt handling model that views the handler
  as a procedure or subroutine.
• Or the handler can be a separate process (with
  its own stack and data areas)

97
Elements Required (contd.)

• Identification of interrupting-device
• vectored mechanisms
• consists of a set of dedicated, contiguous memory
  locations (interrupt vector) and HW mapping of
  device addresses onto the interrupt vector
• status mechanism
• each interrupt has an associated status word
  which specifies the device and reason for
  interrupt
• polling mechanism
• identification mechanism includes interrogating
  the status of each device.
• With some processors, interrupt handling
  associated with a high-level language primitive
• an interrupt is often viewed as a synchronization
  message down an associated channel.
• So, a device is identified when the associated
  channel becomes active.

98
Elements required (contd.)

• identification of interrupt
• once the interrupting device has been identified,
  the interrupt handling routine must determine why
  it generated the interrupt
• this information can be supplied by either status
  information from the device or by having
  different interrupts from the same device through
  different vectored locations or channels.
• control of interrupt enable/disable interrupts
  by
• status mechanisms that provide flags to
  enable/disable interrupts. These flags may be
  accessible by normal bit-oriented instructions.
• mask interrupt control mechanisms that associate
  device interrupts with particular locations in an
  interrupt mask word. The interrupt mask word may
  be addressable by normal or special instructions.
• level interrupt control mechanisms have devices
  associated with certain levels (that determines
  which devices may or may not interrupt).
• Static or dynamic priority control

99
A Simple Example IO System

• Each device has many different types of registers
  as are necessary for its operation.
• Memory-mapped control/status registers
• Control and Status registers (CSRs) contain all
  info on device status
• Data Buffer Registers (DBRs) for temporarily
  storing device data
• 15-8 bits unused 7-0 data
• a device may have more than one CSR and DBR
• the exact number being dependent on the nature of
  the device.

CSR
bits 15 - 12 Errors 11 Busy 10 - 8 Unit
select 7 Done/ready 6 Interrupt enable 5 -
3 reserved 2 - 1 Device function 0
Device enable0
100
Example continued

• On interrupt
• processor stores PC and PSW on the system stack
• PSW layout
• The condition codes contain information on the
  result of the last processor operation.
• new PC and PSW are loaded from interrupt vector
  (two pre-assigned consecutive memory locations)
• the first word contains the address of the ISR
  and the second word contains the PSW including
  its priority.
• A low priority interrupt handler can be
  interrupted by a higher priority interrupt.

15 - 11 Mode information 10 - 8 Unused 7 -
5 Priority 4 - 0 Condition codes
101
Language Requirements

• Modularity and encapsulation facilities
• portability of application code requires
  separation of machine dependent information
• C file
• Ada package
• Modula-1 devices encapsulated in special modules
• An abstract model of device handling
• device an abstract processor performing some
  (fixed) task
• system set of processes with communication and
  synchronization. Synchronization provided by
  interrupt control.

102
Abstract Models for Device Handling

• Need facilities for addressing, manipulating
  device registers
• A device register may be represented as
• a program variable
• an object
• or (even) as a communications channel
• Need suitable representation of interrupts
• procedure call a remote procedure call from a
  device process
• sporadic process invocation
• asynchronous event
• shared-memory based condition synchronization
• message-based synchronization
• All, except procedure, view the handler as
  executing in the scope of a process, and
  therefore require a full context switch
• Optimizations possible by restricting the handlers

103
Representation of Interrupt

• procedure call
• interrupt is viewed as a procedure call, an RPC
  coming from device process any communication
  synchronization must be programmed into the
  interrupt handler (procedure).
• non-nested procedures only global data or state
  local to the handler is accessible
• sporadic process invocation
• interrupt request to execute a process
• handler is a sporadic process that can access
  both local persistent data as well as global data
  (if shared variable communication is available).
• Asynchronous event to a process
• the interrupt handler has access to local state
  of the process and global data after handling,
  resumption or termination of process.
• Shared variable condition synchronization within
  a shared variable synchronization mechanism
• For example, as a signal operation on a
  semaphore the handler can access both local
  state of the process and the global state.
• Message based synchronization
• a contentless message on a channel (Occam). The
  handler (receiving process) can access the local
  state of the sending process.

104
Various Ways of Building Device Drivers

• C and C
• use a procedural model with variables as device
  registers
• for sequential systems, an asynchronous event
  model is equivalent to the procedural model as
  there is only one process to interrupt
  (therefore, there is no need to identify the
  process)
• Ada
• hybrid between procedural and shared variable
  condition synchronization model
• protected procedure calls represent interrupts,
  variables used for device registers
• Each interrupt has a unique ID supported by the
  system (may be address of the hardware interrupt
  vector)
• Occam2
• message-based model
• devices registers as PORTS
• interrupts are messages over a channel.

105
Device Driving in C

• Device registers are addressed by pointer
  variables which can be assigned to the memory
  location of the register
• Device registers are manipulated by low-level
  bitwise logical operators
• Example unsigned short int reg reg 0AA12
• assign n bits starting at position p in register
  pointed at by reg to x
• interrupt handling
• assign interrupt handler by placing address of a
  parameterless procedure in the appropriate
  interrupt vector location
• explicit communication, synchronization with the
  rest of the program.

unsigned int setbits (unsigned int reg, unsigned
int n, unsigned int p, unsigned int x) unsigned
int data, mask data (x ((0 ltlt n))) ltlt (p)
/ data to be masked in / mask (0 ltlt n) /
mask / reg (mask ltlt (p)) / clear current
bits / reg data / or in data /
106
Device Drivers

• Ada
• Three ways tasks can synchronize and communicate
  with each other
• Through the rendezvous
• Using protected units
• Via shared variables
• Ada assumes that the device and the program have
  access to the shared-memory device registers
• Preferred method of writing device drivers is to
  encapsulate them into a protected unit.

107
Types of Device Drivers

• Basic need
• Ensure mutual exclusivity of device access
• E.g., only one application task can request an
  input or output operation on a specific device
• Typically done using (binary) semaphores
• Sometimes, access is granted on a basis of a
  session
• A session bundles many IO operations.
• Can also be source of unbounded priority
  inversion
• Use mutex, monitors
• Types
• Synchronous, Asynchronous and Hybrid

• Courtesy David Kalinsky, OSE Systems.

108
Synchronous versus Asynchronous

• Synchronous driver
• Requesting task waits for driver IO operation to
  complete
• That is, the RTOS is blocked, or suspended
• Other tasks may continue to execute, ISR may
  continue
• Asynchronous driver
• Requesting tasks continues while driver IO is
  happening

109
Synchronous IO

• Now need two locks (semaphores0
• One for mutex, one for blocking

110
Asynchronous IO

• Requesting tasks processes previous data
• While HW is working on the new data
• Calling task is not blocked
• Overlapped IO and execution
• Need a place to hold data, say, a mailbox.

111
Free-Running Asynchronous Input

• Hardware is now doing repeated interrupts without
  the request from application/driver

112
One Possibility

• Handle only latest input from hardware
• Use a semaphore to protect shared data area
• Problem ISR may not get the semaphore since some
  RTOS disallow ISRs to do P() on a semaphore
• Solution Device driver may disable interrupt

113
Latest input only
114
Asynchronous Output

• Deposit data on a queue

115
Output Spooling
116
Priming Pump?
117
Abstracting Drivers

• Problem
• Each SBC generally comes with its own board
  support package (BSP)
• There are over 450 CPU boards with many processor
  variants
• If you make a peripheral, you have to customize
  its drivers