TMS320F28379D: Sending SPI data transmit and receive process to CPU2

Eric said:

I was wondering if I could do the SPI sensor transaction with CPU2 in parallel with my control code being executed on CPU1. I was wondering if I could use the IPC module to do this?

This should be doable. 

I am wondering however, if your SPI transfer is optimized. If not, would it make more sense to try and optimize that instead of dividing the SW between two CPUs? Some SPI optimization you could use: enable SPI FIFO to keep SPI bus as busy as possible, use DMA to transfer data to offload CPU.

Hello Gus

I am not using the SPI FIFOs currently. I wanted to ask: how would this reduce the amount of time each SPI transaction takes in my main ISR?

Could you also explain to me how I’d transfer data with the DMA? How would this work, and how would this help optimise my SPI transductions?

With the devices I am using, a serial clock of 4 MHz is the maximum clock frequency I can operate at. With this frequency, each full data transaction takes 12.6 microseconds on my oscilloscope.

I was wondering how your suggestions would serve to reduce this time in my ISR? 

Eric said:

I was wondering how your suggestions would serve to reduce this time in my ISR? 

In your software flow description, you mention:

Eric said:

ISR
---------------------------
* Read sensor data
* Read current
* Execute control algorithm 
* Acknowledge ISR, enabling further interrupts

From this I am assuming the sensor data read is blocking the next steps in your ISR. My thought is that if you can get the sensor data faster, that will allow you to complete the ISR faster. Let me know if my assumption is not correct. 

Eric said:

With the devices I am using, a serial clock of 4 MHz is the maximum clock frequency I can operate at. With this frequency, each full data transaction takes 12.6 microseconds on my oscilloscope.

What is the SPI bus load  you achieve in this case? In other words, 100% load means you can transfer 12.6us * 4Mhz = 50bits in 12.6us. If there is a lot of dead time in your SPI transfer, it may be due to the structure of your SPI routine. For example, if you write data to SPI, poll for data to finish transmitting, then write new data, you'll incur some CPU latency penalty. You could use FIFO and do something like write 8 characters in one shot to SPI FIFO, then wait for all characters to be transmitted. 

Hello Gus,

I am using two separate SPI modules for my data transactions. I've attached an image below of my serial clock waveform during the transaction. 

                                      

A full sensor transaction takes 12.4 us. A single SPI transaction takes 3.6 us. The time between transactions is 0.8 us. This process happens every ISR. 

I was wondering how the changes you mentioned would affect my SPI data transaction waveform? I don't think there is much dead time in my waveform is there?

Gus Martinez said:

From this I am assuming the sensor data read is blocking the next steps in your ISR. My thought is that if you can get the sensor data faster, that will allow you to complete the ISR faster. Let me know if my assumption is not correct. 

And yes, your assumption is correct.

Eric said:

I was wondering how the changes you mentioned would affect my SPI data transaction waveform? I don't think there is much dead time in my waveform is there?

You could eliminate the 0.8us dead time (assuming the slave device supports this), but you are right, it won't reduce the overall transfer time by more than 1.6us (0.8us x 2). Is a higher SPI clock speed an option?

Hello Gus, 

I did a look into my device data sheet and discovered that I can actually operate at an 8MHz SPI clock. For the time being, this allows for a 20 KHz ISR, however, I have very little room for adding more code to my ISR. 

I think I may have to go with either doing the SPI transaction on the second CPU, or if possible use concurrent processing with nested interrupts (if that is possible), though my feeling is that the right choice would be sending the SPI transaction to the second CPU.

What are your thoughts? 

Hi there Gus,

I was thinking of going for using the second CPU, would you have any advice on how I could set this up? It seems like I can't set up GPIOs on CPU2. Or do you suggest I open up a new question?