Share via

Simple Peripheral Bus (SPB)

  • Article

Note

This article contains references to the term slave, a term that Microsoft no longer uses. When the term is removed from the software, we’ll remove it from this article.

This topic covers recommendations for Simple Peripheral Bus in Windows 10.Windows includes support for low-power, simple buses, such as Inter Integrated Circuit (I²C) and (I²C) and Simple Peripheral Interface (SPI), using framework extensions of the Kernel Mode Driver Framework (KMDF) architecture. Controller drivers are not provided in-box. Chipset vendors, OEMs, or IHVs must develop a controller driver implemented in KMDF. The architecture provides flexible device configuration topologies supporting simultaneous use of buses for control and data transactions, as well as GPIO for signaling and interrupts. The complete device definition is defined through Advanced Configuration and Power Interface (ACPI).

In Windows, buses are supported through KMDF controller drivers. With the aid of the KMDF platform, the controller driver is used predominantly to define the hardware-specific interfaces necessary to enable controller function.

The Windows infrastructure supports devices that share buses, buses that are multiplexed on the same line, and device configuration through ACPI. Windows uses ACPI as the primary means for device identification, configuration, and control.

The following table summarizes the support for the Simple Peripheral Bus.

Bus Inbox Support Framework extension provided Third party allowed Additional support details
I²C No Yes Yes, using SPB Framework extension

Master only

"General Call" is not supported

Direct Memory Access (DMA) supported
SPI No Yes Yes, using SPB Framework extension

Master only, "General Call" is not supported

Full duplex supported

DMA supported
MIPI-HSI No No Yes, using Windows Driver Foundation (WDF)
MIPI-SLIMbus No No Yes, using WDF
MIPI-CSI No No Yes, using WDF
UART No Yes Yes, using Serial Framework extension (SerCx2)

DMA supported

Custom transfer modes supported with SerCx2

Design considerations for SPB

The following are some generic considerations for SPB:

  • SPB is not a Plug and Play bus. Peripheral devices typically have fixed connections to an SPB and cannot be removed. System manufacturers must ensure accurate information in ACPI to enumerate the SPB-connected peripheral devices for the Plug and Play manager, and specifies the hardware resources that are dedicated to each device.

  • There is no in-band interrupt support for SPB. Most peripherals support device signaling through a separate interrupt (often GPIO based) mechanism, and accurately mapped in ACPI.

  • Windows provides support for the SPB Class Extension (spbcx.sys) in Windows 8 and beyond. SoC partners are responsible for developing and redistributing their appropriate SPB Controller driver.

  • Peripheral drivers for SPB devices are generally provided by SPB Device partners. Microsoft provides one class driver for SPB devices for HID over I²C (hidi2c.sys).

  • Device classes may provide HLK requirements or WEG guidance around the following topics related to I²C:

    • Sharing I²C controller with other devices
    • Preferred I²C signaling speed
    • Power management and wake scenarios over I²C and GPIO.

  • Inter Integrated Circuit (I²C): I²C is the primary bus that is validated as part of SPB and is highly recommended on SoC systems.

    Microsoft provides Windows Hardware Compatibility Program requirements for I²C. Use the Windows Hardware Lab Kit (HLK) to test devices against those requirements.

  • Simple Peripheral Interface (SPI): Support for SPI is optional and up to the SoC partner. The Windows Hardware Compatibility Program does not contain any requirements specific to SPI bus.

Support for SPB across systems

Microsoft supports SPB on Arm systems and x86/x64 platforms (running in S3 configurations). Microsoft supports SPB on platforms running in both Connected Standby (CS) and S3 configurations.

Please contact your platform provider for drivers and support.

There are a number of device scenarios that leverage SPB for connectivity. I²C is available on CS and S3 traditional power model. Modern SoCs with on-SoC sensor low power cores can implement non-I²C solutions as needed.

Devices on removable docks/ports should also follow the guidance around docking scenarios, also included in the WEG. Some of those devices may make more sense over buses like USB rather than I²C.

