# Lecture 3 - Odds and Ends

## Public Service Annoucements

1. Due date for assignment 0
2. Remember to get a partner
3. Caches, optimization, clock speed, FIFOs
4. Libraries: memcpy in particular
5. Questions about using a timer

## 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 for a1

• sum over i, except 1, of {execution time of ```if( c<i>``` ) + execution time of `a<i>}` + execution time of `if( c1 )` + ...

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

## A few odds and ends about trains

### Talking to the train controller

This is the hardest part of Ass. 0. If nothing happens to the train the problem can be

• a bug in your code,
• a misunderstanding of UART documentation,
• an error in UART documentation,
• the train controller not receiving,
• your software sending the wrong bytes,
• a misunderstanding of the Marklin documentation,
• an error in the Marklin documentation, or
• something else.

Putting a terminal into the line between the ARM box and the train controller will help you to eliminate possible sources or error more easily. In fact, old dumb terminals had an extra connector on the back and passed everything coming in on one connector out the other while displaying it on the screen, just to make debugging communications easier.

Today you can achieve the same thing using the two COM parts of a simple PC.

• Unplug the cable connecting the COM1 port on the ARM box.
• Connect a COM port on the PC to the COM1 port of the ARM box.
• Connect the other COM port on the PC to the train controller.
• Either use terminal emulators to pass bytes from one COM port to the other, and vice versa, or write a tiny C program to do the same thing, displaying the bytes as you pass them through.
This is an important problem solving technique that you use all the time, possibly without noticing it: break a complex problem into two or more simple ones.

Turning a train headlight on and off is an easy way to see if you are communicating with the train controller successfully.

### States of Three-way Switches

The three way switches are actually a pair of switches so they have four states
 Switch 1 Switch 2 Result Straight Straight Straight Straight Curved Curve Right Curved Straight Curve Left Curved Curved Probable Derailment

# UART Flow Control

All hardware & software has buffers somewhere

• Buffers always overflow, sooner or later
• When buffers overflow something bad happens
• Lose data either off the end, or off the start, depends on implementation
• You can control it with software (^S & ^Q)
• Often loses part of the transmission because of unpredictable time lags
• You can control it with hardware, which is what the train controller does.

### Three-wire RS-232

We need what's called a null modem. Without the crossover it's called straight through.

 connects to signal ground signal ground transmit (XMIT) receive (RCV) receive (RCV) transmit (XMIT)

### Five-wire RS-232

Two extra wires are added to provide flow control

• Request to Send (RTS), asserted when the transmitter has bytes ready to transmit, negated when the transmitter has nothing to transmit
 connects to signal ground signal ground transmit (XMIT) receive (RCV) receive (RCV) transmit (XMIT) clear to send (CTS) request to send (RTS) request to send (RTS) clear to send (CTS)

The train controller asserts RTS, which is read as CTS by the UART. The train controller ignores the RS-232 input if you send when CTS is not asserted.

### Error conditions in UARTs

• 0: FE, framing error. This usually means that you have mismatched speeds.
• 1: PE, parity error. This has meaning only if you are including a parity bit.
• 2: BE, break error. Some systems put break on the line, which indicates that something has gone wrong.
• 3: OE, overrun error. This means that a second byte was received before the first one was read, which usually means that your receive software is too slow.

### Talking to the train controller

This is the hardest part of Ass. 0. If nothing happens to the train the problem can be

• a bug in your code,
• a misunderstanding of UART documentation,
• an error in UART documentation,
• the train controller not receiving,
• your software sending the wrong bytes,
• a misunderstanding of the Marklin documentation,
• an error in the Marklin documentation, or
• something else.

Putting a terminal into the line between the ARM box and the train controller will help you to eliminate possible sources or error more easily. In fact, old dumb terminals had an extra connector on the back and passed everything coming in on one connector out the other while displaying it on the screen, just to make debugging communications easier

#### A few interesting things about RedBoot

What's in the flash ROM of the board is a partial implementation of Redboot.

• fconfig :: NOT