...
The functions which must be implemented are listed and described in Table C-4 the table below. SPI is no more than a physical interconnect. The protocol of command-response interchange the master follows to control a slave is specified on a per-slave basis. Control of the chip select (SSEL) is separated from the reading and writing of data to the slave because multiple bus transactions (e.g., a read then a write then another read) are often performed without breaking slave selection. Indeed, some slaves require bus transactions (or “empty” clocks) AFTER the select has been disabled.
...
Function
...
Description
...
Open()
...
Open (initialize) hardware for SPI.
...
Close()
...
Close (uninitialize) hardware for SPI.
...
Lock()
...
Acquire SPI bus lock.
...
Unlock()
...
.
...
Rd()
...
Read from SPI bus.
...
Wr()
...
Write to SPI bus.
...
ChipSelEn()
...
Enable device chip select.
...
ChipSelDis()
...
Disable device chip select
...
SetClkFreq()
...
Set SPI clock frequency
Table C-4 SPI port functions
The first argument of each of these port functions is the device unit number, an identifier unique to each driver/device type—after all, it is the number in the device name. For example, “sd:0:” and “nor:0:” both have unit number 1. If two SPI devices are located on the same SPI bus, either of two approaches can resolve unit number conflicts:
- Unique unit numbers. All devices on the same bus can use the same SPI BSP if and only if each device has a unique unit number. For example, the SD/MMC card “sd:0:” and serial NOR “nor:1:” require only one BSP.
- Unique SPI BSPs. Devices of different types (e.g., a SD/MMC card and a serial NOR) can have the same unit number if and only if each device uses a separate BSP. For example, the SD/MMC card “sd:0:” and serial “nor:0:” require separate BSPs.