CS452 - Real-Time Programming - Winter 2013

Lecture 3 - Timers, I/O, Pitfalls

Pubilc Service Annoucements

1. Due date for assignment 0
2. Caches, optimization, clock speed, FIFOs
3. Libraries: memcpy in particular
4. 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

1. initialization
2. output
3. 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

• register to load the timer
• register to read the timer
• register to command the timer

Timers available in the EP9302.

1. Two sixteen bit
2. One thirty-two bit
3. One forty bit
4. 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:

• Bill Cowan's lecture notes for CS452 in s12
• Bill Cowan's Spring 2012 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page

Practical Details: pdf

Timers

How does one keep time in a computer?

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

Terminals

How does one produce a useful display on an ASCII terminal?

• Model is an endless scroll on which output appears in order.
• You can't go backwards.
• You can't overwrite.

Make the model more like a window.

• Allow moving backwards. Then the scroll can be finite.
• Allow the cursor to teleport.

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 and beq
• 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.,

1. collect bytes coming in from one serial port
2. collect bytes coming in from another serial port

You might think of doing something like:

FOREVER {
	while (!ready(port1) ;
	read( port1 );
	while (!ready(port2) ;
	read( port2 );
}

What must be true for this code to catch all the bytes?

• The two ports must receive the same number of bytes.
• Byte arrival times on the two ports must be interleaved.
• The two ports must be running at the same speed.

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:

• Bill Cowan's lecture notes for CS452 in w13
• Bill Cowan's Winter 2013 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page