CS 452/652 Spring 2022 - Lecture 11

Jun 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

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

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.

minimum functionality in kernel!
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 - only with HDLC operation?

"regular" hosted environment (such as Linux)
- hardware: special instruction, exception
- operating system
  - start/stop/attach thread
  - write to code segment of process
- breakpoint - write special instruction, handle exception
- continue - rewrite original code, resume execution
- single step - breakpoint at next instruction (or source code line)
- example: see 'man ptrace' on Linux
otherwise: remote operation
- gdb stub/server co-located with target
- EP 9302: gdb stub in RedBoot
- communication over serial link or network (TCP)

breakpoint implemented as undefined instruction: 'user defined function' (udf)
udf handler accessed via branch in 0x04, destination in 0x24
- udf handler invokes gdb stub
- make sure 0x04/0x24 are not modified from reset defaults!
works for breakpoints/single-stepping kernel code (in SVC mode)
debug operation: run user tasks in System mode
⇒ breakpoints/single-stepping should work for most code
however, assignment submissions must run user tasks in User mode!!