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

The Driver Type being to be used.

The operating Mode of the driver (polled or interrupt driven).

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 MPLAB® Harmony Configurator (MHC)

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

Static vs. Dynamic Drivers

Both the Static and the Dynamic drivers provide the APIs needed to configure and communicate using 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 communication 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 your 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().

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

​

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

Interrupt vs Polled mode

Moving data between an application's transmit/receive buffers and the SPI peripheral's hardware registers requires 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 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 or if DRV_SPI_Tasks is to be called on each iteration of the main "while(1)" loop. To have DRV_SPI_Tasks trigger by an interrupt the user checks the box "Use Interrupt Mode" in MHC. To have Harmony place a call to DRV_SPI_Tasks from SYS_Tasks the user will check the box "Use Polled Mode".

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

Interrupt Mode Implementation

Poling Mode Implementation

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.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 the user's application code for a master SPI, the device must provide for the following sequence of events:

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.

Click here to edit contents of this page.

Click here to toggle editing of individual sections of the page (if possible). Watch headings for an "edit" link when available.

Append content without editing the whole page source.

Check out how this page has evolved in the past.

If you want to discuss contents of this page - this is the easiest way to do it.

View and manage file attachments for this page.

A few useful tools to manage this Site.

See pages that link to and include this page.

Change the name (also URL address, possibly the category) of the page.