Day32 Log - IIO Subsystem Introduction¶

Summary¶

Introduced the Linux Industrial I/O (IIO) subsystem.

Focused on:

Understanding IIO design philosophy
Exploring user-space interface (sysfs + character device)
Comparing IIO with hwmon and previous subsystems
Preparing for driver implementation

Key Observations¶

1. No IIO devices present on system¶

ls /sys/bus/

Result:

No iio bus directory
No /sys/bus/iio/devices/
No /dev/iio:deviceX

Insight¶

IIO subsystem is not visible unless a driver registers a device
Unlike I2C or SPI, IIO is not a physical bus
It is a functional subsystem

2. Difference between bus and subsystem¶

Previously learned:

I2C / SPI / platform → bus-based
Devices exist independently of drivers

IIO:

No physical bus
Devices only exist after driver registration

Key takeaway¶

IIO is a functional framework, not a hardware bus

3. IIO vs hwmon¶

Comparison based on prior experience:

Feature	hwmon	IIO
Primary use	Monitoring	Data acquisition
Interface	sysfs only	sysfs + /dev
Data model	Single value	Sample stream
Multi-channel	Limited	Native
Buffer	No	Yes
Trigger	No	Yes

4. IIO core concepts identified¶

Channel¶

Represents a measurable signal

Examples:

in_voltage0
in_temp
accel_x

Trigger¶

Defines when sampling occurs

Examples:

timer
data-ready interrupt
software trigger

Buffer¶

Stores sampled data for user-space

Accessible via:

/dev/iio:deviceX

Scan Elements¶

Defines layout of a sample frame

Example:

timestamp, ch0, ch1, ch2

5. User-space interface structure¶

Expected layout:

/sys/bus/iio/devices/iio:deviceX/
 ├── in_* (channel values)
 ├── sampling_frequency
 ├── scan_elements/
 ├── buffer/
 ├── trigger/

6. Conceptual data flow¶

hwmon¶

read → driver → return value

IIO (buffered)¶

trigger → sample → buffer → user read

7. Mapping to previous learning¶

vs Character Driver¶

char driver → protocol/message based
IIO → structured measurement data

vs TTY¶

TTY → byte stream
IIO → structured samples

vs hwmon¶

hwmon → on-demand read
IIO → sampling-oriented

Issues Encountered¶

No IIO devices available for exploration¶

Problem:

System has no built-in IIO devices
Unable to observe real sysfs structure

Impact:

Could not verify user-space interface directly

Solution / Decision¶

Instead of relying on existing hardware:

→ Implement a minimal IIO driver for learning

Reasons:

Full control over behavior
Faster learning cycle
Avoid dependency on external hardware

Key Learning¶

IIO is a data acquisition framework
User-space interface depends on driver registration
Channel / trigger / buffer are core building blocks
IIO is fundamentally different from hwmon

Reflection¶

Initial expectation:

IIO behaves like another bus (similar to I2C/SPI)

Actual understanding:

IIO is a higher-level subsystem for sensor data pipelines

This realization clarifies:

Why no devices appear by default
Why driver implementation is necessary
Why IIO integrates buffering and triggering

Next Step¶

Day33:

Implement minimal IIO driver
Verify sysfs auto-generation
Understand read_raw() mapping