Data Structures | Macros | Typedefs | Enumerations | Functions
SPI.h File Reference

Detailed Description

Serial Peripheral Interface (SPI) Driver Interface.


Overview

The Serial Peripheral Interface (SPI) driver is a generic, full-duplex driver that transmits and receives data on a SPI bus. SPI is sometimes called SSI (Synchronous Serial Interface). The SPI protocol defines the format of a data transfer over the SPI bus, but it leaves flow control, data formatting, and handshaking mechanisms to higher-level software layers.

The SPI driver operates on some key definitions and assumptions:


Usage

To use the SPI driver to send data over the SPI bus, the application calls the following APIs:

Synopsis

The following code example opens a SPI instance as a master SPI, and issues a transaction.

SPI_Params spiParams;
SPI_Transaction spiTransaction;
uint8_t transmitBuffer[MSGSIZE];
uint8_t receiveBuffer[MSGSIZE];
bool transferOK;
SPI_init(); // Initialize the SPI driver
SPI_Params_init(&spiParams); // Initialize SPI parameters
spiParams.dataSize = 8; // 8-bit data size
spi = SPI_open(Board_SPI0, &spiParams);
if (spi == NULL) {
while (1); // SPI_open() failed
}
// Fill in transmitBuffer
spiTransaction.count = MSGSIZE;
spiTransaction.txBuf = (void *)transmitBuffer;
spiTransaction.rxBuf = (void *)receiveBuffer;
transferOK = SPI_transfer(spi, &spiTransaction);
if (!transferOK) {
// Error in SPI or transfer already in progress.
while (1);
}

More details on usage are provided in the following subsections.

Examples

Initializing the SPI Driver

SPI_init() must be called before any other SPI APIs. This function iterates through the elements of the SPI_config[] array, calling the element's device implementation SPI initialization function.

Opening the SPI Driver

After initializing the SPI driver by calling SPI_init(), the application can open a SPI instance by calling SPI_open(). This function takes an index into the SPI_config[] array, and a SPI parameters data structure. The SPI instance is specified by the index of the SPI in SPI_config[]. Calling SPI_open() a second time with the same index previously passed to SPI_open() will result in an error. You can, though, re-use the index if the instance is closed via SPI_close().

If no SPI_Params structure is passed to SPI_open(), default values are used. If the open call is successful, it returns a non-NULL value.

Example opening a SPI driver instance in blocking mode:

SPI_Params spiParams;
SPI_Params_init(&spiParams);
spi = SPI_open(Board_SPI0, &spiParams);
if (spi == NULL) {
// Error opening SPI
while(1);
}

Example opening a SPI driver instance in callback mode:

SPI_Params spiParams;
SPI_Params_init(&spiParams);
spiParams.transferCallbackFxn = UserCallbackFxn;
spi = SPI_open(Board_SPI0, &spiParams);
if (spi == NULL) {
// Error opening SPI
while (1);
}

SPI Parameters

The SPI_Params structure is passed to the SPI_open() call. If NULL is passed for the parameters, SPI_open() uses default parameters. A SPI_Params structure is initialized with default values by passing it to SPI_Params_init(). Some of the SPI parameters are described below. To see brief descriptions of all the parameters, see SPI_Params.

SPI Mode

The SPI driver operates in both SPI master and SPI slave modes. Logically, the implementation is identical, however the difference between these two modes is driven by hardware. The default mode is SPI_MASTER, but can be set to slave mode by setting SPI_Params.mode to SPI_SLAVE in the parameters passed to SPI_open(). See Master/Slave Modes for further details.

SPI Transfer Mode

The SPI driver supports two transfer modes of operation: blocking and callback. The transfer mode is determined by the transferMode parameter in the SPI_Params data structure. The SPI driver defaults to blocking mode, if the application does not set it. Once a SPI driver is opened, the only way to change the operation mode is to close and re-open the SPI instance with the new transfer mode.

In blocking mode, a task's code execution is blocked until a SPI transaction has completed or a timeout has occurred. This ensures that only one SPI transfer operates at a given time. Other tasks requesting SPI transfers while a transfer is currently taking place will receive a FALSE return value. If a timeout occurs the transfer is canceled, the task is unblocked & will receive a FALSE return value. The transaction count field will have the amount of frames which were transferred successfully before the timeout. In blocking mode, transfers cannot be performed in software or hardware ISR context.

