CS452 - Real-Time Programming - Spring 2011

Lecture 2 - Introduction

Pubilc Service Annoucements

Due date for assignment 0/1
Combination to trains lab
Ubuntu 10.10
`I can remember amusing myself once as an undergraduate, deleting and creating files till I got the right inode numbers to allow a judicious choice of binary file names to result in a directory that was a valid executable a.out image,' says Digby Tarvin. Anybody interested in trying this for elf?
cs452 e-mail alias: cs452@cgl.uwaterloo.ca
How to compile and run your first program

Practical Details: pdf

What is important for real-time?

Throughput
- e.g., number of frames per second in a game
- e.g., frequency of sensor sampling in process control
- no solution except
  1. getting better hardware
  2. getting better algorithms
  3. restructuring the task
Response time
- e.g., time from button press to gun firing in game
- e.g., time from sensor reading to control code executing in provess control
- several programming techniques exist
  1. busy-wait
  2. polling loop
  tension between flexibility and performance

In cs452 we take guaranteed response time as the defining quality of real-time computation.

Serial I/O

Uses a device called a UART,

which is really just two shift registers
with a one byte buffer in front of each one
plus one bit in a control register for each. They mean
- read: there's a byte you haven't read yet
- write: the buffer is empty, you can write

Busy Waiting

This is used to synchronize with an external event, minimizing response time.

#define FOREVER for( ; ; )
FOREVER {
   while( !ready( ) ) ;
   do-it( );
}

or in another form

FOREVER {
   if ( ready( ) ) do-it( );
}

Sometimes you only want to do the thing once, as you do when putting a character on a serial line.

#define UART1_BASE        0x808c0000
#define UART_DATA_OFFSET        0x00    // low 8 bits
#define UART_FLAG_OFFSET        0x18    // low 8 bits
#define TXFF_MASK               0x20    // Transmit buffer full

        flags = (int *)( UART1_BASE + UART_FLAG_OFFSET );
        data = (int *)( UART1_BASE + UART_DATA_OFFSET );
        while( ( *flags & TXFF_MASK ) ) ;
        *data = c;

Worst case response time

From the time that the ready bit sets until the first instruction of do-it is executed

execution time for
```
while( !ready ) ;
do-it;
```
Even a moderately optimizing compiler will produce good machine code. Something like
```
ready:
  ldb  r0, STATUS-ADDRESS
  and  r0, r0, READY-BIT
  beq  _ready
do-it:
  ldb r0, DATA-ADDRESS
    
```
Here do-it is acquiring a single byte from interface hardware when the status register indicates that valid data is available in the dara register.
Worst case response time is the execution of and, beq, ldb, and,andbeq
Normally code like this would be inside a loop, acquiring one byte after another until no more are available.

The problem with busy-waiting

What if the CPU has to two things at once?

E.g.,

collect bytes coming in a serial port
maintain a clock

Unless the rate of bytes coming in and rate of clock ticks are identical

you are guaranteed to lose something sooner or later.

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;
}

Worst case response time

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

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

Assignment 0: pdf

Overall System

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

`COM' ports

Connected to UARTs

RS-232

Only really two

Ethernet port

Busy wait ethernet code in RedBoot

Reset switch

red, even though documentation says black

EP-9302

System on chip

ARM 920T core, implementing ARM v4T instruction set
Two co-processors
1. System controller, MMU
2. Maverick Crunch floating point unit
Peripherals
1. UARTs
2. Timers
3. DIO
4. A/D
5. etc.

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

Separate instruction and data caches

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

Timers normally count down

Timers available in the EP9302.

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

Return to: