Platform/Protocol

SPI (Serial Peripheral Interface) Overview Synchronous, full-duplex serial bus. Master-slave architecture (1 master, multiple slaves). Uses 4 wires: SCLK (clock), MOSI (Master Out Slave In), MISO (Master In Slave Out), SS/CS (Slave Select). Physical Layer Push-pull outputs (faster than open-drain). Each slave requires a dedicated SS line. Data Frame Structure No start/stop bits – continuous stream synchronized to SCLK. Data sampled on clock edges defined by CPOL (clock polarity) and CPHA (clock phase): Mode 0: CPOL=0 (idle low), CPHA=0 (sample on rising edge). Mode 3: CPOL=1 (idle high), CPHA=1 (sample on falling edge). SCLK | MOSI (Data from Master) | MISO (Data from Slave) | CS (Active Low) Key Features Full-duplex communication (simultaneous MOSI/MISO). No addressing – slaves selected via SS lines. Speeds: Up to 100+ Mbps (depends on hardware). Pros & Cons Pros Cons High-speed communication High pin count (n+3 for n slaves) Simple protocol, flexible modes No built-in error detection Full-duplex support No multi-master support Use Cases High-speed sensors (e.g., IMUs). Display controllers (OLED, TFT). SD cards, NOR flash memory. Comparison Table Feature UART I2C SPI Clock None (async) Shared (SCL) Shared (SCLK) Duplex Full-duplex Half-duplex Full-duplex Topology Point-to-point Multi-device Master-slave Speed Low (≤115kbps) Moderate (≤3.4Mbps) High (≥10Mbps) Addressing None 7/10-bit Hardware (SS lines) Pins 2 (TX/RX) 2 (SCL/SDA) 4 + n (SS per slave) Error Handling Parity bit ACK/NACK None

UART (Universal Asynchronous Receiver-Transmitter) UART is a simple, asynchronous serial communication protocol used for full-duplex communication between two devices. Key Features: Asynchronous: No clock signal – relies on pre-agreed baud rate (e.g., 9600, 115200 bps). Uses two main lines: TX (Transmit) and RX (Receive). Configurable baud rate (e.g., 9600, 115200 bps). Error detection: Parity bit (optional). Flow control: Hardware (RTS/CTS) or software (XON/XOFF). No addressing – only two devices per bus. Data Frame Structure Start bit (1 bit, logic low). Data bits (5–9 bits, LSB-first). Parity bit (optional, even/odd/none). Stop bit(s) (1 or 2 bits, logic high). Start Bit | Data Bits (5-9) | Parity Bit (Optional) | Stop Bit (1-2) Points to Remember If the baud rate is set as 115200, then the recever will expect stop bit that is high state for 1 baud period(generally). Usage in Linux Kernel: #include <linux/serial_core.h> struct uart_port *port; uart_write(port, "Hello", 5); Use Cases Debugging consoles (e.g., Linux kernel printk via UART). GPS modules, Bluetooth/Wi-Fi modules.

Basics of I2C Overview Synchronous, multi-master, multi-slave serial bus. Half-duplex communication (bidirectional SDA line). Uses 2 wires: SCL (clock), SDA (data). Speeds: Standard (100 kHz), Fast (400 kHz), High-Speed (3.4 MHz). Physical Layer Open-drain outputs – requires pull-up resistors. 7-bit or 10-bit addressing (supports up to 128/1024 devices). Data Frame Structure Start condition: SDA ↓ while SCL is high. Address frame: 7/10-bit address + R/W bit. ACK/NACK: Slave pulls SDA low to acknowledge. Data frames (8-bit chunks, MSB-first). Stop condition: SDA ↑ while SCL is high. Start | Address | Read/Write | ACK/NACK | Data | Stop Key Features Clock stretching: Slaves can hold SCL low to pause communication. Multi-master arbitration: Masters detect collisions via SDA monitoring. Speeds: Standard (100 kbps), Fast (400 kbps), High-Speed (3.4 Mbps). Use Cases Sensors (temperature, accelerometers). EEPROMs, RTC (Real-Time Clock) modules. Device Tree TODO Writing client device drivers TODO I2C-Tools Package in Userspace Useful for debugging, testing, some simple prototyping Accesses the I²C bus via /dev/i2c-0, /dev/i2c-1… Assume devices have registers, SMBus-like i2cdetect scan an I2C bus for devices No guarantee it works (I²C is not discoverable by the spec) [rishav] ➜ ~ i2cdetect -l i2c-0 i2c i915 gmbus dpc I2C adapter i2c-1 i2c i915 gmbus dpb I2C adapter i2c-2 i2c i915 gmbus dpd I2C adapter i2c-3 i2c AUX A/DDI A/PHY A I2C adapter i2c-4 unknown Synopsys DesignWare I2C adapter N/A i2c-5 unknown Synopsys DesignWare I2C adapter N/A i2c-6 unknown SMBus I801 adapter at f040 N/A [rishav] ➜ ~ i2cdetect -y 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- 28 -- -- -- -- -- -- -- 30: -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- -- No response 28 Response from address 28 UU Address in use (by driver) i2cget, i2cset i2cget: read a register value i2cset: set a register value Can use various types of SMBus and I2C transactions Limited to 8-bit register address # i2cget -y 2 0x28 0x1b 0x21 # i2cset -y 2 0x28 0x55 # i2cdump dump value of all registers i2ctransfer i2ctransfer: the “swiss army knife of Linux I2C”, in userspace Example: reimplement the i2cget -y 2 0x28 0x1b command: # i2ctransfer -y 2 w1@0x28 0x1b r1@0x28 0x21 # w1@0x28 Write transaction, 1 byte, client address 0x28 0x1b Data to send in the write transaction r1@0x28 Read transaction, 1 byte, client address 0x28 Troubleshooting Return code from i2c_*() functions — Never ignore errors! Kernel logs i2c-tools Oscilloscope or logic analyzer No ACK from client - systematic Problem: a client never responds to transactions ...