Do you have successful design experience on use PPI to simulate SPI? Could you please share related materials with me?
Thanks in advance.
I have never heard of anyone attempting to do this, as the PPI is not compatible with SPI protocol in a number of ways. For starters, it is not full-duplex, it does not support a gated clock, and its clock is input-only. However, it might be doable for slave mode SPI operation, and it might also work for master mode if we're clever about it...here are some loose guidelines:
1> The PPI has a minimum data length of 8 bits, so you will be losing pins that would otherwise function as GPIO. PPI_CLK would connect to SCK and you'd need to pick one or two (for full-duplex) PPI data pin(s) to serve as MOSI and/or MISO. For the sake of this hypothetical interface, let's say PPI0 is MOSI and PPI1 is MISO.
2> Your data buffers would have to be populated to spread the SPI data across as many words as you want your SPI serial length to be. For example, if your SPI data length is 24, you'd have to have the data spread across 24 bytes in the PPI buffer in Blackfin memory, with the SPI data being in the same bit location in each buffer. We would populate our buffer with the transmit data always in bit 0 (if we're the master) and bit 1 (if we're the slave). Similarly, we'd receive the data in the same structure and software would have to extract the data from the 24-byte buffer to assemble the 24-bit SPI serial data that we received.
3> To the point of PPI not being full-duplex, you might be able to support transfers in both directions, just not simultaneously. You'd have to disable the PPI, toggle the PORT_DIR bit to change direction, then re-enable the PPI.
4> To the point of PPI not supporting a gated clock, you'd have to dedicate a GPIO to serve as the SPI chip-select and handle enabling of the PPI in the GPIO ISR triggered by a high-to-low transition on that GPIO pin and disabling of the PPI in the GPIO ISR on a low-to-high transition. Of course, the master device would have to insert some sort of delay after the chip-select is driven low in order to allow for us to respond to this assertion and turn the PPI on, and you'd have to verify that the host SPI timing respects this need.
5> Specific to being the SPI master, you might be able to get away with using a GP Timer to generate the SPI clock, and connect the TMRx pin to both the Blackfin PPI_CLK and the other SPI device's SCK. You'd still have to dedicate a GPIO to handle the chip-select output connected to the SPI slave and set it low before enabling the timer, then drive it high again after the required number of clock pulses needed to support the desired SPI data length. Again, you'd need to consult the timing requirements for the other SPI device to make sure that you don't enable the timer too soon after driving the GPIO low.
These thoughts are just off the top of my head. Is this something that is often requested? We might be able to look into it further for possible application note consideration.
Retrieving data ...