Reading ADC with both PRUs

I have asked this of TI but haven’t really gotten a firm answer and I can’t seem to find a clear discussion in the Technical Reference Manual.

I would like to set up PRU1 to monitor two analog input lines and take an action on two GPIOs depending on the values it reads. It would just be started by either the host program through remoteproc or by PRU0.

Simultaneously, I need PRU0 to read three other analog lines and do more complex control work with those.

I can have PRU1 do all the ADC configuration including setting up steps 1, 2 and 3 to read three analog lines in one-shot mode while steps 4 & are set up to read the other two analog lines in continous mode. I’ll write data from steps 1, 2 and 3 into FIFO0 and 4 & 5 into FIFO1.

The question is can PRU0 read FIFO0 while PRU1 might try to read FIFO1 at the same time?

Given that each PRU is capable of accessing the other's data RAM (as I
recall, each PRU sees its RAM at address 0, and sees the other's RAM at
some fixed offset), I'd probably use a few words of PRU0's RAM and have
PRU1 write into that space, along with a timestamp value -- PRU0 would look
for a change in the timestamp, then grab the ADC values (allowing PRU1 to
write new values while PRU0 processes the previous set -- Or PRU0 clears
the timestamp [which is no longer a timestamp] which PRU1 sees as "okay to
write new values", PRU1 then sets the timestamp byte to tell PRU0 "okay to
read". Closest I can come to a shared semaphore/mutex (are there any
synchronization primitives in the PRU runtime?).

I’m going to hold on to this as a backup option. I’m already using the shared memory space so that’s another option but writing to PRU0’s local RAM may be faster. I don’t know. The monitor/control that PRU1 is doing doesn’t would be just fine with a 1-second read interval I think. The three lines that PRU0 is already reading in this application require at least 3ms intervals or better.

Thanks for the good idea on this.


Hello Walter

Two ansychronous processor’s it’s entirely possible eventually ones writing and other is reading and gets bad Data that’s why they invented hardware dual port ram.

Ping pong circular buffer’s work on one processor systems you disable interrupts in critical regions or lock it with a mutex controlled by RTOS.

Perhaps it’s not critical

How long have you been waiting on an answer just curious?


… setting up steps 1, 2 and 3 to read three analog lines in one-shot mode while steps 4 & are set up to read the other two analog lines in continous mode. I’ll write data from steps 1, 2 and 3 into FIFO0 and 4 & 5 into FIFO1.

Yes. You can use the FIFO_select bit (26) in the STEPCONFIGx registers to spread the samples. And when the Mode bits (1-0) are cleared (one-shot) the sequencer will disable that step after operation (in STEPENABLE register). Next turn the sequencer will again consider only enabled steps.

The question is can PRU0 read FIFO0 while PRU1 might try to read FIFO1 at the same time?

Not at the same time, but one after the other (L3 access control). AFAIR PRU-1 waits until PRU-0 is done. And both PRUSS are waiting until ARM is done.

#The question is can PRU0 read FIFO0 while PRU1 #might try to read FIFO1 at the same time?

If these FIFOS are in Data RAM it’s recommended to use shared memory. What’s confusing is as I understood it there’s a PRU shared RAM and another larger shared memory so sample code must be inspected carefully if that’s true to understand exactly what’s being referred to as Shared. I think the larger RAM is called OCM.

Below and following link is the relavent blurb to support my comment I found here

