Using MPLAB® Harmony v2 to Communicate with SPI

To use the Serial Peripheral Interface (SPI) in an MPLAB® Harmony application you will need to consider:

  1. The driver type to be used.
  2. The operating mode of the driver (polled or interrupt-driven).
  3. The protocol required to communicate with other SPI devices on the board.

Harmony provides two types of drivers: static and dynamic. Each of the SPI drivers can operate in either a Polled mode or an Interrupt mode. The selection of which driver to use, and what mode to operate in, is made when setting up the SPI device in the MPLAB Harmony Configurator (MHC).

When the project is generated, the MHC will configure the SPI settings according to the selected menu items.

spi-selection.png

Static vs. Dynamic Drivers

Both the static and the dynamic drivers provide the Application Programming Interfaces (APIs) needed to configure and communicate using an SPI. Both drivers support Standard mode, Framed mode, and Audio Protocol mode. Both drivers can support the enhanced SPI buffer found on some 32-bit MCUs.

The benefit most useful to application developers is the dynamic driver's ability to share the SPI peripheral among several tasks. This is useful when several different devices are attached to a single SPI channel and each of the applications tasks communicates with a different Slave device.

There are no inherent code efficiency or measurable execution speed benefits between the two driver implementations.

The dynamic driver is the most commonly used SPI driver implementation because it allows the application to seamlessly share a peripheral.

The dynamic SPI driver requires that, before communicating with a device connected to an SPI peripheral, the application must OPEN the SPI channel using a call to the function DRV_SPI_Open. This function returns a pointer to the driver (also called a handle) if the SPI channel is available. If the desired SPI channel is either uninitialized or in use by another task, NULL is returned by DRV_SPI_Open().

drv-spi-open.png

A valid handle, returned from DRV_SPI_Open, is a required parameter for all SPI communication functions using a dynamic driver.

drv-spi-bufferaddwrite.png

An application does not have to CLOSE an SPI channel after each communication exchange. The channel can be kept open for an extended period.

Example: Configuring and Using SPI dynamic drivers

Interrupt vs. Polled mode

Moving data between an application's transmit/receive buffers and the SPI peripheral's hardware registers require the Harmony function DRV_SPI_Tasks to be called. DRV_SPI_Tasks calls, through a function pointer, the specific routine to transfer the data. The determination of which function DRV_SPI_Tasks uses as a callback function, is determined by the configuration entered into the MHC. The use of different callback functions by DRV_SPI_Tasks has no effect on the application API calls or usage.

The application developer is responsible for choosing whether DRV_SPI_Tasks is called as an Interrupt Service Routine (ISR) or if DRV_SPI_Tasks is to be called on each iteration of the main while(1) loop. To have DRV_SPI_Tasks triggered by an interrupt, check the box Use Interrupt Mode in the MHC. To have Harmony place a call to DRV_SPI_Tasks from SYS_Tasks, check the box Use Polled Mode.

Once you have selected which mode to use, MHC will modify the Harmony source files needed for proper mode implementation.

Interrupt Mode Implementation

spi-interrupt.png

Example: Configuring and Using SPI in Interrupt Mode


Poling Mode Implementation

spi-polled.png


Device Protocol

SPI uses 4-wires to communicate between a Slave device and the SPI Master. SPI Slave devices expect, and respond to, certain sequences of simultaneous signals (i.e., protocol) on the SPI lines. Due to the variety of protocols among SPI devices, Harmony does not attempt to implement any specific protocol. The Harmony SPI drivers will ensure the data packets are accurately delivered. It is the programmer's responsibility to ensure the content and sequence of the packets sent are appropriate.

spi-protocol-example.png

Example: Reading a serial EEPROM

The above picture shows the protocol for reading a byte of data from the 25LC256 Serial EEPROM. To successfully read the EEPROM user's application code for a Master SPI, the device must provide for the following sequence of events:

  1. Assert the CS signal.
  2. Send out the read command (03) with eight clock signals.
  3. Send out the 16-bit address to read with 16 clock signals.
  4. Receive the 8-bit response by sending out eight 'don't care' with eight clock signals.
  5. De-assert the CS signal.

 Learn More

 
Entire SPI Driver Interface
Learn more >
© 2019 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.