Device
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).
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: