CS452 - Real-Time Programming - Spring 2012

Lecture 3 - Timers, I/O, Pitfalls

Pubilc Service Annoucements

Due date for assignment 0
Caches, optimization, clock speed, FIFOs
Libraries: memcpy in particular
Some clean-up needed in course account

The Hardware/Software Provided

Provided and maintained by CSCF

Linux systems
- cross compiler: runs on 86_64, produces code for ARM
- GNU toolchain: compiler, assembler, link editor
  - You will notice that my makefile separates
    - compilation to assembly code,
    - assembling the assembly code, and
    - link editing.
- need to login explicitly to linux.student.cs
TFTP servers
- need to type IP number explicitly

TS-7200

Specific documentation from Technologic

System on Chip (SoC)

EP9302, designed and manufactured by Cirrus semiconductor

Memory

Byte addressable, word size 32 bits

32 Mbytes of RAM, starting at 0x00000000
4 Mbytes of flash RAM, starting at 0x60000000
- Contains RedBoot, which is loaded into RAM at startup
Special locations at low addresses
Special locations above 0x80000000
Two types of special location
- Supplied by Technologic: 0x80840000 to 0x80840047
- Suppied by Cirrus:
  - 0x80010000 to 0x8081ffff
  - 0x808a0000 to 0x80900023

Separate instruction and data caches

`COM' ports

Connected to UARTs

RS-232
Actual UART hardware is on the EP9302

Only really two

Ethernet port

Busy wait ethernet code in RedBoot

used by loader to execute TFTP protocol
used by RedBoot, which was customized by Technologic and installed in the Flash RAM

Reset switch

red, even though documentation says black
actually, some are black

EP-9302

Specific documentation from Cirrus

System on chip

ARM 920T core, implementing ARM v4T instruction set
- Specific documentation from ARM
Two co-processors
1. System controller, MMU
  - ARM documentation
2. Maverick Crunch floating point unit
  - Cirrus documentation
Two interrupt controllers
- Both ARM and Cirrus documentation
- An ARM-designed part, the PL-190
Peripherals
1. UARTs
2. Timers
3. DIO
4. A/D
5. etc.

Software

Compiler

GNU tool chain

when you are getting started optimizing is usually a bad idea
software multiplication, division, floating point from libgcc.a
gcc uses a couple of functions like memcpy
Makefile
target.ld

RedBoot

Partial implementation

fconfig :: NOT
load (tftp)
examine, copy, fill memory

Returns when program terminates

Busy-wait IO

COM2 uses monitor; COM1 goes to train

initialization
output
input

Timers

How does one keep time in a computer?

crystal oscillator
interrupts from a timer
ntp

Timers normally count down

You interact with the timer through three registers

Timers available in the EP9302.

Two sixteen bit
One thirty-two bit
One forty bit
One watch-dog

Polling Loops

Polling loops allow you to manage more than one condition/activity pair at the same time.

The basic polling loop

FOREVER {
  if( c1 ) a1;
  if( c2 ) a2;
  ...
  if( cN ) aN;
}

A Few Comments

Shallow computation

Worst case response time

sum over n of {execution time of if( c<n> ) + execution time of a<n>}

What you put into an action matters a lot.

Suppose you put busy-wait I/O to the train controller into an action

Will you catch it in your testing?

Probably not.

When you Miss Deadlines

Testing more than once

Suppose you want a better response time for a1. Then try the loop

FOREVER {
  if( c1 ) a1;
  if( c2 ) a2;
  if( c1 ) a1;
  if( c3 ) a3;
  ...
  if( c1 ) a1;
  if( cN ) aN;
}

Worst case response time for a1

execution time for if( c1 ) + maximum over n of execution time for if( cn ) an

Breaking into pieces

Suppose the response time is still too long, because the execution of one action, say a2, is too long. Then you can break a2 into two parts

FOREVER {
  if( c1 ) a1;
  if( c2 ) { a2.1; half-done = TRUE; }
  if( c1 ) a1;
  if( half-done ) { a2.2; half-done = FALSE; }
  ...
}

This is strarting to get a little complicated and we haven't said anything about inter-action communication

Return to: