ICS 213 Fall 2002 Prof' Rajesh Gupta Low Level Programming for Embedded Systems

1
ICS 213 Fall 2002 Prof. Rajesh GuptaLow Level
Programming for Embedded Systems

• Rajesh Gupta
• University of California, Irvine

2
System Characteristics

• Complexity in function (and in size)
• Concurrent control of separate components
• devices operate in parallel
• Facilities to interact with special purpose
  hardware
• need to program devices in a reliable and
  abstract way
• High reliability and safety
• failure has severe life, environmental and
  economic consequences
• Guaranteed response times
• predictability is important sometimes more so
  than efficiency.

3
Low Level Programming

• Problem addressed
• how do we extend/modify process and communication
  models to enable modeling and control of
  devices?
• Review 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.
• Reference BW, Chapter 15.

4
Basic Input/Output Mechanisms

• Two general classes

5
Device Interface

• Interface using registers
• separate memory versus I/O accesses using
  separate assembly instructions (e.g., Intel 486)
• main memory versus IO space
• in memory-mapped I/O, a part of the memory is
  mapped to device registers (e.g., Moto M68K)
• 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.

6
Device Interface Basics

• Interface Timing
• Synchronous vs. Asynchronous Interface
• Polling, Interrupts, and DMA

7
Interface Timing

• Two types of CPU-Component interfacing
• Memory Interface Read/Write
• Peripheral Interface Memory-Mapped I/O or
  Separate I/O
• 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

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

9
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

10
An Example Timing Diagram (D-F/F)
11
An Example Protocol Diagram (Memory Read)
12
Parameter Table (68K memory read)
13
Processor Memory/Peripheral Interface

• Address bus
• 23-bit -gt 223 16-bit words to be addressed,
  interrupt (A01-A03)
• can be driven when DMA, multiprocessor system
• Data bus
• 8-bit or 16-bit data transfer (bidirectional)
• interrupt vector number on D00 to D07
• 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

14
Processor Mem/Peri Interface (contd)

• 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

15
Synchronous vs. Asynchronous
Synchronous
Asynchronous (handshake)
16
Memory Mapped I/O vs. Dedicated I/O

• Memory mapped I/O
• Motorola style.
• No distinction between memory space and I/O space
  (R/W)
• Dedicated (Separate) I/O
• Intel style
• Separate memory space (MemR/MemW) and I/O space
  (IN/OUT)
• Pros and Cons (of MM IO)
• 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

17
Basic I/O Techniques

• Programmed I/O (timed I/O, CPU-initiated I/O)
• CPU examines the status of the I/O device to see
  if its ready.
• CPU exchanges data with I/O devices via CPU
  register.
• Polled I/O
• CPU checks the status on a regular basis.
• CPU time is wasted for status check.
• Direct I/O very simple device, no status
  checking (e.g. LED)
• Interrupt-driven I/O
• Same data transfer mechanism as in PIO (I/O
  device reg.)
• Data transfers are initiated by the I/O device
  thru interrupt.
• DMA (Direct Memory Access)
• Problem of Interrupt-driven I/O slow I/O device
  speed
• Removes CPU involvement in the data transfer (I/O
  dev. Mem)

18
Basic I/O Techniques (contd)
19
Sequence of Actions in Interrupt Response
(from Microcomputer Hardware Design by D.
Protopapas)
20
Identification of Interrupting Device

• Polled Interrupt
• have a common interrupt service routine for all
  devices
• the interrupt service routine checks the status
  of each device in turn (high software overhead)
• Vectored Interrupt
• CPU obtains a vector number from the interrupting
  device.
• Device responds to an IACK by providing a vector
  number on D00-D07 and asserting DTACK.
• Autovectored Interrupt
• Older devices for 8-bit processor cannot provide
  vector numbers.
• If VPA is asserted at IACK cycle, the 68000
  carries out autovectored interrupt.
• Internally, the 68000 generates the appropriate
  vector number.
• 19h-1Fh reserved for autovectored interrupt

21
Vectored vs. Autovectored
22
DMA

• Removes CPU-I/O device bottleneck
• Data transfer rate the order of 10-50Mbytes/s.
• DMAC A coprocessor for DMA process (third party
  DMA)
• Register set address reg., count reg., status
  control reg.
• Bus request (BR) Bus grant (BG)
• Burst mode vs. Cycle stealing
• Burst mode keep the bus until the whole block is
  transferred (for fast I/O device)
• Cycle stealing steals a CPU cycle, and transfer
  a word at a time.
