CS 452/652 Winter 2023 - Lecture 11

Documents

• BCM - Broadcom BCM2711 data sheet (local copy)
• SC16 - SC16IS752 data sheet (local copy)

Interrupt Sources

• transmit (TX): FIFO contains N free slots (level interrupt)
• receive (RX): FIFO contains N elements (level interrupt)
• RX timeout: FIFO not empty; below N, no arrival for 32-bit time (level interrupt)
• CTS, status: CTS changes (edge interrupt)
• combined interrupt delivered to GPIO Pin 24
• interrupts controlled via IER register (SC16, Section 8.3)
• interrupt number queried via IIR register (SC16, Section 8.5)

Hardware FIFO

• Hardware FIFO (64 bytes) reduces interrupt rates (with interrupt mitigation) and absorbs small bursts of data
  • enable/disable both RX/TX in FCR[0]
  • interrupt triggers in FCR, TLR (needs EFR[4], MCR[2])
• RX timeout interrupt after 4 bytes silence - how long?
  • 115,200 bits/sec at 10 bits/byte ⇒ 1 byte ~ 87 usec
  • acceptable for terminal/keyboard interaction
• train/track: ~20ms latency maybe not acceptable?
• BUT: could align RX trigger with sensor readings?

UART Operation

• naive: wait for interrupt → action
• better: wait for interrupt → check status → action → repeat
• best: 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

Task Structure

• minimum functionality in kernel!
• UART 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: system calls

SPI Interface

• need atomicity of 2-byte UART operations
• implement in SPI interactions in kernel and expose via UART-specific system calls

GPIO/GIC Setup

• GPIO banks: 0-27, 28-45, 46-57
• program GIC to handle interrupt from GPIO pin 24 (serial hat wiki page)
• BCM (Section 5.1, Page 65): GPIO pin 24 in Bank 0
• BCM (Section 6.2.4, Page 86): GPIO Bank 0 → VideoCore IRQ 49
• as before (Figure 7): add 96 = 145
  • enable and route using ISENABLER/ITARGETSR - just like timer interrupt
• GPIO setup for Pin 24
  • set function GPIO_INPUT, resistor GPIO_NONE (not pull-down or pull-up)
  • add interrupt by setting Bit 24 in GPLEN0
    • pin level low causes interrupt
    • GPEDS registers observe interrupt → GIC is notified
    • interrupt must be confirmed by writing '1' to relevant GPEDS bit

Flow Control

• For keyboard/terminal, 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) signalled on separate wire when the receiver is able to receive and process the next byte.
• before sending
  • check TX up (cf. TX interrupt)
  • check CTS transition to up (cf. status interrupt)
• CTS line connected to SC16IS752 chip: homebrew inverse signal (cf. DIP switch on Märklin box)
• software flow control (Xon/Xoff) not supported by Märklin
• Auto-CTS not tested

CTS Quirk

• 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.