spidev is a Python module for talking to SPI devices through the Linux spidev kernel driver. That means native Windows does not expose the same /dev/spidev* device files that Raspberry Pi and other Linux boards use. The Python spidev project page describes the module as an interface to SPI devices from user space through the Linux kernel driver.
For Windows projects, the practical answer is usually not “install spidev.” Instead, choose a Windows-compatible SPI path: a USB-to-SPI adapter, an FTDI bridge with PyFtdi, a microcontroller that exposes SPI over serial, or a hardware vendor SDK. The right option depends on the device, voltage levels, driver support, and whether you need desktop Python or a Linux-capable board.
WSL can run Linux user-space tools, but it does not magically create SPI pins on a Windows laptop. You still need hardware that Windows can expose to the environment. For most desktop setups, a supported USB bridge is more predictable than trying to make Linux spidev access unavailable Windows hardware.
If you are writing code that must run on more than one operating system, detect the platform and keep hardware-specific code behind a small interface. For related project hygiene, see the Python testing framework guide and the Python file-exists guide.
Detect Windows Before Importing spidev
Do not import spidev unconditionally in code that may run on Windows. Check the platform first and choose the backend that matches the machine.
import platform
system_name = platform.system()
if system_name == "Windows":
backend = "usb_spi_adapter"
else:
backend = "linux_spidev"
print(backend)
This does not solve SPI by itself, but it prevents a Windows import failure from hiding the real decision. Your application can then select a PyFtdi, serial, vendor SDK, or Linux backend explicitly.
Use spidev On Linux Boards
On Linux boards that expose SPI through the kernel driver, spidev remains the normal Python choice. Keep Linux code isolated so the rest of the program can be tested on Windows without hardware.
def transfer_with_linux_spidev(payload):
import spidev
spi = spidev.SpiDev()
spi.open(0, 0)
spi.max_speed_hz = 500_000
try:
return spi.xfer2(payload)
finally:
spi.close()
This function belongs in a Linux-specific adapter module. It should not be called on Windows unless you are using a Linux environment that actually has access to the SPI hardware.
Use PyFtdi With USB-to-SPI Hardware
For desktop Python on Windows, a USB-to-SPI adapter is often the cleanest path. PyFtdi supports FTDI devices with SPI, I2C, GPIO, and UART-style interfaces. The PyFtdi SPI API documentation shows how its SPI controller and ports are organized.
from pyftdi.spi import SpiController
def read_id_with_pyftdi():
spi = SpiController()
spi.configure("ftdi://ftdi:232h/1")
slave = spi.get_port(cs=0, freq=1_000_000, mode=0)
try:
return list(slave.exchange([0x9F], 3))
finally:
spi.terminate()
The exact URL and chip-select settings depend on your adapter. Confirm wiring, voltage, SPI mode, and clock speed before assuming a software problem. Hardware mismatches often look like Python errors at first.
Install the adapter driver recommended by the hardware vendor and test with a simple command before connecting expensive peripherals. Once basic transfer works, move the values into your application code.
Use A Serial Bridge Through A Microcontroller
Another Windows-friendly option is to let a microcontroller handle SPI and expose a simple serial protocol to the PC. Python then sends commands over COM ports instead of controlling SPI pins directly.
import serial
def send_spi_command(port, payload):
with serial.Serial(port, 115200, timeout=1) as link:
link.write(bytes(payload))
return list(link.read(3))
print(send_spi_command("COM5", [0x9F]))
This architecture is useful when the SPI timing is strict or when the target hardware already has microcontroller firmware. It also keeps Windows driver requirements simpler because Python only needs serial-port access.
The tradeoff is that you need firmware on the microcontroller. In return, the PC-side Python code stays portable and does not need low-level SPI access.
Hide Hardware Behind An Interface
Keep SPI-specific code behind a small interface so the rest of the program can be tested without the real device. A mock backend lets you verify parsing, retries, and error handling on any machine.
class SpiBus:
def transfer(self, payload):
raise NotImplementedError
class MockSpiBus(SpiBus):
def transfer(self, payload):
return [0x12, 0x34, 0x56]
bus = MockSpiBus()
print(bus.transfer([0x9F]))
This pattern works whether the production backend uses Linux spidev, PyFtdi, serial, or a vendor SDK. It also keeps unit tests independent from cables and drivers.
Keep Adapter Settings In Configuration
SPI projects often need a device URL, COM port, mode, speed, and chip-select value. Store those settings outside the transfer code so Windows and Linux setups can use different values without editing the logic.
from pathlib import Path
def load_adapter_url(path="spi_adapter.txt"):
config_path = Path(path)
if not config_path.exists():
return "ftdi://ftdi:232h/1"
return config_path.read_text(encoding="utf-8").strip()
print(load_adapter_url())
Configuration also makes troubleshooting easier. You can log the selected backend and adapter settings before opening the device, which helps distinguish a missing driver from a wiring or code issue.
In short, spidev is the Linux route. On Windows, use a supported adapter library such as PyFtdi, a CircuitPython/Blinka-compatible bridge, a serial microcontroller bridge, or the device vendor’s SDK. Adafruit’s FT232H Windows guide is a useful reference for one Windows-compatible USB bridge workflow.