Innovation... driven by intelligence and logic

Course Structure. I2C Protocol and Device Driver Development

The course is structured to move logically from theoretical protocol understanding to practical driver implementation and advanced kernel integration.

Part 1: I2C Protocol Deep Dive & Foundations (Sessions 1-4)

1. Introduction & I2C Protocol Basics

Overview of embedded buses (I2C, SPI, UART). I2C physical layer: SDA/SCL lines, open-drain, pull-ups. Terminology: Master, Slave, Multi-Master.

2. I2C Protocol Frames & Timing

Start/Stop Conditions, Address Frame (7-bit vs. 10-bit), R/W bit, ACK/NACK mechanism. Data transfer format. I2C timing constraints.

3. Advanced I2C Protocol & Tools

Clock Stretching, Bus Arbitration, Repeated Start condition. Introduction to user-space tools: `i2c-tools` (`i2cdetect`, `i2cget`, `i2cset`). Hands-on: Detecting devices on a real I2C bus.
4. Linux Kernel Modules & Build System
Review of Linux Kernel Module (LKM) structure. `module_init` and `module_exit`. Setting up the Kernel Build System and cross-compilation environment for the target board.

Part 2: Linux I2C Subsystem Components (Sessions 5-8)

5. I2C Subsystem Architecture

Understanding the Linux I2C Framework: Adapter, Algorithm, Client, and Driver. The role of the Bus structure in the Linux Device Model.

6. I2C Adapter and Algorithm

The role of `struct i2c_adapter` and `struct i2c_algorithm`. Introduction to the core function: `master_xfer`. Implementing a dummy I2C Adapter driver.

7. I2C Client and Device Tree

The role of `struct i2c_client` (the device on the bus). Introduction to **Device Tree (DT)**: Structure, properties (`reg`, `compatible`). **Instantiating I2C devices** via Device Tree. |

8. I2C Client Driver Structure

The role of `struct i2c_driver`. The `probe` and `remove` functions. Matching client and driver: `i2c_device_id` table and DT compatible string.
Part 3: I2C Controller Driver from Scratch (Sessions 9-12)
This part focuses on the low-level Adapter side, which handles the hardware specifics. This is the "Bus Driver."
9. Platform Devices & MMIO Access
Need for Platform Drivers/Devices for non-discoverable hardware (like an on-chip I2C controller). Registering the platform driver. Accessing hardware registers using `ioremap` and `readl/writel`.

10. Low-Level Master Transfer Implementation

Developing the `master_xfer` logic: Generating Start/Stop conditions and transferring address/data by writing to hardware registers. Polling for transfer completion.
11. Interrupt-Driven I2C Controller (Part 1)
Introduction to Interrupt Handling (`request_irq`, `ISR`). Moving the `master_xfer` logic to be interrupt-driven for better performance.
12. Interrupt-Driven I2C Controller (Part 2)
Advanced interrupt topics: Shared IRQs, Bottom Halves (Tasklets/Workqueues) for deferred processing (if time permits). Finalizing and testing the I2C Controller (Adapter) Driver.
Part 4: I2C Client Device Driver from Scratch (Sessions 13-16)

This part focuses on the high-level Client side, which is the actual device driver. This is the "Device Driver" for an I2C slave chip.
13. Client Driver Implementation Basics

Writing the `i2c_driver` structure for a sample I2C slave (e.g., an EEPROM or Sensor). Implementing the `probe` function: getting the `i2c_client` and device-specific initialization. |

14. Character Device Interface for I2C Client

Integrating the I2C Client Driver with the **Character Device framework** to expose functionality to user space (e.g., creating a `/dev/i2c_dev`). |

15. I2C Data Transfer APIs

Using the Linux I2C subsystem APIs: `i2c_master_send`, `i2c_master_recv`, and `i2c_transfer` within the driver's `read/write` functions. **Practical lab: Reading a device ID** from the slave chip. |

16. `ioctl` and Device-Specific Commands

Implementing the **`ioctl`** interface to handle device-specific commands (e.g., setting a sensor's sampling rate, reading a specific register). |
Part 5: Advanced Topics and Final Project (Sessions 17-20)

17. Power Management & Error Handling

Incorporating power management hooks (`.suspend`, `.resume`) into the driver. Robust error handling and debugging techniques for I2C communication (e.g., retries, timeouts).

18. Device Tree Overlays and Dynamic Device Instantiation

Working with Device Tree Overlays (DTO) to modify the device tree at runtime. Dynamic device instantiation using sysfs (`new_device`).

19. Project: Complete Driver Integration

Consolidating all learned components: Ensuring the Controller Driver (Adapter) and Client Driver can communicate seamlessly through the I2C framework.

20. Review, Debugging, and Next Steps

Review of the I2C transfer flow from User-Space -> Char Device -> Client Driver -> I2C Subsystem -> Adapter Driver -> Hardware. Advanced kernel debugging techniques (`debugfs`, tracing). Q&A and career path discussion.


Go to Top ^