One PRU may access the memory of another for passing information but it is recommend to use scratch pad or shared memory, see below.
[Open Core Protocol]( (OCP) master port
Access to the data bus that interconnects all peripherals on the SoC, including the ARM Cortex-A8, used for data transfer directly to and from the PRU in Level 3 (L3) memory space.
### Shared Between PRUs
Scratch pad
3 banks of 30 32-bit registers (total 90 32-bit registers).
Single-cycle access, can be accessed from either PRU for data sharing and signalling or for individual use.
12KB data memory
Accessed over the 32-but bus, not single-cycle.
[Sent from Yahoo Mail on Android](

I am thinking that I’ll have PRU0 do all the configuration and enabling of the TSC and have the values for the two sensors that I want PRU1 to monitor put in FIFO1. I’ll have PRU0 only read from FIFO0 and let PRU1 only read from FIFO1.
I will set up the three I want to read in one-shot mode and have PRU0 enable them to be read again. the other two will be in continuous mode so PRU0 won’t have to do anything as long as it doesn’t change their configuration.
If PRU-1 waits until PRU-0 is done then it can read FIFO1 as needed to get the data. I only need it to read these possibly as little as once per second so that alone will reduce the number of potential conflicts with PRU0.

If this will work it will eliminate having PRU0 read FIFO1 and write the data into shared memory space where PRU1 could read it. That in itself would have a potential conflict on PRU0 write/PRU1 read.

Good info. I’m going to set up some testing. Thank you!

Mark - I think I waited a day or maybe two. They’ve engaged and are answering my questions. It’s congruent with what is being shared here.


I don’t understand that concept. When you switch bits in the STEPENABLE register, you’d loose accurate ADC timing. What sampling rate are you talking about?

AFAIR your target is to controlling two eletromagnetic valves (water medium?). They’ve a latency of more than 10 ms → sampling rate & controller loop should be 1 kHz or above.

When sampling all 5 channels continguously in one FIFO and fetching them by one PRU in a ring buffer (SRam), you can do this with accurate timing up to 40 kHz (more than enough). Meanwhile the other PRU evaluates the ring buffer, computing the standard channels (4 &) continguously and the other channels (1, 2, 3) on demand. Note: There’re 1000 PRU cycles between two ADC samples, and 5000 PRU cycles between a sequencer loop (@ 40kHz). Both PRUs exchange the last ring buffer writing position by DRam (or scratch pad).

This alternative concept does not only guarantee accurate timing, it’s also easy to develop and maintain.

BTW: It doesn’t matter which PRU (or the ARM) does the configuration. Just starting the sequencer (CTRL register) should be done by the ADC-PRU.

Both PRUs exchange the last ring buffer writing position by DRam (or scratch pad).

Too many RAMS we need to be clear to avoid confusion please


Internal RAM is SRAM and there are several

SBL ARM internal SRAM (fast from ARM)
PRU shared RAM
PRU data and instruction RAM( fastest for PRU)
The Shared SRAM between ARM and PRU and any DSP on other chips( used by rproc??)


Slightly off subject but to me this AM64 looks big

1Meg of SRAM split between the 4 Cortex R4 that can run bare metal or Free RTOS and in next release instead of waiting for Linux to boot to load the firmware by Rproc it’s loaded in about 500 mS.

Supports Linux on dual A53 has 2 PRU and a 5th R5 onboard JTAG and GUI creator for Linux side and supports BLE and WiFi ( not sure if that’s an add on)

$99 for starter kit. I’ve ordered one

Not sure if PRU has access to all that fast SRAM but anything done by the PRU can certainly be done by any of the R4 which has REAL interrupts and much easier to rapidly code and debug than the PRU.

No hocus pocus transferring large amounts of Data from PRU or R4 using slow DDR and spending months trying to squeeze a few bytes of memory for the PRU​:joy::ok_hand::face_with_hand_over_mouth:

Even Nick the TI resident PRU genius used 2 PRU to implement his FOC reference design.
The AM64 demo app uses one Cortex ARM R4 to do the same thing. On a SOC like AM64x the PRU would only be needed if you ran out of peripherals.
Amazing demo one R4 is running FFT no need to pass anything back to A53. The Application core(A53) is nothing more than a network gateway wired or wireless and a GUI Host. That turns Linux programmers into PC programmer’s :face_with_hand_over_mouth: and the Real Time programming is done in RTOS.
Maybe in next release with quick boot they will fix RPMSg make it faster. Perhaps they ported libprio :japanese_goblin: fixed it and documented it properly

Ooops I forgotten. I’m pretty sure the Matlab to implement FOC is already a possibility on Cortex R4 that’s never going to happen for PRU

Vector control, also called field-oriented control (FOC), is a variable-frequency drive (VFD) control method in which the stator currents of a three-phase AC or brushless DC electric motor are identified as two orthogonal components that can be visualized with a vector.