Skip to main content





The SPI class represents an SPI synchronous serial port. imp SPI buses are completely independent. Objects representing a given imp’s specific SPI buses are automatically instantiated at start-up and are accessed through the following object properties of the hardware object:

imp SPI 1 SPI 2 SPI 3 SPI 4 SPI 5
imp001 hardware.spi189 hardware.spi257
imp002 hardware.spi189 hardware.spi257
imp003 hardware.spiEBCA hardware.spiLGDK
imp004m hardware.spiAHSR hardware.spiGJKL
imp005 hardware.spiBCAD hardware.spi0
imp006 hardware.spiEFGH hardware.spiXABCD hardware.spiXPQRS hardware.spiXTUVW
impC001 hardware.spiDCAB hardware.spiPQRS hardware.spiEVMT hardware.spiYJTHU hardware.spiYRFES

The imp005’s second SPI bus is accessed via dedicated pins rather than GPIO, hence the slightly different nomenclature.

SPI always clocks data in both the read and write directions simultaneously — please see SPI Explained for more information. Most of the time, the data in one direction is simply filler, so the API behaves as if that filler data doesn’t exist: the spi.readblob() and spi.readstring() calls also write filler data, and the write call also reads and ignores filler data. Use spi.writeread() for those few occasions when the data in both directions is valid.

Currently, the imp must be the SPI controller; peripheral mode may be supported in a future firmware revision.

The imp001 and imp002 do not provide a chip-select (CS) line in their SPI buses. If needed, CS lines can be driven separately using a digital output and pin.write(). Other imps do provide a CS line, but it is driven only in certain SPI modes (byte sync).

  • For more information on each imp’s pin-out, see the imp pin mux.

Member Entities

The SPI object has the following member methods:

The SPI object also has the following deprecated member method, which should not be used in new code, but are documented here as an aid to understanding and migrating old code:

  • last byte read from the SPI port