CS 452/652 Winter 2020 - Lecture 15
February 7, 2020
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 UARTXIntIDIntClr at offset 0x1C
"UART Interrupt Identification and Interrupt Clear Register."
Interrupts @ VIC
- not all interrupts addressable by VIC
- VIC-numbered interrupts:
- transmit (TX)
- receive (RX)
- combined interrupt
- get rest (or all?) through combined interrupt
- 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)
- try read; done?
- enable RX interrupt
- RX interrupt arrives → disable (level signal)
- similar for write, if data is available
- 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.
- 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?
- be aware of Section 14.4.19 - but I have not seen this
- then again, I have not seen the CTS quirk either...