Skip to content

Day28 - SPI IRQ and Dual-Bus Integration

Overview

In Day28, we extended the existing sensor driver framework by adding interrupt (IRQ) support for SPI transport and validating a dual-bus hybrid model (IRQ + polling) across both I2C and SPI.

The core design goal was to:

  • Keep the core layer bus-agnostic
  • Add IRQ support without breaking abstraction
  • Reuse the same update logic for:
  • I2C
  • SPI
  • IRQ
  • polling
  • on-demand access

Architecture Recap

The driver is structured as:

Transport Layer (I2C / SPI)
        ↓
   mysensor_core
        ↓
     hwmon
        ↓
     sysfs
  • Transport layer:
  • Implements read_reg() / write_reg()
  • Provides bus_ctx

  • Passes irq to core

  • Core layer:

  • Manages:
    • cache
    • update policy
    • IRQ handling
    • polling
  • Completely bus-agnostic

SPI Protocol Behavior

Unlike I2C, SPI does not define a standard read protocol.

Our SPI slave (STM32) uses a two-frame pipeline protocol:

Frame 1:
  MOSI → READ command
  MISO ← dummy / previous data

Frame 2:
  MOSI → NOP
  MISO ← actual register value

This is a common SPI pattern due to:

  • full-duplex nature
  • slave processing latency

IRQ Design

IRQ Ownership

IRQ is handled in the core layer, not in SPI driver.

Reason:

  • Keeps transport layer simple
  • Allows reuse for both I2C and SPI
  • Maintains clean abstraction

IRQ Flow

IRQ (GPIO interrupt)
   ↓
core IRQ handler
   ↓
mysensor_core_refresh()
   ↓
update cache
   ↓
hwmon read returns new data

Hybrid Model

The driver supports three update sources:

  • IRQ
  • polling
  • on-demand

Mode Behavior

Mode IRQ Polling
irq enabled disabled
poll disabled enabled

Debug Interface Design

A custom debug_status sysfs node is added under hwmon.

Example:

/sys/class/hwmon/hwmonX/debug_status

Transport Awareness

Although hwmon device has no bus:

  • hwmon_dev->bus == NULL

We expose transport info via core:

sensor_bus=spi (spi0.0)
sensor_bus=i2c (1-0048)

Important distinction:

  • hwmon device → user interface
  • SPI/I2C device → actual hardware transport

Key Design Principles

  • Keep bus abstraction strict
  • Use struct device *dev for:
  • logging
  • bus identification
  • Keep bus_ctx as opaque pointer
  • Reuse core update logic for all paths

Summary

Day28 achieved:

  • SPI IRQ support
  • Dual-bus (I2C + SPI) integration
  • Unified update mechanism
  • Debug visibility for:
  • transport
  • update source
  • event counters