CCS/TMS320F28377D: stable SPI regardless fixed CPU interrupts

Mark,
thank you for your support.

Well, data is being sent bidirectional. Both master ans slave receive wrong data sometimes, but some other time everything goes right. I didn't use oscilloscope for additional checking.
But, as you mentioned: 'If you are constantly interrupting the CPU and spending all of the time in an ISR, you may not ever reach the main loop', which means that this way having SPI in the main loop together with ISR timer is not good, do you agree? I need a way of stable SPI where it would never come in such situation. Also, I need to have fixed-interval ISR timer0 for some motor control tasks, reading sensors...
The following code is SPI between master and slave sending 32bit floats as two parts of 16bits (because SPI buffers are 16bit) :

SLAVE:

    for(;;)
    {

    // SPI begin, Transmit data 32 bit float over SPI which has 16 bit shift register
             union mytypeSend data_sent;
             union mytypeReceive data_reci;

             data_sent.fl=s; //send float number - encoder reading

             // Transmit data first 16 bits of 32 bit float number
             spi_xmit(data_sent.ui[0]);
             // Wait until data is received
             while(SpiaRegs.SPIFFRX.bit.RXFFST !=1) { } // 1 word = 16 bits
             // Check against sent data
             rdata1 = SpiaRegs.SPIRXBUF;
             data_reci.ui[0]=rdata1;

             // Transmit data second 16 bits of 32 bit float number
             spi_xmit(data_sent.ui[1]);
             // Wait until data is received
             while(SpiaRegs.SPIFFRX.bit.RXFFST !=1) { } // 1 word = 16 bits
             // Check against sent data
             rdata2 = SpiaRegs.SPIRXBUF;
             data_reci.ui[1]=rdata2;
             aM=data_reci.fl; //32 bit float contained from two 16 bits parts
             SpiaRegs.SPIFFTX.bit.TXFFINTCLR=1;  // Clear Interrupt flag
             SpiaRegs.SPIFFRX.bit.RXFFOVFCLR=1;  // Clear Overflow flag
             SpiaRegs.SPIFFRX.bit.RXFFINTCLR=1;  // Clear Interrupt flag

    // SPI end

    }

MASTER:

for(;;)
    {
    // SPI begin, Transmit data 32 bit float over SPI which has 16 bit shift register
             union mytypeSend data_sent;
             union mytypeReceive data_reci;

             data_sent.fl=1111.12345+bM; //some increasing float

             // Transmit data first 16 bits of 32 bit float number
             spi_xmit(data_sent.ui[0]);
             // Wait until data is received
             while(SpiaRegs.SPIFFRX.bit.RXFFST !=1) { } // 1 word = 16 bits
             // Check against sent data
             rdata1 = SpiaRegs.SPIRXBUF;
             data_reci.ui[0]=rdata1;

             // Transmit data second 16 bits of 32 bit float number
             spi_xmit(data_sent.ui[1]);
             // Wait until data is received
             while(SpiaRegs.SPIFFRX.bit.RXFFST !=1) { } // 1 word = 16 bits
             // Check against sent data
             rdata2 = SpiaRegs.SPIRXBUF;

             data_reci.ui[1]=rdata2;
             aM=data_reci.fl; //32 bit float contained from two 16 bits parts
             bM=bM+0.001;

             SpiaRegs.SPIFFTX.bit.TXFFINTCLR=1;  // Clear Interrupt flag
             SpiaRegs.SPIFFRX.bit.RXFFOVFCLR=1;  // Clear Overflow flag
             SpiaRegs.SPIFFRX.bit.RXFFINTCLR=1;  // Clear Interrupt flag

    // SPI end
    }

Is there some other way of getting stable SPI together with CPU fixed ISR timer0?
Is it a good idea to have SPI inside the ISR timer0 interrupt on both master and slave, not in the main loop?

Thank you again,
Tihomir

Tihomir,

Have you been able to resolve your issues?

Tihomir Zilic said:

which means that this way having SPI in the main loop together with ISR timer is not good, do you agree?

I partially agree with your statement. It really depends on how your control loop is structured, and if you can ever make it into the main loop. You need to design your system so that you can capture measurements, compute tasks, and then act on them predictably in every cycle of your control loop. If your control loop tasks do not leave enough time to manage your housekeeping tasks, (comms, data logging, etc), you will need to optimize your system somewhere. Either by slowing down you loop time, or optimizing your control loop time. 

It looks like you are using the SPI in a very manual, hands-on way that requires a lot of CPU interaction. If you enable the FIFO, you can write the two 16-bit words to the SPI and wait until the SPI has received both before interacting with the data. This will free up the CPU to do other things.This could cut some time out of the SPI loops. 

Tihomir,

Sorry for the long delay. Have you been able to resolve your question? The simple answer is that the shared RAM is just a big dumb memory. You can use it how you see fit. If CPU1 stores a value in the RAM space and it is in a float32 format, CPU2 should be programmed to know that it is going to be picking up a float32 when it reads the shared RAM. There is no hardware that enforces any structure. Said in another way, if CPU1 programs a float32 value in your shared RAM, CPU2 could read it as two int16 values, which probably would not work.  In essence, CPU2 will interpret the data in the RAM however you tell it to interpret the data. The key is that your program should know where to pull data from and how to interpret it, even in a single core, simple system.

Glad to hear that you resolved your questions. Please create a new post in the future if you have any additional questions.