CS 452/652 Winter 2022 - Lecture 14

February 7, 2022 prev next

Please refer to Chapter 14 in EP93xx User Guide for further details.

transmit (TX): FIFO at least half empty (level)
receive (RX): FIFO at least half full (level)
RX timeout: FIFO not empty; no arrival for 32 bit time (level)
status: CTS changes (ignore other flags) (edge)
combined interrupt: ORed combination of all of the above
- check UART{1,2}IntIDIntClr at offset 0x1C
  "UART Interrupt Identification and Interrupt Clear Register."

In general, the hardware FIFO can reduce the interrupt rate for highspeed devices (with interrupt mitigation), and absorb small bursts of output without software buffering.
RX interrupt only triggered when FIFO half-full → 8 bytes
- proper operation (try read before interrupt) will drain FIFO
- however, up to 7 keystrokes could go unnoticed...
RX timeout interrupt after 4 bytes silence - how long?
- 115,200 bits/sec at 10 bits/byte ⇒ 1 byte ~ 87 usec
- acceptable for keyboard interaction
UART1/train: ~20ms latency not acceptable

For UART2 (screen/keyboard), it is assumed that the receiver device is fast enough to handle communication at channel speed.
UART1 provides explicit flow control signal for (potentially slow) train controller.
- UART's 'TX ready' status only means the communication channel is ready.
- Clear-To-Send (CTS) is a separate signal (separate wire) that the receiver asserts when it is able to receive and process the next byte.
- aside: another reason not to bother with FIFO for UART1...
before sending
- check TX up (cf. TX interrupt)
- check CTS up (cf. status interrupt)
status interrupt needs to be confirmed (edge signal)

expected order of events and actions is:
TX & CTS up → write → TX & CTS down → wait → TX & CTS up (repeat)
due to different internal clock rates at ARM board and Marklin controller:
TX & CTS up → write → TX down → TX up PROBLEM → CTS down → CTS up
i.e., TX might go back up before CTS goes down
- a simple status check might send next command too early
- need state machine (triggered by status interrupts) to track CTS state after send
An earlier description by Bill Cowan is available here.

naive: wait for interrupt → action
more robust: wait for interrupt → check status → action → repeat
reorder: check status → action or wait for interrupt → repeat
actual reading/writing is done in user-level server?
- remember possible infinite loop with level interrupt signals...
example: read (assume reader/buffer is present)
1. try read; done?
2. enable RX interrupt
3. RX interrupt arrives → disable (level signal)
4. repeat
similar for write, if data is available

servers - how many? your design
- services requests from clients, notifiers, reader/writer?
- provides buffering
- might have to park clients
notifier handles interrupts/events
actual low-level read/write operations: in server, notifier, or separate task?