Day32 - Linux IIO Subsystem (Introduction)¶

Overview¶

The Industrial I/O (IIO) subsystem in Linux is designed for data acquisition devices, especially sensors that produce sampled data streams.

Typical use cases include:

ADC (Analog-to-Digital Converter)
IMU (accelerometer / gyroscope)
Light / proximity sensors
Pressure / distance sensors

Unlike hwmon, which focuses on monitoring system health, IIO provides a generic framework for sampling, buffering, and triggering sensor data.

Key Design Philosophy¶

hwmon vs IIO¶

Feature	hwmon	IIO
Purpose	Monitoring	Data acquisition
Data model	Current value	Sample stream
Interface	sysfs only	sysfs + character device
Multi-channel support	Limited	Native
Sampling control	Not central	Core feature
Buffer support	No	Yes
Trigger support	No	Yes

Key takeaway¶

hwmon → "What is the current value?"
IIO → "How do we sample and stream data?"

User-Space Interface¶

IIO exposes two main interfaces:

1. sysfs (configuration & single-shot read)¶

/sys/bus/iio/devices/iio:deviceX/

Common attributes:

name
in_voltage0_raw
in_voltage0_scale
sampling_frequency
scan_elements/
buffer/
trigger/

2. Character Device (buffered data)¶

/dev/iio:deviceX

Used for:

Continuous sampling
Multi-channel data acquisition
Efficient bulk data transfer

Core Concepts¶

1. Channel¶

A channel represents one measurable signal.

Examples:

in_voltage0
in_voltage1
in_temp
accel_x, accel_y, accel_z

Each channel may expose:

raw value
scale
offset

Example¶

in_voltage0_raw   = 1234
in_voltage0_scale = 0.001

User-space conversion:

voltage = raw * scale
        = 1234 * 0.001 = 1.234 V

2. Trigger¶

A trigger defines when a sample is taken.

Common sources:

Timer
Data-ready interrupt
External GPIO
Software trigger

Example¶

sampling_frequency = 1000 Hz

→ sample every 1 ms

3. Buffer¶

A buffer stores sampled data and provides it to user-space.

Enabled via:

buffer/enable
buffer/length

Once enabled, data flows into:

/dev/iio:deviceX

4. Scan Elements¶

Defines the layout of a sample frame.

Example (3-axis IMU):

timestamp, accel_x, accel_y, accel_z

This allows:

multi-channel synchronization
consistent data structure

Data Flow (Conceptual)¶

Non-buffered mode¶

User → read sysfs → driver → read hardware → return value

Buffered mode¶

Trigger fires
    ↓
Driver reads hardware
    ↓
Push data into buffer
    ↓
User reads /dev/iio:deviceX

Comparison with Previous Learning¶

1. vs hwmon (Day20–21)¶

hwmon flow¶

cat temp1_input
    ↓
driver reads sensor (or cache)
    ↓
return single value

IIO flow (buffered)¶

trigger → sample → buffer → /dev/iio:deviceX

Key difference¶

hwmon = on-demand read
IIO = event-driven sampling

2. vs Character Device Driver (Day9–16)¶

Your custom driver:

write() → command
read()  → response
poll()  → event

IIO:

read_raw() → single value
buffer     → data stream
trigger    → sampling event

Key difference¶

char device = protocol / message-based
IIO = structured data stream

3. vs TTY Subsystem (Day29–31)¶

TTY RX path:

IRQ → flip buffer → tty buffer → read()

IIO buffered path:

Trigger → sample → IIO buffer → read()

Similarities¶

both use buffering
both decouple interrupt context and user read
both optimize data flow

Differences¶

TTY	IIO
byte stream	structured sample
protocol-based	measurement-based
continuous RX/TX	trigger-driven

Example Use Cases¶

Example 1: ADC (multi-channel)¶

Channels: voltage0, voltage1, voltage2
Trigger: timer (1 kHz)
Buffer: enabled

Result:

(timestamp, ch0, ch1, ch2)
(timestamp, ch0, ch1, ch2)
...

Example 2: IMU sensor¶

Channels: accel_x/y/z, gyro_x/y/z
Trigger: data-ready interrupt
Buffer: enabled

Example 3: Simple sensor (no buffer)¶

Channel: temperature
Only read:

in_temp_raw
in_temp_scale

→ behaves similar to hwmon, but still uses IIO framework

When to Use IIO¶

Use IIO if:

Multiple channels need to be sampled together
Sampling frequency matters
Continuous data acquisition is required
Timestamped data is needed
Hardware provides data-ready interrupt

When NOT to Use IIO¶

Do NOT use IIO for:

Command/response devices
Communication protocols (e.g., NFC mailbox)
Simple monitoring only (prefer hwmon)
Control-oriented drivers

Mental Model Summary¶

hwmon¶

read → get current value

IIO¶

define channels
    ↓
define when to sample (trigger)
    ↓
collect samples (buffer)
    ↓
stream to user-space

Next Step (Day33)¶

Implement a minimal IIO driver:

single channel
no buffer
no trigger
only read_raw()

Goal:

understand iio_dev
understand iio_chan_spec
map sysfs ↔ driver