CS 452/652 Winter 2026 - Lecture 11

I/O Interrupt Handling

Feb 10, 2026 prev next

see BCM, Chap 11
interrupt sources:
- TX (transmit) - room in the transmit buffer
- RX (receive) - data in the receive buffer
- status change
- error condition
control interrupts:
- IMSC (Interrupt Mask Set Clear) controls which interrupts are generated
  one bit per interrupt: 1 enables interrupt, 0 disables it
- ICR (Interrupt Clear Register) clears pending interrupt
  one bit per interrupt: 1 clears interrupt
one interrupt signal at GIC (Interrupt ID = 153)
- configure at GIC (like timer interrupt) - enable and target core
- logical OR of all interrupts from all UARTs (BCM Page 87)
- MIS: pending interrupts after applying masking (vs. RIS raw)
- PACTL_CS: determine which UART (Section 6.2.4, Figure 6)

naive: wait for interrupt → action
- spurious interrupts? concurrent access? (cf. busy-wait debug output)
better: wait for interrupt → check status → action → repeat
best: check status → action or wait for interrupt → repeat
- avoid interrupt handling as much as possible
actual reading/writing is done in user task
- remember possible infinite loop with level interrupt signals...
- default mode for level signal is interrupt disabled
example: input
- try read; done?
- else enable RX interrupt
- RX interrupt arrives → disable
- repeat
- similar for output
UART interrupt handling in detail
- read GICC_IAR to find the InterruptID
- if it is the UART interrupt
  - read UART MIS register(s) to find out which UART interrupt(s)
  - level signal: disable interrupt at IMSC
  - clear interrupt using UART ICR
  - write to GICC_EOIR when finished in kernel (as for the timer interrupt)
- user task eliminates cause of interrupt, if necessary (RX/TX level)
- AwaitEvent() enables level interrupt using IMSC

32 characters for Tx and 32 for Rx
can be enabled or disabled (together)
interrupt "trigger levels" are 1,2,4,6,7/8 full (see UART IFLS register)
should enable Tx FIFO?
- allows for small bursts of writes
  but cannot control when queued writes are sent
should enable Rx FIFO?
- helps buffer bursts of incoming data
  but additional delay on reception
- timeout interrupt: FIFO non-empty and 32 bit quiet time (see PLM for details)

match communication speed to processing speed
terminal receiver is normally fast enough to handle communication at channel speed
serial communication provides explicit flow control signal for
- UART's 'TX ready' status only means the communication buffer has room
- Clear-To-Send (CTS) signalled on separate wire when the receiver is able to receive and at least buffer the next byte
- available at UART via FR register
in principle, before sending:
- check TX up (cf. TX interrupt)
- check CTS up (cf. status interrupt)
in theory, hardware flow control should do that
in practice, old hardware might not de-assert CTS fast enough!

interrupt arrives GPIO Pin 17 (Interrupt #145)
- GPIO code will be posted on Piazza
similar to UART interrupts
- CANINTE controls interrupt generation
- CANINTF reports interrupts and is used for clearing interrupts
- use same pattern: try I/O operation; enable interrupt if I/O fails
- level signal: keep interrupts disabled otherwise
3 TX, 2 RX buffers reported seperately
- ignore TX1 and TX2?
- rollover into RX1: ordering between RX0 and RX1?
flow control not applicable to CAN bus communication with CS3
- here: request/response pacing
- in general treated as a separate issue from basic communication (example: IP vs TCP)
- "overload" messages in CS3 documents refer to electrical overload?

CS3 keeps list of all "active" locomotives on track
- "Erster Befehl nimmt Lok/Funktionsdecoder in Zyklus auf."
- CS3 seems to cycle through list and refresh commands/status
- init all (potential) trains: all in cycle
- this slows down (reorders?) new commands
remove train from cycle (command 0x00, subcmd 0x04, MRK Page 16)
- dlc = 5
- data 0-3: train number or 0 for all
- data 4: 0x04 (sub command)
note this also seems to turn off the lights