CS 452/652 Fall 2022 - Lecture 11
Oct 20, 2022
- 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 (64 bytes) reduces interrupt rates (with interrupt mitigation) and absorbs small bursts of data
- enable/disable both RX/TX in FCR
- interrupt triggers in FCR, TLR (needs EFR, MCR)
- 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?
- 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)
- try read; done?
- enable RX interrupt
- RX interrupt arrives → disable (level signal)
- similar for write, if data is available
- need atomicity of 2-byte UART operations
- implement in SPI interactions in kernel and expose via UART-specific system calls
- 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
- 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?
- For keyboard/terminal, the receiver device is fast enough to handle communication at channel speed.
- UART1provides 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)
- Unfortunately, it seems that the CTS line is not connected to SC16IS752 chip...
- software flow control (Xon/Xoff) not supported by Märklin
- 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.