This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320C6748: GPIO latency

Guru 10750 points
Part Number: TMS320C6748

Hi,

I want to emulate SPI interface by using the C6748 GPIO, the C6748 is running at 400MHz. I see that each time I change the GPIO value it takes about 70 clock cycles, Is there a way to reduce it?
Many Thanks,
HRi
  • Hi,

    Not sure if this is possible.

    However I'm looping the design team to confirm/correct my understanding.

    Best Regards,
    Yordan
  • 70 clock cycles is not unrealistic for the C6748 to work the GPIO. At least it is in the ballpark of taking lots of cycles to do it. The DSP is designed to do math really well and makes system tradeoffs that allow a strong reliable design to work with a wide variety of internal peripherals on the internal buses.

    How are you measuring the 70 clock cycles? From what measurable start to what measurable end? It is extremely difficult to get an accurate measurement from a DSP instruction execution to an external pin change because of the delays between the two, going both ways.

    How fast do you need the GPIOs to run? Do you need to be going both directions simultaneously, plus generate a clock and select line?

    The C6748 has two SPI ports with multiple chip selects already on the part. If you need a third or fourth SPI port, how much processing capability are you willing to give up for bit-banging the SPI pins?

    Regards,
    RandyP

  • Hi Randy,

    We are toggling the GPIO in a loop and measuring it, currently we are aroung 2MHz, and we want to get to 10MHz,

    We are aready using the other SPI ports, and we need additional one,

    Thanks,
    Haim
  • Haim,

    I doubt you can get to 10MHz with anything short of pure and tight assembly code, which would mean the DSP is only toggling pins and not doing any other processing.

    Show me the source code for your loop and the Disassembly Window for that code in CCS showing the assembly generated for the loop.

    The main thing you have to avoid is read-modify-write instructions since those cause a lot more bus activity than simple write instructions. It depends on how you wrote the code and how you compiled it and what the compiler did with it.

    Regards,
    RandyP
  • A bit late to the party. The GPIO controller is known to have significant delays. Others have tried to toggle GPIOs as fast as possible. Some threads listed below. Highest speed noted was 12.5 MHz. But that was with a tight loop (as Randy noted). ISR based code would be even slower.

    e2e.ti.com/.../228345.aspx
    e2e.ti.com/.../127628.aspx
    e2e.ti.com/.../135631.aspx
    e2e.ti.com/.../240772.aspx
    e2e.ti.com/.../252738.aspx