• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 121 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.

AM2434: AM64x: timing issues PRU with General-Purpose Interface GPIO

Niklas Haase
Prodigy 40 points
Part Number: AM2434

Tool/software:

Hello 

I am currently using the PRU in SD Mode. To use GPIOs, I have to rely on the General-Purpose Interface (GPIO). My issue is that the timing of these external peripherals is less precise and shows some unusual behavior.

The test program is quite simple and generates a PWM signal. Pin multiplexing is handled by an R5F program, following the configuration described in the corresponding FAQ article, using the same settings.

    LDI     R1.w2, 0x60
    LDI     R1.w0, 0x1000   ;GPIO1 Baseaddress (0x601000)
    LDI     R2.w0, 0x18     ;GPIO_SET_DATA01 offset
    LDI     R3.w0, 0x1C     ;GPIO_CLR_DATA01 offset
    LDI     R4.w0, 0x01     ;bit 1 -> output 0

CHECK_PROCESSING_TIMING:
    SBBO    &R4, R1, R2, 4  ;set General-Purpose Interfaces connected Pin High
    SET     R30, R30, 1     ;set PRU connected Pin 1 High
    NOP
    NOP
    NOP
    NOP
    NOP
    NOP
    NOP
    NOP
    NOP
    SBBO    &R4, R1, R3, 4  ;set General-Purpose Interfaces connected Pin Low
    CLR     R30, R30, 1     ;set PRU connected Pin 1 Low
    NOP
    NOP
    NOP
    NOP
    NOP
    NOP
    NOP
    NOP
    JMP     CHECK_PROCESSING_TIMING
    HALT

When the timing is correct, as demonstrated in the example code, the signal from the General-Purpose Interface shows a delay of approximately 27ns plus one clock cycle (3.3ns) with acceptable jitter. However, if I remove just one operation from the loop and the period no longer aligns with some internal timing of the SoC, I observe significant jitter in the General-Purpose Interface output. The standard deviation is 2.24ns, and the delay can vary between 26.3 and 34.4ns plus one clock cycle (3.3ns).

Is there a way to achieve always the better timing performance when using the PRU with the General-Purpose Interface?

Regards

Niklas

  • 0
    TI__Guru** 100980 points

    Hello Niklas,

    Pin accesses: PRU GPI / PRU GPO vs "regular" GPIO

    A big reason why we have PRU cores on this device is that the PRU GPI / PRU GPO signals have a completely deterministic latency from inside the PRU core, to the processor pin (and from the pin to the processor). In general, if you care about nanosecond precision, these are the signals that you should be using.

    Accesses outside of the PRU subsystem are not going to be fully deterministic for multiple reasons. I have not benchmarked this specifically, but I would not be surprised if there was some nanosecond jitter for accesses to the system GPIO modules. You will also probably find that average latency to access GPIO0 is slightly different than the latency to access GPIO1, one of the SPI interfaces, etc.

    You can find more information here:
    [FAQ] What is a PRU core? Why are PRU GPIO signals different from regular GPIOs?

    And then some more information about read and write latency can be found here:
    [FAQ] PRU: How do I calculate read and write latencies? 

    FYI, I am going to add some comments to your code block to make it a bit easier for future readers to interpret

  • +1
    TI__Guru** 100980 points

    FYI: PRU Academy and OpenPRU are coming! 

    This year, we are working on 2 projects: PRU Academy, and OpenPRU.

    PRU Academy will be a module within the processors academy for:
    AM243x ||  AM26x ||  AM62x ||  AM64x

    My goal is to provide comprehensive documentation for how to get started with PRU development, covering hardware topics, RTOS & Linux programming, firmware development, etc. If you want an idea of the kind of scope I am working towards, take a glance at the AM64x multicore academy, which I also wrote.

    (by the way, if you are developing for AM64x, multicore academy is a really great resource. People usually start with section "Application development on Remote Cores")

    Send me a direct message if you want to be notified when the first draft of PRU academy goes live, tentatively within about a month. 

    This kind of documentation takes literal years to write. So I focus my time on writing pages that address challenges that people are currently running into. That means the questions you ask on e2e have a direct impact on the next page that gets written!

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 40 points

    Thank you for this information. It is good to know, and I am looking forward to learning from this documentation. The lack of beginner-friendly tutorials has been a significant drawback, especially since most existing tutorials are based on the AM335x and do not reflect the current standards, particularly with the new IDE.