CS452 - Real-Time Programming - Winter 2015

Lecture 2 - Polling Loops

Public Service Annoucements

  1. E-mail only to uwaterloo addresses; respond on newsgroup
  2. Due date for assignment 0
  3. Caches, optimization, clock speed, FIFOs. Any one of these turned on is likely to lead to obscure bugs.
  4. Libraries: memcpy in particular
  5. Nettops:
  6. University github: git.uwaterloo.ca
  7. Comments about first.pdf
  8. Once upon a time global variables were a tool of the devil.
    Then object-oriented programming came along.
    For real-time programming global variables and objects are still tools of the devil.

Practical Details: pdf


"Smart" terminals

In the late 1970s Digitial Equipment Corporation (now part of HP by way of Compaq) introduced a "smart" terminal called the VT100; the feature that made it "smart" was cursor addressing. There were keys added to its keyboard each of which sent several characters at once. The first character was always ESCAPE, so these key sequences were called escape sequences. Each sequence moved the cursor in some way. Putting this sequences in editors created the first full-screen editors.

The first escape codes moved the cursor around the display. They were used more often by programs than by users. Without cursor adderssing it was necessary to write 80 X 24 characters to make a change to the display, even if only 2 characters were changing. With cursor addressing an escape sequence could put the cursor in the right place after which the program can send the characters to be changed.

Escape sequences vary from one terminal program to another with a common core which is the set created for the VT100.


Timers

How does one keep time in a computer?

In practice, how do you find out the time for a0?

In practice, how do you know that you are keeping accurate time?


Busy Waiting

This is used to synchronize with an external event, minimizing response time. This bit of code waits for something to be ready then does something as soon at whatever it is is ready.

    #define FOREVER for( ; ; )
    FOREVER {
      if ( ready( ) ) do-it( );
    }
  
Actually, the code above does not necessarily work. Almost every compiler that optimizes even a little will convert the above code to
    if ( ready( ) ) do-it( );
  
The compiler does not know that a value inside ready( ) will change without an assignment.

Note. The volatile keyword is one way of controlling the compiler. You can alternatively write assembly code or compile without optimiziation.

Worst case response time

Let's suppose

    int ready( ) {
      return *status-addr >> # & 1;
  
which the compiler will in-line.

Exercise for the reader. What is the longest possible time between the ready-bit setting and execution of the first instruction of do-it. Case 1: do-it inlined; case 2: do-it run as a function.

The problem with busy-waiting

What if the CPU has to three things at once?

E.g.,

  1. collect/send bytes coming from/to one serial port,
  2. collect/send bytes coming from/to another serial port, and
  3. maintain a clock in the terminal window.

To understand this problem we need to do a little mental arithmetic to see, for example, how long the CPU would spend busy-waiting.


Digression: How many bits in a character?


Four questions.

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

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 the testing you do?

Testing more than once

Suppose you are getting events that trigger a1 too infrequently. 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

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. How would you accomplish that?


A few odds and ends about trains

  1. Put a terminal between the ARM box and the train controller.
  2. The three way switches are actually a pair of switches so they have four states
  3. Turning a train headlight on and off is an easy way to see if you are communicating with the train controller successfully.

Return to: