CS452 - Real-Time Programming - Spring 2012

Lecture 2 - Polling Loops

Pubilc Service Annoucements

Due date for assignment 0
Ubuntu 10.10
How to compile and run your first program
Caches, optimization, clock speed, FIFOs
Libraries: memcpy in particular

Practical Details: pdf

What is real-time programming?

Actually real-world programming, which means

World is measured in seconds, metres, etc.
Programs manipulate bits, bytes, words, which must be translated into into real-world measures.
For example,
- formatted output: translate from int, which computers manipulate, to decimal, which humans read
  - out in the open: i2a( ), printf( )
  - hidden: print, cout
- Banking: int translates into, e.g., number of cents
  - program says dispense( 10000 ), which means `put five twenties into the hopper'.
  - microcontrollers start
    - activating motors
    - sensing forces
    - reading digitized video
    - etc.
- Train control: contents of messages map, sometimes indirectly, into changes in speed of trains, state changes (turn-outs, train locations), sensor reports.

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

Timers

How does one keep time in a computer?

crystal oscillator in a phase-locked loop
interrupts from a timer
ntp

Polling Loops

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;

Note. The volatile keyword.

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

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.

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: