Simple Peripheral Bus (SPB)
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||
"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
|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)||
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.
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.
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.
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.
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|
Chip select line
Device selection polarity
Controller address / pin
Configure initial baud rate
Initial baud rate
Start bit and stop bit length
Flow control method(Hardware/Software/None)
Lines in use
Receive buffer size
Transmit buffer size
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|