Protocol on Rishav's Digital Garden

SPI

Wed, 05 Feb 2025 23:06:00 +0000

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

Wed, 05 Feb 2025 22:14:00 +0000

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.

I2C

Fri, 08 Nov 2024 21:40:00 +0000

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