CS452 - Real-Time Programming - Winter 2017
Lecture 3 - Odds and Ends
Public Service Annoucements
-
Due date for assignment 0
-
Remember to get a partner
-
Caches, optimization, clock speed, FIFOs
-
Libraries: memcpy in particular
-
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?
-
Ignore Unicode. Why be different from all the other programmers
in the world?
-
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 is 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 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.
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.
-
How long does it take to transmit/receive a byte to/from the
train controller?
-
2.4K bps -- 0.24K Bps -- 4 msec/B
-
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
-
How often do you need to read the timer?
-
Is there a problem?
-
Yes. What is it?
-
Will you catch it in your testing?
-
Typing commands, no!
-
Downloading a file, yes!
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 odds and ends about UARTs
Error conditions in UARTs
There is a receive status register 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.
-
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
States of three-way switches
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
-
Clear to Send (CTS) asserted when a receiver is ready to
receive input, negated when the receiver is not ready to
receive input.
-
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
-
Written by the transmitter, read by the receiver.
|
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!
- load (tftp)
- go [address]
- examine, copy, fill memory
The program you have written so far is allocating local memory
on a stack?
- Where is Redboot's stack?
This enables you to get a clean return to RedBoot when your program
terminates.
When your program crashes Redboot catches the exception, and puts
out some information for gcc to hook into your program. (ecos and
RedHat are strongly connected to the GNU project. (Don't
bother trying to use gdb!) You see it on the bottom two
lines of output. It's useless except for one 8 digit number
starting 00218 or 00219. This is the address of the last instruction
the CPU attempted to execute. Using the load map and the assembly
code you can find exactly how far the program got before crashing.
Unfortunately, the error may have occurred long before execution
stopped.
Return to: