Using Both PRUs together on a Black Wireless

Our application is currently using PRU0 to operate most of our system that requires deterministic operation. We use the ARM for UI and control of some non-time sensitive components.

I would like to bring in PRU1 to handle a few tasks and have PRU0 and PRU1 collaborate.

I tried a simple step. I wrote and compiled code for PRU1 to configure the TSC ADC and that code works fine SO LONG AS PRU0 is not running.

Question 1 then, what do I need to do to enable PRU0 and PRU1 to execute code at the same time?

Next, if this can work, I want PRU0 to signal PRU1 to do a task. The poor man’s way would be to setup a PRU0 accessible GPIO line as output and setup a PRU1 accessible GPIO line as input and physically wire the two i/o ports together. This uses up two ports though that I could use for something else.

The second option I thought of is to define a variable in shared memory space and have PRU0 set the value to 1 to signal PRU1. PRU1 would just continuously check that memory space for a 1 and reset it to 0 when it reads the 1 and completes it’s task.

I suspect there is some other way I’m not familiar with. What is the best, most reliable way to accomplish this?

We are currently running on 4.19x.

Check how BeagleLogic uses the inter-PRU signaling feature. There’s a great article series by the author: BeagleLogic: Building a logic analyzer with the PRUs: Part 1 – The Embedded Kitchen

1 Like

A similar, but more complex concept gets shown in example pruss_toggle. One PRU doesn’t trigger the other. Instead PRU-0 generates a PWM signal (20 MHz) and PRU-1 measures the frequency and duty cycle (by eCAP).

This gets shown in example pruss_add. A function is running at PRU-0, getting parameters from ARM CPU. It’s trivial to send the parameters/fetch the return value from the other PRU.

When using SRam, the writing preferences depend on the PRU running the firmware (switching the PRUSS result in different preferences). So I recomment to exchange data in DRam.

Regards

Um, nothing in particular? If you can’t run them simultaneously, something is strange. Try and just toggle a PRU I/O in both on a tight loop so you can verify that everything is correct. I suspect your init code is accidentally blocking on external resource access.

As for signalling, you can send an interrupt between the two PRUs. I’d probably use that since your PRU1 can sit in a loop and wait until it gets the interrupt from PRU0. Remember, interrupts on the PRUs are polled so they would work just like monitoring a bit in shared memory space.

1 Like

the best most reliable way for the two PRU to communicate is a ‘ring buffer’. More reliable than just a variable which wouldn’t account for requests generated faster than they could be handled.

a ring buffer sufficiently large, would allow requests to queue up awaiting processing. Neither PRU would need to obsess on whether the other PRU is ‘ready’ for communication. The writer would simply write to the buffer when appropriate, and the reader would read from the buffer when ready to perform the task.

Circular buffer - Wikipedia gives good overview of the process.

The app that I have made available for download uses two ring buffers. one connects the ARM processor to PRU1 and the second connects PRU1 to PRU0. You might find it instructive to study.

good luck
gomer

1 Like