In callback mode, a SPI transaction functions asynchronously, which means that it does not block code execution. After a SPI transaction has been completed, the SPI driver calls a user-provided hook function. Callback mode is supported in the execution context of tasks and hardware interrupt routines.

SPI Frame Formats and Data Size

The SPI driver can configure the device's SPI peripheral to transfer data in several SPI format options: SPI (with various polarity and phase settings), TI, and Micro-wire. The frame format is set with SPI_Params.frameFormat. Some SPI implementations may not support all frame formats & the SPI driver will fail to opened. Refer to the device specific implementation documentation for details on which frame formats are supported.

The smallest single unit of data transmitted onto the SPI bus is called a SPI frame and is of size SPI_Params.dataSize. A series of SPI frames transmitted/received on a SPI bus is referred to as a SPI transaction.

SPI Transactions

A SPI transaction consists of a series of SPI frames transmitted/received on a SPI bus. A SPI transaction is performed using SPI_transfer(). SPI_transfer() accepts a pointer to a SPI_Transaction structure that dictates the quantity of data to be sent and received. The SPI_Transaction.txBuf and SPI_Transaction.rxBuf are both pointers to data buffers. If txBuf is NULL, the driver sends SPI frames with all data set to the default value specified in the hardware attributes. If rxBuf is NULL, the driver discards all SPI frames received. SPI_transfer() of a SPI transaction is performed atomically.

Warning
The use of NULL as a sentinel txBuf or rxBuf value to determine whether the SPI transaction includes a tx or rx component implies that it is not possible to perform a transmit or receive transfer directly from/to a buffer with a base address of 0x00000000. To support this rare use-case, the application will have to manually copy the contents of location 0x00000000 to/from a temporary buffer before/after the tx/rx SPI transaction.

When the SPI is opened, the dataSize value determines the element types of txBuf and rxBuf. If the dataSize is from 4 to 8 bits, the driver assumes the data buffers are of type uint8_t (unsigned char). If the dataSize is from 8 to 16 bits, the driver assumes the data buffers are of type uint16_t (unsigned short). If the dataSize is greater than 16 bits, the driver assumes the data buffers are uint32_t (unsigned long). Some SPI driver implementations may not support all data sizes; refer to device specific SPI implementation documentation for details on what data sizes are supported.

The optional SPI_Transaction.arg variable can only be used when the SPI driver has been opened in callback mode. This variable is used to pass a user-defined value into the user-defined callback function.

SPI_transfer() always performs full-duplex SPI transactions. This means the SPI simultaneously receives data as it transmits data. The application is responsible for formatting the data to be transmitted as well as determining whether the data received is meaningful. Specifics about SPI frame formatting and data sizes are provided in device-specific data sheets and technical reference manuals.

The following code snippets perform SPI transactions.

Example transferring 6-bit SPI frames. The transmit and receive buffers are of type uint8_t.

SPI_Transaction spiTransaction;
uint8_t transmitBuffer[BUFSIZE];
uint8_t receiveBuffer[BUFSIZE];
bool transferOK;
SPI_Params_init(&spiParams);
spiParams.dataSize = 6;
spi = SPI_open(Board_SPI0, &spiParams);
...
spiTransaction.count = someIntegerValue;
spiTransaction.txBuf = transmitBuffer;
spiTransaction.rxBuf = receiveBuffer;
transferOK = SPI_transfer(spi, &spiTransaction);
if (!transferOK) {
// Error in SPI or transfer already in progress.
}

Example transferring 12-bit SPI frames. The transmit and receive buffers are of type uint16_t.

SPI_Transaction spiTransaction;
uint16_t transmitBuffer[BUFSIZE];
uint16_t receiveBuffer[BUFSIZE];
bool transferOK;
SPI_Params_init(&spiParams);
spiParams.dataSize = 12;
spi = SPI_open(Board_SPI0, &spiParams);
...
spiTransaction.count = someIntegerValue;
spiTransaction.txBuf = transmitBuffer;
spiTransaction.rxBuf = receiveBuffer;
transferOK = SPI_transfer(spi, &spiTransaction);
if (!transferOK) {
// Error in SPI or transfer already in progress.
}

The following example shows an example of a callback function that utilizes the arg parameter.

