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:
3. Interrupt Configuration¶
23→ GPIO numberIRQ_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:
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:
Use MCU to generate clean signal:
Advantages:
- Debounce handled in MCU
- Stable timing
- Reliable interrupt triggering
Takeaways¶
interrupts≠ GPIO configurationpinctrlis mandatory for stable IRQ- Always ensure:
- idle level
- correct edge
- proper wiring
Next Steps¶
- Combine polling + interrupt mode
- Add
irq_enablecontrol - Optimize workqueue handling