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). S C L K | M O S I ( D a t a f r o m M a s t e r ) | M I S O ( D a t a f r o m S l a v e ) | C S ( A c t i v e L o w ) 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). S t a r t B i t | D a t a B i t s ( 5 - 9 ) | P a r i t y B i t ( O p t i o n a l ) | S t o p B i t ( 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. S t a r t | A d d r e s s | R e a d / W r i t e | A C K / N A C K | D a t a | S t o p 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) [ i i i i i i i [ 0 1 2 3 4 5 6 7 r 2 2 2 2 2 2 2 r 0 0 0 0 0 0 0 0 i c c c c c c c i : : : : : : : : s - - - - - - - s h 0 1 2 3 4 5 6 h a a 0 v i i i i u u u v ] 2 2 2 2 n n n ] c c c c k k k 1 ➜ n n n ➜ o o o ~ w w w ~ 2 n n n i i U 2 2 3 U c c d d e i i i A S S S e 4 t 9 9 9 U y y M t e 1 1 1 X n n B e c 5 5 5 o o u c 5 t A p p s t g g g / s s - m m m D y y I - 6 l b b b D s s 8 y u u u I 0 s s s D D 1 2 7 A e e d d d / s s a 2 p p p P i i d 8 8 c b d H g g a Y n n p W W t 9 A a a e r r r e e a a I I t 2 2 b C C f 0 a a 4 c d d 0 a a p p d t t e e r r e I I I I N N N f 2 2 2 2 / / / C C C C A A A a a a a d d d d a a a a p p p p t t t t e e e e r r r r -- 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 # 0 # # x i 2 i 2 1 2 c c g s e e t t - - y y 2 2 0 0 x x 2 2 8 8 0 0 x x 1 5 b 5 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: # 0 # x i 2 2 1 c t r a n s f e r - y 2 w 1 @ 0 x 2 8 0 x 1 b r 1 @ 0 x 2 8 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 ...