TMS320C6748: Issue in the timing

Harikrishnan R S

Part Number: TMS320C6748

Hi,

I am currently working with a peripheral device which is communicating with the DSP using SPI at a rate of 25 MHz (spiclkmax of the peripheral used) .I am currently writing five 8bit words from the DSP to peripheral which takes approximately 1.6 μs I am having some time bound applications which is required to be completed in 3.9 μs . I am also having some calculations which takes approximately 1 μs . I am currently using Timer 0 for achieving the timing requirement. There is an ISR in the program which sets a flag for the calculations and SPI operations in the main program. The Timer P0 out is also used in my application.

My issue is regarding timing . Even though the calculations and SPI communication is completed in 2.6 μs, There is some additional time taken inside which makes the total time for calculations above the required time (3.9 μs). The DSP is working at 456 MHz and the all the sections are stored in the SHDSPL2RAM. What are the possible solutions ?

Thank you in advance for any help you can provide.

over 5 years ago

0 Cvetolin Shulev-XID over 5 years ago

TI__Guru 65405 points

The team is notified. They will post their feedback directly here.

BR
Tsvetolin Shulev

0 RandyP over 5 years ago

TI__Guru* 84110 points

Harikrishnan,

You can search for "c6748 workshop" on TI.com (no quotes) to find our archived training for embedded DSPs and TI-RTOS. It will help you see all the hooks for doing realtime processing from input to output and how to optimize & pipeline the various stages of the applications.

It would help if you could draw out the different timelines showing their dependencies. The 3.9us seems to be independent of the other items, and you only mention outputs with no mention of inputs or if the outputs trigger the inputs, and so on.

The easiest thing to say to do is to use the Compiler's optimization to minimize your processing time, but that is not something with any hints from your description.

What triggers the ISR? Is that the Timer0's function?

Are you using TI-RTOS?

Regards,
RandyP

0 Harikrishnan R S over 5 years ago in reply to RandyP

Expert 1670 points

Thank You RandyP,

Thanks for the reply,

Yes, the ISR is triggered by the Timer0 . What is the delay that occurs during the ISR calling and returning ?

0 RandyP over 5 years ago in reply to Harikrishnan R S

TI__Guru* 84110 points

I do not know. Sorry, but that is not something I would know. My first thought is that any delay would be outside the key processing window but I can imagine that being wrong in terms of your specific application.

When you have a chance to explain the things I asked about, it may be easier for me to offer some system performance comments.

Regards,
RandyP

0 Norman Wong over 5 years ago

Guru 26430 points

A summary of your first post:

1.6us Write 5 bytes to SPI
1.0us Other calculations
1.3us Maximum allowable overhead
-----
3.9us Maximum poll period

SPI is 25Mhz or 0.04us/bit, 0.032us/byte, 1.6us/5bytes
Clock is 456Mhz or 0.002us. For 1.3us that would be 593 clocks.

593 cycles may seem like a lot but it depends on how you structured you code. A guess:

int do_calc;

interrupt timer_po_isr() // ??.?us to complete?
{
  if (do_calc ==1)
    too_slow();
  do_calc = 1;
}

main
{
  do_calc = 0;
  while(1)
  {
    if(do_calc)
    {
      blocking_spi_write_5_bytes(); // 1.6us
      calc();  // 1.0 us
      do_calc = 0;
    }
  }
}

Function calls take time to layup a stack frame. Before an Interrupt handler is called, registers are saved and probably a lot of dispatch code occurs. I doubt you can speed it up much further. Without the code, it is difficult to offer advice. Assuming the above pseudo code is correct, you could try to calc at the same time as the SPI send. Or use DMA to reduce the amount of code for polling/sending.

Processors

Processors forum

TMS320C6748: Issue in the timing