|
|
SPI driver implementation for a CC32XX SPI controller using the micro DMA controller.
The SPI header file should be included in an application as follows:
Refer to SPI.h for a complete description of APIs & example of use.
This SPI driver implementation is designed to operate on a CC32XX SPI controller using a micro DMA controller.
This SPI controller supports 4 phase & polarity formats. Refer to the device specific data sheets & technical reference manuals for specifics on each format.
This SPI controller supports a hardware chip select pin. Refer to the device's user manual on how this hardware chip select pin behaves in regards to the SPI frame format.
| Chip select type | SPI_MASTER mode | SPI_SLAVE mode |
|---|---|---|
| Hardware chip select | No action is needed by the application to select the peripheral. | See the device documentation on it's chip select requirements. |
| Software chip select | The application is responsible to ensure that correct SPI slave is selected before performing a SPI_transfer(). | See the device documentation on it's chip select requirements. |
SPI data frames can be any size from 4-bits to 32-bits. The SPI data frame size is set in SPI_Params.dataSize passed to SPI_open. The SPICC32XXDMA driver implementation makes assumptions on the element size of the SPI_Transaction txBuf and rxBuf arrays, based on the data frame size. If the data frame size is less than or equal to 8 bits, txBuf and rxBuf are assumed to be arrays of 8-bit uint8_t elements. If the data frame size is greater than 8 bits, but less than or equal to 16 bits, txBuf and rxBuf are assumed to be arrays of 16-bit uint16_t elements. Otherwise, txBuf and rxBuf are assumed to point to 32-bit uint32_t elements.
| data frame size | buffer element size |
|---|---|
| 4-8 bits | uint8_t |
| 9-16 bits | uint16_t |
| 17-32 bits | uint32_t |
Data buffers in transactions (rxBuf & txBuf) must be address aligned according to the data frame size. For example, if data frame is 9-bit (driver assumes buffers are uint16_t) rxBuf & txBuf must be aligned on a 16-bit address boundary, if data frame is 20-bit (driver assumes buffers are uint32_t) rxBuf & txBuf must be aligned on a 32-bit address boundary.
This driver is designed to operate with the micro DMA. The micro DMA generates an interrupt on the perpheral's interrupt vector. This implementation automatically installs a DMA aware hardware ISR to service the assigned micro DMA channels.
As this driver uses uDMA to transfer data/from data buffers, it is the responsibility of the application to ensure that these buffers reside in memory that is accessible by the DMA.
A uint32_t scratch buffer is used to allow SPI_transfers where txBuf or rxBuf are NULL. Rather than requiring txBuf or rxBuf to have a dummy buffer of size of the transfer count, a single DMA accessible uint32_t scratch buffer is used. When rxBuf is NULL, the uDMA will transfer all the SPI data receives into the scratch buffer as a "bit-bucket". When txBuf is NULL, the scratch buffer is initialized to defaultTxBufValue so the uDMA will send some known value. Each SPI driver instance must have its own scratch buffer.
When used in blocking mode small SPI transfers are can be done by polling the peripheral & sending data frame-by-frame. This will not block the task which requested the transfer, but instead immediately perform the transfer & return. The minDmaTransferSize field in the hardware attributes is the threshold; if the transaction count is below the threshold a polling transfer is performed; otherwise a DMA transfer is done. This is intended to reduce the overhead of setting up a DMA transfer to only send a few data frames. Keep in mind that during polling transfers the current task is still being executed; there is no context switch to another task.
#include <ti/drivers/dpl/HwiP.h>#include <ti/drivers/dpl/SemaphoreP.h>#include <ti/drivers/Power.h>#include <ti/drivers/SPI.h>#include <ti/drivers/dma/UDMACC32XX.h>
Go to the source code of this file.
Data Structures | |
| struct | SPICC32XXDMA_HWAttrsV1 |
| SPICC32XXDMA Hardware attributes. More... | |
| struct | SPICC32XXDMA_Object |
| SPICC32XXDMA Object. More... | |
Macros | |
| #define | SPICC32XXDMA_PIN_05_CLK 0x0704 |
| #define | SPICC32XXDMA_PIN_06_MISO 0x0705 |
| #define | SPICC32XXDMA_PIN_07_MOSI 0x0706 |
| #define | SPICC32XXDMA_PIN_08_CS 0x0707 |
| #define | SPICC32XXDMA_PIN_45_CLK 0x072C |
| #define | SPICC32XXDMA_PIN_50_CS 0x0931 |
| #define | SPICC32XXDMA_PIN_52_MOSI 0x0833 |
| #define | SPICC32XXDMA_PIN_53_MISO 0x0734 |
| #define | SPICC32XXDMA_PIN_NO_CONFIG 0xFFFF |
| Indicates a pin is not to be configured by the SPICC32XXDMA driver. More... | |
Typedefs | |
| typedef struct SPICC32XXDMA_HWAttrsV1 | SPICC32XXDMA_HWAttrsV1 |
| SPICC32XXDMA Hardware attributes. More... | |
| typedef struct SPICC32XXDMA_Object | SPICC32XXDMA_Object |
| SPICC32XXDMA Object. More... | |
| typedef struct SPICC32XXDMA_Object * | SPICC32XXDMA_Handle |
Variables | |
| const SPI_FxnTable | SPICC32XXDMA_fxnTable |
| #define SPICC32XXDMA_PIN_05_CLK 0x0704 |
PIN 5 is used for SPI CLK
| #define SPICC32XXDMA_PIN_06_MISO 0x0705 |
PIN 6 is used for MISO
| #define SPICC32XXDMA_PIN_07_MOSI 0x0706 |
PIN 7 is used for MOSI
| #define SPICC32XXDMA_PIN_08_CS 0x0707 |
PIN 8 is used for CS
| #define SPICC32XXDMA_PIN_45_CLK 0x072C |
PIN 45 is used for SPI CLK
| #define SPICC32XXDMA_PIN_50_CS 0x0931 |
PIN 50 is used for CS
| #define SPICC32XXDMA_PIN_52_MOSI 0x0833 |
PIN 52 is used for MOSI
| #define SPICC32XXDMA_PIN_53_MISO 0x0734 |
PIN 53 is used for MISO
| #define SPICC32XXDMA_PIN_NO_CONFIG 0xFFFF |
Indicates a pin is not to be configured by the SPICC32XXDMA driver.
| typedef struct SPICC32XXDMA_HWAttrsV1 SPICC32XXDMA_HWAttrsV1 |
SPICC32XXDMA Hardware attributes.
These fields, with the exception of intPriority, are used by driverlib APIs and therefore must be populated by driverlib macro definitions. For CCWare these definitions are found in:
intPriority is the SPI peripheral's interrupt priority, as defined by the underlying OS. It is passed unmodified to the underlying OS's interrupt handler creation code, so you need to refer to the OS documentation for usage. For example, for SYS/BIOS applications, refer to the ti.sysbios.family.arm.m3.Hwi documentation for SYS/BIOS usage of interrupt priorities. If the driver uses the ti.dpl interface instead of making OS calls directly, then the HwiP port handles the interrupt priority in an OS specific way. In the case of the SYS/BIOS port, intPriority is passed unmodified to Hwi_create().
A sample structure is shown below:
| typedef struct SPICC32XXDMA_Object SPICC32XXDMA_Object |
SPICC32XXDMA Object.
The application must not access any member variables of this structure!
| typedef struct SPICC32XXDMA_Object * SPICC32XXDMA_Handle |
| const SPI_FxnTable SPICC32XXDMA_fxnTable |