SPB framework extension

The SPB framework extension library extends the Windows Driver Framework to support SPB drivers. The SPB framework simplifies development of an SPB controller driver and improves the compatibility between peripheral drivers and the controller driver by providing common implementation of the "top-half" of the driver that processes I/O requests (as compared to the "bottom-half", which is driven by the top-half and controls the hardware). The SPB Framework Extension is a KMDF extension library. It handles the up-front processing of SPB request and the sequence in which they are handed to the controller driver. The SPB framework extension is designed to support I²C and SPI buses, and may be appropriate for other buses with similar semantics.

Serial Framework extension

The serial framework extension library extends the Windows driver framework to support serial controller drivers. Similarly to the SPB framework, the serial framework simplifies development of a serial controller driver and improves the compatibility between peripheral drivers and the controller driver by providing common implementation of the "top-half" of the driver that processes I/O requests. The serial framework extension is a KMDF extension library. It handles the up-front processing of the calls to the serial APIs and the sequence in which they are handed to the controller driver. The serial framework extension is designed to support the modern UART controllers and simplify controller driver implementation and diagnosability.

I²C and UART HLK requirements

There are Hardware Compatibility Program requirements for I²C and UART controllers. Requirements for SPI are being considered for the future as well. The logo requirements are primarily intended for SoC silicon vendors for the bus interface hardware and the associated controller drivers. OEMs and ODMs are not required to revalidate the hardware or controller driver but are welcome to run the tests if desired. Special set-up steps are required to validate these requirements. The setup includes the following:

  • An open system with accessible I²C /UART pins/ports
  • Modifications in ACPI to expose the I²C/ UART test device to software
  • A specific test device (WITT) attached to the system under validation

For additional set-up information, please refer to the Hardware Lab Kit (HLK) documentation.

Peripheral drivers

Peripherals are enumerated by ACPI and are generally static. Peripheral function drivers determine their appropriate bus resources by interacting with the framework extensions. Peripherals and controllers are not hierarchical, and peripherals may use several SPB, GPIO, Serial, and other high speed buses. Peripheral drivers that access embedded devices, such as sensors, input devices, modems, and radios, may be written in kernel mode or user mode. These drivers may be portable across different ODM or OEM board configurations as long as ACPI is updated appropriately.

Firmware

Controller ACPI settings and bus parameters are vendor-specific and dependent on the particular controller. The following table summarizes the ACPI settings for the controller and the peripheral bus.

Bus Controller ACPI settings Peripheral ACPI settings
I²C

Controller addresses

Pin configuration

Bus address

Clock rate

Slave mode

Addressing mode
SPI

Controller addresses

Pin configuration

Chip select line

Clock rate

Clock polarity

Clock phase

Wire mode

Device selection

Device selection polarity

Slave mode
UART

Controller address / pin

Configure initial baud rate

Initial baud rate

Parity

Start bit and stop bit length

Flow control method(Hardware/Software/None)

Lines in use

Receive buffer size

Transmit buffer size

Endian-ness

For an ACPI example, see How to Get the Connection Settings for a Device. For more information about how to integrate devices on low power buses, see Accessing GPIO, I2C, and UART Devices.

Tools and technical reference

Resource Title Content type Description Link
Using the Windows Driver Framework to build better drivers Video Discusses how the WDF can improve driver reliability and how to better realize power-savings and deploy drivers on multiple versions of Windows. Channel 9
Understanding Low-Power Buses Video Demonstrates how to integrate a device on the new buses and create a driver. You will learn how to write ACPI to enumerate your peripheral and get started writing and testing a peripheral driver. Channel 9
Kernel-Mode Driver Framework Design Guide Article Introduces Kernel-Mode Driver Framework (KMDF). MSDN
UMDF 1.x Design Guide Article Introduces User-Mode Driver Framework (UMDF). MSDN
Windows Hardware Compatibility Program Article Provides information on the Windows Certification Program. MSDN