• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 97 subscribers
  • Views 452 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM1707 EMDA3 Latencies?

Collin Hockey
Prodigy 40 points

For our application, we need to be able to read data coming in on GPIO pins at a fairly fast rate (around 25Mhz) and push it to SDRAM. Faster would be ideal. We have the data lines attached to GPIO banks 0 and 1, and a data ready signal attached to another GPIO pin.

We were thinking the EMDA3 peripheral might be able to handle the speeds, but I'm concerned about latencies. The idea would be to have an EDMA event triggered by the data ready signal read from the 32 bit GPIO register and put the data into SDRAM.

Is this a reasonable approach? Is there a document somewhere I can reference that would provide more information about the speeds of the EDMA peripheral? I've found SPRAAG8, but that is mainly aimed a the C64x+ devices.

In the future, we'd like to take at least a few of these bits and push them to USB. Can the EDMA peripheral directly write to the USB interface?

Thanks!

  • 0
    TI__Genius 14545 points

    Collin,

    Collin Hockey said:
    Is this a reasonable approach? Is there a document somewhere I can reference that would provide more information about the speeds of the EDMA peripheral? I've found SPRAAG8, but that is mainly aimed a the C64x+ devices.

        The EDMA3 shouldn't have an issue with this approach. The latency isn't going to be a function of the EMDA3 throughput, rather the latency of the entire system, including GPIO module, EDMA3, switch fabric, memory access etc. For an overview of the switch fabric, you can refer to this wiki page. The clocks to the EDMA3 can be configured to run at a rate much faster than 25MHz.

     

    Collin Hockey said:
    Can the EDMA peripheral directly write to the USB interface?

       The USB has it's own DMA as well. Worse case scenario can use a Transfer Completion Event from the EDMA3 to trigger a USB DMA Transfer.

     

     

  • 0 in reply to dabuan
    Prodigy 40 points

    Drew, Thanks for the information. However, I think I've figured out that the EDMA cannot respond fast enough.

    The GPIO bank 2 event triggers the 4 byte transfer just fine, but at the end of the transfer, the event missed flag is high and there looks to be samples missing. (The ADC is in a test mode with predictable output).

  • 0 in reply to Collin Hockey
    TI__Genius 14545 points

    Collin,

     

    Good stuff.

    Do you have any other events that would are queue'd up preventing the ADC event submission from being submitted to the Transfer Controller ASAP?

    Event misses will be registered when an additional events are generated by the GPIO module but the previous event is still in the queue or has not been submitted to the Transfer Controller.

  • 0 in reply to dabuan
    Prodigy 40 points

    There should not be any other events, this is the only function the EDMA is performing. In fact, it's the only thing the entire chip is doing at this point.

  • 0 in reply to Collin Hockey
    TI__Genius 14545 points

    Collin,

    Are you using an the EDMA3 Low Level Drivers on top of DSP/BIOS, or are you programming the EDMA3 at the register level?

  • 0 in reply to dabuan
    Prodigy 40 points

    Programming it at the register level. The processor is running all custom C code.

  • 0 in reply to Collin Hockey
    TI__Genius 14545 points

    Collin,

    Spoke internally to get latency data since I was surprised by your results. I takes 33 CPU (SYSCLK1) cycles from event generation latch to transfer controller submission complete, which assuming a 300MHz SYCLK1 clock frequency equates to ~ every 110nS if I did my math right. So for an transfer that is generated by the same event source , this equates to ~9.09 MHz before you'll start to see missed events from the same source. This will scale accordingly with SYSCLK1 frequency.