• Bus mastering (first party DMA)
• An enhancement of DMA
• I/O device not only can send the data to the
  memory, but also can take the control of the bus
  (w/o DMAC)

23
A DMA Transaction Flow
24
Programming Language Needs
25
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
• determine status of a device
• control operations
• perform non-transfer device dependent actions
• I/O operations
• perform actual transfer of data between device
  and CPU

26
Interrupt-driven control

• Interrupt-driven control is more common
• three types
• interrupt-driven program-controlled
• interrupt-driven program-initiated (DMA)
• interrupt-driven channel-program controlled
• DMA and Channel programs can cause cycle stealing
  from the processor. This may make it difficult to
  estimate the WCET of a program.

27
Interrupt-driven devices

• Needed HW support (also supplemented by explicit
  SW)
• context switching mechanisms
• preserve the state, place processor in new state,
  restore suspended process after interrupt
  processing is complete.
• Range from basic (only PC), partial (PC and PSW)
  and complete (full context is saved).
• 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.
• Often interrupt handling associated with a
  high-level language primitive
• an interrupt is often viewed as a synchronization
  message down an associated channel. Device
  identified by the active channel.

28
Interrupt-driven Control (contd.)

• Mechanisms needed (continued)
• 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
• through flags (in status mechanisms) or mask
  interrupt control mechanisms that associate
  device interrupts with particular locations in an
  interrupt mask word or level interrupt control
  mechanisms.
• priority control
• static or dynamic.

29
Example I/O

• Memory-mapped control/status registers (68K)
• CSR registers contain all info on device status
• data buffer registers for temporarily storing
  device data
• 15-8 bits unused 7-0 data
• a device may have more than one CSR and DBR

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 enable
30
Example continued

• On interrupt
• processor stores PC and PSW on the system stack
• PSW layout
• new PC and PSW loaded from interrupt vector
• 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
31
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.

32
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 a communications channel
• Need suitable representation of interrupts
• procedure call
• interrupt is viewed as a procedure call, an RPC
  coming from device process
• 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.

33
Abstract Modeling (contd)

• Interrupt representation (contd)
• Asynchronous event to a process
• the interrupt handler has access to local state
  of the process and global data
• Shared variable condition synchronization
• signal on a semaphore
• message based synchronization
• a contentless message on a channel (Occam)
• All except procedure call require full context
  switch
• since the handler executes within the scope of a
  process

34
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
• Ada
• hybrid between procedural and shared memory model
• protected procedure calls represent interrupts,
  variables used for device registers
• Modula-1 ( RT Euclid)
• shared memory model
• modula-1 maps condition variables to interrupts
• RT Euclid uses semaphores
• Occam2
• message-based model
• devices as ports interrupts are messages over a
  channel.

35
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
• 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 /
36
Device Driving in Ada

• Facilities for addressing and manipulating device
  registers
• through REPRESENTATION CLAUSES
• A representation clause can be
• attribute definition clause size, alignment,
  storage space for tasks, address
• enumeration representation clause internal
  values for literals
• record representation clause offsets and lengths
  of components

37
Representation Clauses

• Record representation clause
• specifies the storage representation of records
  that is, the order, position and size of its
  components.

38
Register definition and use
39
Ada Interrupt Handling

• The occurrence of an interrupt (HW or SW)
  consists of
• interrupt generation
• underlying hw/sw mechanism that makes an
  interrupt available to the program
• interrupt delivery
• action that invokes a part of the program
  (interrupt handler)
• In between generation and delivery, the interrupt
  is blocked.
• The handler is invoked once for each delivery of
  an interrupt
• when blocked all future occurrences are
  prevented.
• Reserved interrupts
• e.g., clock interrupt used to implement the delay
  statement.
• Each non-reserved interrupt has a default handler
  assigned by the runtime system
• ceiling priorities are used in interrupt priority.

40
Example

• An ADC that as a 16-bit result register at
  hardware address 8150000 and a control register
  at 8150002
• 16-bit machine with CSR
• Driver as a protected type within a package, so
  that its interrupt processed as a protected
  procedure call
• allows more than one ADC handling.

41
(No Transcript)
42
(No Transcript)
43
Summary

• High-level programming of device drivers requires
• ability to pass data to and from the device
• ability to handle interrupts
• Control and data information is passes via device
  registers
• accessible through memory or IO
• Interrupt handling requires context switching,
  device, interrupt identification and control,
  prioritization
• Abstract model of device handling is necessary
  for HL programming.