The SPI Framework module provides a set of ThreadX-aware framework APIs and handles the integration and synchronization of multiple SPI peripherals on an SPI bus, including chip-select handling and its level activation. With the SPI Framework, one or more SPI buses can be created and multiple SPI peripherals can be connected to the SPI bus. The SPI Framework module uses a single interface to access both SCI SPI and RSPI drivers. The SPI Framework module uses the SCI and RSPI peripherals on the Synergy MCU.
The SPI Framework supports the following features:
- Supports multiple devices on a bus
- Provides high-level APIs for initialization, transfers, and closing the module
- Supports synchronized transfers
- Supports chip-select operations
- Supports bus-locking
The SPI Framework module guide is targeted for SSP 1.2.0 and the SK-S7G2 Kit.
The most recent versions of the SPI Framework module guide application note, application project and import guide are available here
Module Guide Errata
Section 3: Module Operational Overview, Edits to text
The SPI Framework module complies with the layered-driver architecture of the SSP. It uses either the SCI on SPI module or the RSPI module to communicate with the SPI peripherals on the Synergy microcontroller.
The framework-driver architecture uses a “bus” and “device on bus” architecture. Only one device is configured to the lower level at a time, and remaining devices are reconfigured upon read or write operation if required. The Device can be reconfigured only when the bus is not locked. Every device is linked to the bus to which it will be connected. The user must configure the bus, the framework, and the lower-level module for each device connecting to the bus. The user can add the existing framework shared-bus when configuring multiple devices on the same bus. Each SPI framework must be configured with a unique name in the ISDE configurator.
A common start and stop procedure is used for all SPI data-transfer operations (read, write and writeRead). During the start process, the Framework module checks whether reconfiguration is required. Chip select is asserted during the transfer-start process and de-asserted during the transfer-end process if bus is not locked. The user must configure the chip-select IO pin and chip-select active level.
The SPI Framework module supports the bus-locking functionality, meaning that the user can lock the bus for a given peripheral. The locking allows devices to reserve a bus to themselves for a given period of time (between lock and unlock.) This allows devices to complete several reads and writes on the bus without any intervention from other devices on the same bus, which is required in some instances. The chip select becomes active during lock and becomes inactive when unlocked. Writes and reads in between the lock and unlock do not alter the chip-select line.
Section 3.1.1: Module Operation Notes Edit to second bullet pointed item
- Multiple SPI devices can be configured to share a common bus. Once the SPI Framework bus module is configured, different SPI peripherals (devices) can be connected to that bus.
- For each SPI device connected to the bus, one SPI HAL module (new or shared) and one SPI Framework device module must be added.
- User-defined callback is not required as it has been internally taken care of by the framework.
- Setting the interrupts to different priority levels could result in improper operation.
Module Guide Resources
The SPI Framework module is used in the following application projects:
- Bluetooth Low Energy on DK-S7G2 and DK-S3A7 - Application Project here.
- Renesas Bluetooth MCU (RL78/G1D) - Application Project here.
The SPI Framework module is used in the Communication Developer Examples available for the SK-S7G2. You can find a Knowledge Base article that describes the Developer Examples and how to use them here.
- Refer to the most recent release notes for known issues, available here.