• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 261 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.

Original question:

AM6442: PRU to R5F Host Interrupt Performace

AM6442: PRU to R5F Host Interrupt Performace

Francesco Rolando
Prodigy 30 points
Part Number: AM6442

Tool/software:

My thread is locked without an answer, so I need to open a new one.

Please refer to the original thread for the issue's details.

Thanks.

  • 0
    Prodigy 30 points

    Tushar Thakur, would it be possible for you to reassign an expert to this issue, or should I conclude that it's unsolvable?

    Many thanks

  • 0 in reply to Francesco Rolando
    TI__Mastermind 48868 points

    Hi Francesco,

    From the above link, I can see there are three questions pending.

    1. How much is the typical api/soc delay introduced by GPIO_pinWriteHigh?

    2. How much is the latency of VIM / HwiP_* api?

    3. What interrupt handling resources are shared between R5 cores?

    Please confirm the above for better assistance.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 30 points

    Yes, plus,

    4. Can I implement any configuration to have a more deterministic delay?

    Thanks!

  • 0 in reply to Francesco Rolando
    Mastermind 7450 points

    Hello Franceso,

    one information I couldn't find in your other post is where your code is executing from. Did you try putting all of your R5f code into TCM?

    If your code is located in MSRAM or even worse in DDR memory there are rather huge latencies when code isn't available in the L1 cache, and that cache is rather small and from my experience often misses. Of course this depends on the whole code executing on that R5f core at the time.

    If you manage to put all of your code into TCM you eliminate that factor.

    On a scale of a few hundred ns that could be relevant.

    Please note that I'm not TI, and they may have other advice for you.

    Regards,

    Dominic

  • 0 in reply to Dominic Rath
    Prodigy 30 points

    Ciao Dominic,

    thanks for the hints, unfortunately the code is already executed from TCMA and TCMB the data/memory segments are on MSRAM in other to be shared with PRU.

    Francesco.

  • +1 in reply to Tushar Thakur
    TI__Mastermind 48868 points

    Hi Francesco,

    Thanks for your patience.

    Tushar Thakur said:
    1. How much is the typical api/soc delay introduced by GPIO_pinWriteHigh?

    The average cycle taken to make GPIO pin high is ~160 cycles from R5F running at 800 MHz.

    Tushar Thakur said:
    2. How much is the latency of VIM / HwiP_* api?

    The average time taken to call the user callback function once the ISR is generated is ~365 cycles from R5F running at 800 MHz.

    All the above results are taken from release build of the provided project.

    Please refer below project.

    Project - interrupt_latency_am64x-evm_r5fss0-0_nortos_ti-arm-clang.zip

    Tushar Thakur said:
    3. What interrupt handling resources are shared between R5 cores?

    Please refer section 6.2.3.1 R5FSS Block Diagram of device TRM for this information.

    Francesco Rolando said:
    Can I implement any configuration to have a more deterministic delay?

    You can use the above program to calculate benchmarking number and have more deterministic way of getting interrupts.

    Regards,

    Tushar