Skip to content

Day23 - I2C Sensor with Interrupt (IRQ)

Overview

In this lab, we extend the I2C sensor driver to support hardware interrupt (IRQ).

Previously: - Day19: Basic I2C driver - Day20: hwmon integration - Day22: Polling mode

Now: - Day23: Interrupt-driven update


Key Concept

1. GPIO Interrupt vs gpiod

Item gpiod (GPIO driver) interrupts (IRQ)
Ownership Driver controls GPIO Hardware wiring
Direction Explicit (GPIOD_IN) Implicit input
Pull-up/down Often handled ❗ Must use pinctrl
IRQ mapping gpiod_to_irq() From Device Tree

👉 interrupts only describes wiring, not configuration.


2. Role of pinctrl

pinctrl is responsible for:

  • Pin mux (GPIO vs ALT)
  • Pull-up / pull-down
  • Electrical configuration

Example:

my_sensor_pins: my_sensor_pins {
    brcm,pins = <23>;
    brcm,function = <0>;   // GPIO mode
    brcm,pull = <2>;       // pull-up
};

Attach to device:

pinctrl-names = "default";
pinctrl-0 = <&my_sensor_pins>;

3. Interrupt Configuration

interrupt-parent = <&rp1_gpio>;
interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
  • 23 → GPIO number
  • IRQ_TYPE_EDGE_FALLING → trigger type

4. IRQ Flow

STM32 GPIO (PA8)
Raspberry Pi GPIO23
pinctrl (pull-up, GPIO mode)
IRQ subsystem
request_irq()
ISR (top half)
workqueue (bottom half)
I2C read sensor

5. Why Interrupt Didn't Work Initially

Even though IRQ was registered:

/proc/interrupts → counter = 0

Root cause:

  • GPIO had no pull-up
  • No stable idle high level
  • No valid falling edge

Fix:

  • Add pinctrl with pull-up

6. Hardware Design Pattern

Instead of using raw button signal:

Button → (noisy)

Use MCU to generate clean signal:

Button → STM32 → Clean pulse → Pi IRQ

Advantages:

  • Debounce handled in MCU
  • Stable timing
  • Reliable interrupt triggering

Takeaways

  • interrupts ≠ GPIO configuration
  • pinctrl is mandatory for stable IRQ
  • Always ensure:
  • idle level
  • correct edge
  • proper wiring

Next Steps

  • Combine polling + interrupt mode
  • Add irq_enable control
  • Optimize workqueue handling