• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 965 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.

PRU and GPIO

Fernando Gomes
Prodigy 50 points

Hello, from the documentation I see that PRU is only able to use R31 as inputs and R30 as outputs, I want to get clear if it is possible to have the PRU accessing the other GPIO ports. Also is it possible to have the PRU accessing the peripheral registers like the UART registers for example, when these UARTs are mapped on Linux? At least to access these registers in read only mode?

Best regards

Fernando

  • 0
    TI__Genius 15910 points

    Hi Fernando,

    The PRU is a system master peripheral and has access to most SoC resources.  As such, the PRU can access both the standard GPIO ports and UART registers (even when these peripherals are mapped on Linux).  For additional details, refer to Table 3-1 of the AM1808 TRM.  

    Also, please note that applications requiring real-time response should use the PRU GPI/Os, rather than the standard GPIOs.  

    Regards,
    Melissa

  • 0 in reply to melissaw
    Prodigy 50 points

    Hi Melissa

    Thanks for your reply! Can you clarify que problem of the realtime response using standard GPIOs versus the PRU GPIOs? Are there different timmings for accessing both or is there any other timming issues? I know that there might be some problems accessing the same registers from the ARM and the PRU processor, so for example on the standard GPIOs we should use bit set and get registers instead of read / modify / write the full registers, to avoid corruption by the simultaneous access from the PRU and ARM, is there any other precaution you recommend that we should take into account?

    Thanks

    Fernando

  • 0 in reply to Fernando Gomes
    TI__Genius 15910 points

    Hi Fernando,

    In general, there are additional delays when accessing MMRs outside of the PRU subsystem due to the SoC's switch fabric.  The dedicated PRU GPI/Os allow the PRU processor to detect and react to I/O event within two PRU cycles.

    Those are excellent points about accessing the same GPIO registers from the PRU and ARM.  Yes, if both processors will be accessing these registers, then it is best to use the bit set and get registers.  

    It is also good to take precautions against race conditions when both processors will be accessing a register.  If needed, there is a semaphore example in the DSP-based PRU support package or the Linux-based PRU example code.  Note the Linux-based examples are also available in the OMAPL138 and AM1808 SDKs.

    Regards,
    Melissa

  • 0 in reply to melissaw
    Prodigy 50 points

    Dear Melissa

    Thanks for your support! Is it possible to have more detailed information on the timing issues when using the standard GPIOs and other registers (like the UART registers) from the PRU subsystem? Are these timings deterministic? What I suppose that could happen is that the PRU sets for example a bit on one standard GPIO and proceeds execution, but the real update of the pin might happen a bit later, is this true? And if it is, this delay is deterministic?

    Thanks again!

    Fernando