# 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

## Estimating time

In a real-time system finding the correct algorithm requires us to think about how long things take. Mostly this means doing mental or back of the envelope calculations where we care only about getting the right order of magnitude.

#### Digression: How many bits in a byte?

• ASCII defines three character sets: 6-bit (upper case letters only) , 7-bit (upper and lower case letters) and 8-bit (upper and lower case plus accented letters). 7-bit has been for many decades the most common.
• The two UARTs must synchronize. This occurs as a result of the receiving UART searching for a start bit that starts every communication.
• To detect errors, which UARTs do there needs to be an end of transmission bit to put the UART back to searching for a start bit and there may be a parity bit to catch 1-bit errors.
• The character set, the number of stop bits and the existence (or not) of a parity bit must be the same at both ends of the communication line. This is the main drawback of the UART as a device: the evil counterpart of its extreme robustness. (Most of the complexity of mondern I/O insulates the OS and the user from having to deal with such problems.) Since UARTs are nowadays used only by experts, such as you, it's no longer a problem.
End of digression.

#### Practical questions

Can we put busy-wait I/O into the polling loop? Acutally, four questions.

1. How long does it take to transmit/receive a byte to/from the train controller?
• 2.4K bps -- 0.24K Bps -- 4 msec/B
2. How long does it take to transmit/receive a byte to/from the terminal?
• 115K bps -- 10K Bps -- 0.1 msec/B -- 100 usec/B
3. How often do you need to read the timer?
• more than once every 10 msec
4. Is there a problem?
• Yes. What is it?
• Will you catch it in your testing?
• Typing commands, no!

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

What can you do if think your polling loop is too slow?

• Time the loop to make sure that you are right. Afterwards, keep this code, giving debugging output only if it's too slow.
• Figure out which action must run the most often, and what the longest repeat time it can tolerate. If this exceeds your loop time then you know where the problem is.
• Estimate the time of different actions and figure out where is the mid-point of your loop's execution.
• Insert an extra test and action for the failing action at the mid-point.
• Repeat as needed.
Like this:
```    FOREVER {
if( c1 ) a1;
if( c2 ) a2;
...
if( cn ) an;
if( c1 ) a1;
if( cn+1 ) an+1;
...
if( cN ) aN;
}
```

## A few odds and ends about UARTs

### Error conditions in UARTs

There is a receive status register in each UART that tells you something about receive errors. Its bits are:

• 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. You will not see this in the lab unless something has gone seriously 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.

### The data register

At most 8 of the bits in the integer you read have genuine content. Masking is usual.

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

• Written by the receiver; read by the transmitter. If you are a hardware person you would say "Driven by the receiver; latched by the transmitter."
• 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. Of course, nothing is sent to you saying that a byte has been lost.

#### A few interesting things about RedBoot

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

• fconfig :: NO! NOT! NEVER!