// SPI is opened with callback function as seen in other examples
// Our goal is to post a semaphore when transfer with sufficient size
// completes.
...
// Pass pointer to an initialized semaphore to callback via arg
spiTransaction.count = someIntegerValue;
spiTransaction.txBuf = transmitBuffer;
spiTransaction.rxBuf = receiveBuffer;
spiTransaction.arg = &mySemaphore;
...
// Our callback function is defined here
void spiCallbackFxn(SPI_Handle spi, SPI_Transaction *tran)
{
sem_t *semPtr = (sem_t *)(tran->arg);
// Post the semaphore if our transaction was more than LIMIT
if (tran->status == SPI_STATUS_SUCCESS &&
tran->count > LIMIT) {
sem_post(semPtr);
}
}

Canceling a transaction

SPI_transferCancel() is used to cancel a SPI transaction when the driver is used in SPI_MODE_CALLBACK mode.

Calling this API while no transfer is in progress has no effect. If a transfer is in progress, it is canceled and the callback functions is called. The SPI_Status status field in the SPI_Transaction structure can be examined within the callback to determine if the transaction succeeded.

Example:

Master/Slave Modes

This SPI driver functions in both SPI master and SPI slave modes. Logically, the implementation is identical, however the difference between these two modes is driven by hardware. As a SPI master, the peripheral is in control of the clock signal and therefore will commence communications to the SPI slave immediately. As a SPI slave, the SPI driver prepares the peripheral to transmit and receive data in a way such that the peripheral is ready to transfer data when the SPI master initiates a transaction.

Asserting on Chip Select

The SPI protocol requires that the SPI master asserts a SPI slave's chip select pin prior to starting a SPI transaction. While this protocol is generally followed, various types of SPI peripherals have different timing requirements as to when and for how long the chip select pin must remain asserted for a SPI transaction.

Commonly, the SPI master uses a hardware chip select to assert and de-assert the SPI slave for every data frame. In other cases, a SPI slave imposes the requirement of asserting the chip select over several SPI data frames. This is generally accomplished by using a regular, general-purpose output pin. Due to the complexity of such SPI peripheral implementations, this SPI driver has been designed to operate transparently to the SPI chip select. When the hardware chip select is used, the peripheral automatically selects/enables the peripheral. When using a software chip select, the application needs to handle the proper chip select and pin configuration. Chip select support will vary per SPI peripheral, refer to the device specific implementation documentation for details on chip select support.


Configuration

In order to use the SPI APIs, the application is required to provide device-specific SPI configuration in the Board.c file. The SPI driver interface defines a configuration data structure:

