PRU Communications: Beaglebone Black

[Venkatesh Vadde]

We are a group working with a Beaglebone and trying to get more time determinism between the PRUs. We are trying to get one PRU to respond to a trigger from the other PRU. The INTC framework seems quite complex, and we are finding it quite difficult to decipher or understand (but an example might help us build on it). Does the PRU allow for a timed response like an interrupt based mechanism? Can someone suggest something for our requirement of communication between the PRUs?   

Thank you,

-Vadde

[Paul Beam]

The PRUs do not support a traditional interrupt mechanism where code flow is diverted due to an event.  You must poll a flag to determine if the interrupt has occurred.  The PRUs latency in response will be dependent upon how often you poll.  I suggest you keep your main loop short and use state machines for all operations so that a poll is not delayed by a long function.  

 

You may need to add an additional processor if you need traditional interrupt operation.

[Venkatesh Vadde]

Thank you for the suggestion. We will explore this option. Do you think the shared memory between PRUs is a natural choice of location to consider placing such a mailbox at?

 

On Tue, Jul 2, 2019 at 6:31 PM Paul Beam <rpau...@gmail.com> wrote:

The PRUs do not support a traditional interrupt mechanism where code flow is diverted due to an event.  You must poll a flag to determine if the interrupt has occurred.  The PRUs latency in response will be dependent upon how often you poll.  I suggest you keep your main loop short and use state machines for all operations so that a poll is not delayed by a long function.  

 

You may need to add an additional processor if you need traditional interrupt operation.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/db23f6aa-17b9-4fb7-9d38-7ff47f5205e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Beam]

This is from the TI FAQ on the PRU:

Does the PRU-ICSS/ PRU_ICSSG Support Interrupts?

Yes,but not in the same way that most cores support interrupts.The PRU-ICSS/ PRU_ICSSG contains an interrupt controller that can map 64 system events down to two flags that are set in a PRU core register (bits 30 and 31 in core register R31).The PRU core can then check each of these flags in a single cycle to see if an event has occurred.These flags can either be polled upon or checked periodically (dependent on what makes the most sense for the use case).The PRU-ICSS/ PRU_ICSSG interrupt controller does not support jumping the program counter of the PRU core to a pre-determined function when an event occurs.

The other PRU can be one of these 64 events that sets a bit.  Whether it makes more sense to use the bits in R31 or shared memory will depend upon your application.  Shared memory would allow you to queue up more data than just a single bit, but a larger message could take more time to process.  This is a design decision you will have to make.

[TJF]

AFAIK only the uio_pruss driver supports interrupts. But that doesn't make sense. Polling a certain memory adress is more effective.

Use any memory area with direct (no OCP latency) PRU access: DRAM-[0|1] or SRAM

But note, there're acces rules: when one PRU allways polls a memory address, the other may not be able to change the value.

Regards

[Venkatesh Vadde]

Thank you, Paul. We will try using the PRU core register and see what performance we can get. The shared memory option sounds less useful, but we might try it just to find out how limited it is. The upside of the shared memory is the relative ease of use, but that is not good enough if it leads to memory contention issues. 

Regards.

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5a29e2b2-dbb8-4819-b65b-8899c3a17324%40googlegroups.com.

[Venkatesh Vadde]

Thanks, TJF. Any PRU documentation on the access rules and how to avoid a memory contention? 

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/21227461-819f-4033-9ecb-0c4a0f65dbae%40googlegroups.com.

[TJF]

Am Dienstag, 2. Juli 2019 19:23:19 UTC+2 schrieb Venkatesh Vadde:

Thanks, TJF. Any PRU documentation on the access rules and how to avoid a memory contention? 

Find details in

https://elinux.org/images/d/da/Am335xPruReferenceGuide.pdf

In the DRAM each PRU has prefered access to its own area (chapter 3.1.2). So the DRAM of the triggering PRU may be a better choise for the shared memory.

Regards

[Venkatesh Vadde]

Thanks much. We are going to use this as a standby and try using the PRU core register flag setting as a default option. 

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/af42fc7c-abe3-4f49-b5f2-f71e5420eefc%40googlegroups.com.

[TJF]

Yes, that's a further option. You can HALT one PRU and restart it by setting bit 1 (ENABLE) in the CONTROL register, using the other PRU.

But note, you also have to increase the STATUS register, in order to jump over the HALT statement.

Regards

[Charles Steinkuehler]

As has been discussed, the PRUs have no direct "interrupt" like
functionality that interrupts and redirects program execution.

In addition to the various methods already discussed, if you are
trying to tightly couple program execution between the two PRU cores,
I suggest using the transfer instructions (XIN/XOUT). While these
instructions are typically used to access the scratchpad and hardware
multiplier, you can also specify a direct connection between the two
PRU cores. In this case, one PRU core executes an XIN instruction and
the other core executes an XOUT. The core that executes the
instruction first will stall until the other PRU executes it's
transfer instruction, at which point the two PRU cores will continue
executing code, synchronized by the transfer instruction. The
transfer is terminated if either PRU core stalls for more than 1024
cycles.

Details are in the TRM, but you have to have one of the versions with
full details on the PRU cores (eg: spruh73c or similar).

--
Charles Steinkuehler
cha...@steinkuehler.net

[Venkatesh Vadde]

Sounds a tad more intricate, but seems powerful. Thanks for letting us know, Steinkuehler.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/30cf3e82-eae4-07cb-7be8-0bf34137de0d%40steinkuehler.net.

[TJF]

Interesting, thanks Charles!

Am Mittwoch, 3. Juli 2019 17:35:41 UTC+2 schrieb Charles Steinkuehler:

The
transfer is terminated if either PRU core stalls for more than 1024
cycles.

How to distinguish between a terminated or regular transfer?

Regards

[Charles Steinkuehler]

From the TRM:
"In direct connect mode (device ID 14), any PRU transaction will be
terminated if the stall is greater than 1024 cycles. This will
generate the event pr<1/0>_xfr_timeout that is connected to INTC."

--
Charles Steinkuehler
cha...@steinkuehler.net

[TJF]

Thanks for quoting the TRM for me (I didn't download the 'c' version yet).

So we have to check the event bit and clear it in a second cycle.

My method to HALT one PRU and resume it by the other is less expensive and more flexible. It isn't limited to a 1024 cycle window. And by specifying any program counter, the halted PRU can continue anywhere, not just at the next position in IRAM.

Regards