An Introduction to the SPI Application Framework

The SPI bus has always been my favorite communication interface. It’s blindingly fast compared to other communication protocols like UART or IIC and doesn’t have a complex protocol involving addressing, NAKs or ACKs. SPI does use a single pin to perform slave device selection but if a system only has one or two SPI devices there isn’t much concern for the slave selects using up all the GPIO pins. Let’s take a look at how quickly a developer can get the SPI Application Framework up and running.

 

 

First, just like with every Renesas Synergy™ Application Framework, the SPI Application Framework needs to be added to the project using the SSP Configuration Window. SPI is located under the Framework > Connectivity thread stack option. Upon adding the SPI Application Framework, developers will easily notice (since all modules that require user configuration settings are highlighted in red) that they need to add a SPI Driver by clicking on the missing driver and selecting new. Just like with IIC, there are two different module options developers can choose from, the dedicated R_RSPI module or the multi-purpose R_SCI_SPI module that also supports SCI. From a software standpoint, the drivers are abstracted by the framework and the code to access SPI will be identical.

 

Once the driver selection has been made, the interrupt priorities need to be set for RXI, TXI, ERI and IDLE. If you have avidly read this blog, you may be experiencing some déjà vu at the moment. Don’t be alarmed! The reason is that the Renesas Synergy Application Frameworks follow a consistent pattern for setting up the different frameworks! Once a developer has setup one application framework, setting up others becomes a common process although some frameworks have options and thus require some additional configuration. After setting up the interrupts, the SPI thread stack should look something similar to the following:

 

 

Now any developer knows that at this point, SPI may be configured but the chances are any slave devices out on the bus aren’t going to respond to any messages. While the SPI interface is simple, setting the clock polarity, the clock phase, baud rate and signal delays are critical to successful communication. These parameters among others can be configured in the property tab after a developer clicks on the SPI Drivers stack. Perusing these properties will reveal that the slave select polarity and which pin the slave select is on is missing from the configuration!

 

How on Earth is a developer supposed to set these settings? Clicking on the SPI Framework stack and looking under the properties reveals that a developer can select the port, pin and slave select polarity at the framework level rather than the driver layer. This makes total sense! If there is more than a single SPI device on the bus, all one needs to do is add another SPI Framework Device, adjust the framework settings and a new configuration for the device will be generated. The fun part is that adding another framework automatically pulls in the previously set driver settings (which makes sense since the device is talked to with the same driver just a different pin is used to select it).

 

Once the devices are configured and the generate button has been pressed, a developer can roll up their sleeves and immediately start communicating to the slave devices. Communication is performed using open, write, read and close API calls. Developers can even use lock and unlock bus calls to allow other devices to use the bus.

 

Next week we will look at the advanced SPI capabilities available within Synergy which include the QSPI module. In the mean-time,

 

Live long and profit!

 

Professor_IoT

 

 

Hot Tip of the Week

 

Once you have your SPI Application Framework functioning you might need to do some debugging on other parts of your program. We have just posted a new Application Note on Debugging Your Application with IAR C-SPY that shows everything from basic debugging, to using advanced techniques like Timelines, Interrupt logging, ThreadX aware debugging and Stack Analysis to dig into the more challenging problems. The Application Note can be found here: https://www.renesas.com/en-us/doc/products/renesas-synergy/apn/r20an0418eu0100-synergy-iar-c-spy.pdf

 

 

Using C-SPY Timelines to Debug Challenging Problems