typedef struct {
SPI_FxnTable const *fxnTablePtr;
void *object;
void const *hwAttrs;

The application must declare an array of SPI_Config elements, named SPI_config[]. Each element of SPI_config[] must be populated with pointers to a device specific SPI driver implementation's function table, driver object, and hardware attributes. The hardware attributes define properties such as the SPI peripheral's base address, and the MOSI and MISO pins. Each element in SPI_config[] corresponds to a SPI instance, and none of the elements should have NULL pointers. There is no correlation between the index and the peripheral designation (such as SPI0 or SPI1). For example, it is possible to use SPI_config[0] for SPI1.

Because the SPI configuration is very device dependent, you will need to check the doxygen for the device specific SPI implementation. There you will find a description of the SPI hardware attributes. Please also refer to the Board.c file of any of your examples to see the SPI configuration.

#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
Include dependency graph for SPI.h:
This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Data Structures

struct  SPI_Transaction
 A SPI_Transaction data structure is used with SPI_transfer(). It indicates how many SPI_FrameFormat frames are sent and received from the buffers pointed to txBuf and rxBuf. The arg variable is an user-definable argument which gets passed to the SPI_CallbackFxn when the SPI driver is in SPI_MODE_CALLBACK. More...
 
struct  SPI_Params
 SPI Parameters. More...
 
struct  SPI_FxnTable
 The definition of a SPI function table that contains the required set of functions to control a specific SPI driver implementation. More...
 
struct  SPI_Config_
 SPI Global configuration. More...
 

Macros

#define SPI_CMD_RESERVED   (32)
 
#define SPI_STATUS_RESERVED   (-32)
 
#define SPI_STATUS_SUCCESS   (0)
 Successful status code returned by SPI_control(). More...
 
#define SPI_STATUS_ERROR   (-1)
 Generic error status code returned by SPI_control(). More...
 
#define SPI_STATUS_UNDEFINEDCMD   (-2)
 An error status code returned by SPI_control() for undefined command codes. More...
 
#define SPI_WAIT_FOREVER   (~(0U))
 Wait forever define used to specify timeouts. More...
 

Typedefs

typedef struct SPI_Config_SPI_Handle
 A handle that is returned from a SPI_open() call. More...
 
typedef void(* SPI_CallbackFxn) (SPI_Handle handle, SPI_Transaction *transaction)
 The definition of a callback function used by the SPI driver when used in SPI_MODE_CALLBACK. More...
 
typedef void(* SPI_CloseFxn) (SPI_Handle handle)
 A function pointer to a driver specific implementation of SPI_close(). More...
 
typedef int_fast16_t(* SPI_ControlFxn) (SPI_Handle handle, uint_fast16_t cmd, void *arg)
 A function pointer to a driver specific implementation of SPI_control(). More...
 
typedef void(* SPI_InitFxn) (SPI_Handle handle)
 A function pointer to a driver specific implementation of SPI_init(). More...
 
typedef SPI_Handle(* SPI_OpenFxn) (SPI_Handle handle, SPI_Params *params)
 A function pointer to a driver specific implementation of SPI_open(). More...
 
typedef bool(* SPI_TransferFxn) (SPI_Handle handle, SPI_Transaction *transaction)
 A function pointer to a driver specific implementation of SPI_transfer(). More...
 
typedef void(* SPI_TransferCancelFxn) (SPI_Handle handle)
 A function pointer to a driver specific implementation of SPI_transferCancel(). More...
 
typedef struct SPI_Config_ SPI_Config
 SPI Global configuration. More...
 

Enumerations

enum  SPI_Status {
  SPI_TRANSFER_COMPLETED = 0, SPI_TRANSFER_STARTED, SPI_TRANSFER_CANCELED, SPI_TRANSFER_FAILED,
  SPI_TRANSFER_CSN_DEASSERT, SPI_TRANSFER_PEND_CSN_ASSERT, SPI_TRANSFER_QUEUED
}
 Status codes that are set by the SPI driver. More...
 
enum  SPI_Mode { SPI_MASTER = 0, SPI_SLAVE = 1 }
 Definitions for various SPI modes of operation. More...
 
enum  SPI_FrameFormat {
  SPI_POL0_PHA0 = 0, SPI_POL0_PHA1 = 1, SPI_POL1_PHA0 = 2, SPI_POL1_PHA1 = 3,
  SPI_TI = 4, SPI_MW = 5
}
 Definitions for various SPI data frame formats. More...
 
enum  SPI_TransferMode { SPI_MODE_BLOCKING, SPI_MODE_CALLBACK }
 SPI transfer mode determines the whether the SPI controller operates synchronously or asynchronously. In SPI_MODE_BLOCKING mode SPI_transfer() blocks code execution until the SPI transaction has completed. In SPI_MODE_CALLBACK SPI_transfer() does not block code execution and instead calls a SPI_CallbackFxn callback function when the transaction has completed (successfully or not). More...
 

Functions

void SPI_close (SPI_Handle handle)
 Function to close a SPI peripheral specified by the SPI handle. More...
 
int_fast16_t SPI_control (SPI_Handle handle, uint_fast16_t cmd, void *controlArg)
 Function performs implementation specific features on a given SPI_Handle. More...
 
void SPI_init (void)
 This function initializes the SPI module. More...
 
SPI_Handle SPI_open (uint_least8_t index, SPI_Params *params)
 This function opens a given SPI peripheral. More...
 
void SPI_Params_init (SPI_Params *params)
 Function to initialize the SPI_Params struct to its defaults. More...
 
bool SPI_transfer (SPI_Handle handle, SPI_Transaction *transaction)
 Function to perform SPI transactions. More...
 
void SPI_transferCancel (SPI_Handle handle)
 Function to cancel SPI transactions. More...
 

Macro Definition Documentation

§ SPI_WAIT_FOREVER

#define SPI_WAIT_FOREVER   (~(0U))

Wait forever define used to specify timeouts.

Typedef Documentation

§ SPI_Handle

typedef struct SPI_Config_* SPI_Handle

A handle that is returned from a SPI_open() call.

§ SPI_CallbackFxn

typedef void(* SPI_CallbackFxn) (SPI_Handle handle, SPI_Transaction *transaction)

The definition of a callback function used by the SPI driver when used in SPI_MODE_CALLBACK.

Parameters
SPI_HandleA SPI_Handle
SPI_Transaction*Pointer to a SPI_Transaction

§ SPI_CloseFxn

typedef void(* SPI_CloseFxn) (SPI_Handle handle)

A function pointer to a driver specific implementation of SPI_close().

§ SPI_ControlFxn

typedef int_fast16_t(* SPI_ControlFxn) (SPI_Handle handle, uint_fast16_t cmd, void *arg)

A function pointer to a driver specific implementation of SPI_control().

§ SPI_InitFxn

typedef void(* SPI_InitFxn) (SPI_Handle handle)

A function pointer to a driver specific implementation of SPI_init().

§ SPI_OpenFxn

typedef SPI_Handle(* SPI_OpenFxn) (SPI_Handle handle, SPI_Params *params)

A function pointer to a driver specific implementation of SPI_open().

§ SPI_TransferFxn

typedef bool(* SPI_TransferFxn) (SPI_Handle handle, SPI_Transaction *transaction)

A function pointer to a driver specific implementation of SPI_transfer().

§ SPI_TransferCancelFxn

typedef void(* SPI_TransferCancelFxn) (SPI_Handle handle)

A function pointer to a driver specific implementation of SPI_transferCancel().

§ SPI_Config

typedef struct SPI_Config_ SPI_Config

SPI Global configuration.

The SPI_Config structure contains a set of pointers used to characterize the SPI driver implementation.

This structure needs to be defined before calling SPI_init() and it must not be changed thereafter.

See also
SPI_init()

Enumeration Type Documentation

§ SPI_Status

enum SPI_Status

Status codes that are set by the SPI driver.

Enumerator
SPI_TRANSFER_COMPLETED 

SPI transfer completed

SPI_TRANSFER_STARTED 

SPI transfer started and in progress

SPI_TRANSFER_CANCELED 

SPI transfer was canceled

SPI_TRANSFER_FAILED 

SPI transfer failed

SPI_TRANSFER_CSN_DEASSERT 

SPI chip select was de-asserted (only applicable in return partial mode)

SPI_TRANSFER_PEND_CSN_ASSERT 

SPI transfer is pending until the chip select is asserted

SPI_TRANSFER_QUEUED 

SPI transfer added to transaction queue

§ SPI_Mode

enum SPI_Mode

Definitions for various SPI modes of operation.

Enumerator
SPI_MASTER 

SPI in master mode

SPI_SLAVE 

SPI in slave mode

§ SPI_FrameFormat

Definitions for various SPI data frame formats.

Enumerator
SPI_POL0_PHA0 

SPI mode Polarity 0 Phase 0

SPI_POL0_PHA1 

SPI mode Polarity 0 Phase 1

SPI_POL1_PHA0 

SPI mode Polarity 1 Phase 0

SPI_POL1_PHA1 

SPI mode Polarity 1 Phase 1

SPI_TI 

TI mode (not supported on all implementations)

SPI_MW 

Micro-wire mode (not supported on all implementations)

§ SPI_TransferMode

SPI transfer mode determines the whether the SPI controller operates synchronously or asynchronously. In SPI_MODE_BLOCKING mode SPI_transfer() blocks code execution until the SPI transaction has completed. In SPI_MODE_CALLBACK SPI_transfer() does not block code execution and instead calls a SPI_CallbackFxn callback function when the transaction has completed (successfully or not).

Enumerator
SPI_MODE_BLOCKING 

SPI_transfer() blocks execution. This mode can only be used when called within a Task context

SPI_MODE_CALLBACK 

SPI_transfer() does not block code execution and will call a SPI_CallbackFxn. This mode can be used in a Task, software or hardware interrupt context.

Function Documentation

§ SPI_close()

void SPI_close ( SPI_Handle  handle)

Function to close a SPI peripheral specified by the SPI handle.

Precondition
SPI_open() has to be called first.
Parameters
handleA SPI_Handle returned from SPI_open()
See also
SPI_open()

§ SPI_control()

int_fast16_t SPI_control ( SPI_Handle  handle,
uint_fast16_t  cmd,
void *  controlArg 
)

Function performs implementation specific features on a given SPI_Handle.

Commands for SPI_control can originate from SPI.h or from implementation specific SPI*.h (SPICC26XXDMA.h, SPIMSP432DMA.h, etc.. ) files. While commands from SPI.h are API portable across driver implementations, not all implementations may support all these commands. Conversely, commands from driver implementation specific SPI*.h files add unique driver capabilities but are not API portable across all SPI driver implementations.

Commands supported by SPI.h follow a SPI_CMD_<cmd> naming convention.
Commands supported by SPI*.h follow a SPI*_CMD_<cmd> naming convention.
Each control command defines arg differently. The types of arg are documented with each command.

See SPI_control command codes for command codes.

See SPI_control return status codes for status codes.

Precondition
SPI_open() has to be called first.
Parameters
handleA SPI_Handle returned from SPI_open()
cmdSPI.h or SPI*.h commands.
controlArgAn optional R/W (read/write) command argument accompanied with cmd
Returns
Implementation specific return codes. Negative values indicate unsuccessful operations.
See also
SPI_open()

§ SPI_init()

void SPI_init ( void  )

This function initializes the SPI module.

Precondition
The SPI_config[] array must exist and be persistent before this function can be called. This function must also be called before any other SPI driver APIs. This function call does not modify any peripheral registers.

§ SPI_open()

SPI_Handle SPI_open ( uint_least8_t  index,
SPI_Params params 
)

This function opens a given SPI peripheral.

Precondition
SPI controller has been initialized using SPI_init()
Parameters
indexIndex of config to use in the SPI_config array
paramsPointer to an parameter block, if NULL it will use default values. All the fields in this structure are RO (read-only).
Returns
A SPI_Handle on success or a NULL on an error or if it has been opened already.
See also
SPI_init()
SPI_close()

§ SPI_Params_init()

void SPI_Params_init ( SPI_Params params)

Function to initialize the SPI_Params struct to its defaults.

Parameters
paramsAn pointer to SPI_Params structure for initialization

Defaults values are:

§ SPI_transfer()

bool SPI_transfer ( SPI_Handle  handle,
SPI_Transaction transaction 
)

Function to perform SPI transactions.

If the SPI is in SPI_MASTER mode, it will immediately start the transaction. If the SPI is in SPI_SLAVE mode, it prepares the driver for a transaction with a SPI master device. The device will then wait until the master begins the transfer.

In SPI_MODE_BLOCKING, SPI_transfer() will block task execution until the transaction has completed or a timeout has occurred.

In SPI_MODE_CALLBACK, SPI_transfer() does not block task execution, but calls a SPI_CallbackFxn once the transfer has finished. This makes SPI_tranfer() safe to be used within a Task, software or hardware interrupt context. If queued transactions are supported SPI_Transfer may be called multiple times to queue multiple transactions. If the driver does not support this functionality additional calls will return false. Refer to device specific SPI driver documentation for support information.

From calling SPI_transfer() until transfer completion, the SPI_Transaction structure must stay persistent and must not be altered by application code. It is also forbidden to modify the content of the SPI_Transaction.txBuf during a transaction, even though the physical transfer might not have started yet. Doing this can result in data corruption. This is especially important for slave operations where SPI_transfer() might be called a long time before the actual data transfer begins.

Parameters
handleA SPI_Handle
transactionA pointer to a SPI_Transaction. All of the fields within transaction except SPI_Transaction.count and SPI_Transaction.status are WO (write-only) unless otherwise noted in the driver implementations. If a transaction timeout has occurred, SPI_Transaction.count will contain the number of frames that were transferred. Neither is it allowed to modify the transaction object nor the content of SPI_Transaction.txBuf until the transfer has completed.
Returns
true if started successfully; else false
See also
SPI_open
SPI_transferCancel

§ SPI_transferCancel()

void SPI_transferCancel ( SPI_Handle  handle)

Function to cancel SPI transactions.

In SPI_MODE_BLOCKING, SPI_transferCancel has no effect.

In SPI_MODE_CALLBACK, SPI_transferCancel() will stop an SPI transfer if if one is in progress. If a transaction was in progress, its callback function will be called in context from which this API is called from. The SPI_CallbackFxn function can determine if the transaction was successful or not by reading the SPI_Status status value in the SPI_Transaction structure.

Precondition
SPI_init(), SPI_open(), SPI_transfer() are called
Parameters
handleA SPI_Handle
See also
SPI_open
SPI_transfer
© Copyright 1995-2019, Texas Instruments Incorporated. All rights reserved.
Trademarks | Privacy policy | Terms of use | Terms of sale