• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 291 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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:

AM2634: PRU interrupt management

PROCESSOR-SDK-AM64X: SKAM64 -A

shruti gupta
Intellectual 2150 points
Part Number: PROCESSOR-SDK-AM64X

Is it possible to use a GPI pin in PRU core as an interrupt , like we can do in R5F core?  I want to use a specific GPI pin as an interrupt and want to read some data on both its rising and falling edge.

  • +1
    TI__Guru 72835 points

    Hello Shruti,

    PRU-ICSS devices & polling for GPI interrupts

    For PRU-ICSS and PRUSS devices, the discussion you linked in the "original question" has most of the information you would be looking for. There is one additional important piece of information that I did not see in that thread: in PRU-ICSS and PRUSS, the PRU cores cannot be preempted. That means that when one of those interrupts comes in, it will cause a bit to change in the interrupt register. However, the PRU program will not get interrupted, and the PRU program will not know that an interrupt has arrived until it polls the interrupt register to see if any interrupts have come in.

    The PRUs in these devices are absolutely able to drive interfaces without preemption - the PRUs are just programmed to be waiting for an input signal at the time that an input signal is expected. e.g., AM335x software UART https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/08_02_00_24/exports/docs/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/pru-sw-uart.html , multi-ADC SPI connections https://www.ti.com/tool/TIDA-01555 , etc.

    PRU_ICSSG devices add preemption

    PRU_ICSSG devices (AM64x, AM24x, AM65x) add in the Task Manager, which CAN preempt executing code. If you look at the "PRU_ICSSG Local INTC" section of the AM64x Technical Reference Manual (TRM), you will see that some interrupts can be mapped to the Task Manager, and the Task Manager can then interrupt the associated PRU core so the core can perform a higher priority task as soon as the interrupt occurs.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Intellectual 2150 points

    Hey Nick

    Thanks for the response, so if the PRU is doing only one task for example just reading and storing the data, then it's better to poll that specific bit in R31 on which we want to do the needful instead of using the task manager or is there any other advantages of going with the task manager except for timing? 

  • 0 in reply to shruti gupta
    TI__Guru 72835 points

    Hello Shruti,

    [NOTE: Added after I went back and double-checked the AM64x TRM, PRU GPO pins are not listed in INTC inputs 0-63, and I was not able to find INTC inputs 64-159. I am asking the hardware folks for more info, but there may not be a good connection for the Task Manager to be interrupted by a GPI pin]

    "better" is a tricky word. In general, if you don't need the task manager, I suggest not using it. More information:

    Input latency & read/write latency

    Let's define "input latency" as the time between when the signal arrives at the processor pin, and the time that the PRU core knows that the signal has arrived. "read/write" latency is the time between when an input signal arrives at the processor pin, and the PRU knows the signal has arrived, writes an output signal, and the output signal arrives at a different processor pin. So input latency will always be less than read/write latency.

    If the PRU firmware is polling the GPI pin, that will provide the fastest input latency and read/write latency. Here is the read/write latency I measured a while ago on TI EVMs:
    AM64x 333MHz PRU clock: 6 PRU clocks for read/write (~26 ns)
    AM335x 200MHz PRU clock: 7 PRU clocks for read/write (~35 ns)

    You can consider these measurements "worst case" - I think I actually measured AM335x with just 6 clock cycles of read/write latency a couple years earlier, so it is possible that shorter trace lengths between my measurement point and the processor pin would show the true read/write latency to be slightly less.

    If you are routing the GPI signal to an interrupt to the task manager, it will take slightly more time. The task swap itself has a 1 clock latency, so it will take 1-2 extra clock cycles for the task manager to interrupt the PRU cores and switch context.

    Code design 

    The task manager was added to enable very complex gigabit Ethernet protocols. So it is a useful tool, but it adds software complexity. Often the task manager is not needed for designs.

    AM64x PRU developers will often dedicate one PRU core to reading and writing GPI/GPO pins (we call this "bitbanging"). Then they use the other RTU and TX_PRU cores to do all the other work (copying data around, doing data processing, interfacing with the rest of the processor, etc). If the single PRU core cannot handle all the GPI/GPO work, it may make sense to spread the bitbanging load across both PRU cores in a PRU_ICSSG.

    Another thing to keep in mind is determinism. One benefit of not using the task manager if you don't need it, is that you know your code is 100% deterministic! Since the code will never be interrupted, you can know exactly what assembly instruction is running on the PRU core at every single clock cycle, and you can guarantee that your interface timing is always met. Code that uses the task master can still be deterministic, but it becomes a lot more complex to investigate all the edge cases and make sure you always meet timing.

    Regards,

    Nick