Reading ADC with both PRUs
101 views
Skip to first unread message
Walter Cromer
Jun 11, 2021, 12:44:27 PM6/11/21
to BeagleBoard
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?
Dennis Lee Bieber
Jun 11, 2021, 1:33:05 PM6/11/21
to Beagleboard
On Fri, 11 Jun 2021 09:44:27 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
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?).
--
Dennis L Bieber
gmane.comp.hardware.beagleboard.user Walter Cromer
<walterc-2dFtBuzUeF/tpnMUCzy8b...@public.gmane.org> wrote:
>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
>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?
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?).
--
Dennis L Bieber
Walter Cromer
Jun 11, 2021, 4:07:29 PM6/11/21
to BeagleBoard
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.
Walter
Mark Lazarewicz
Jun 11, 2021, 5:28:54 PM6/11/21
to Dennis Lee Bieber, Beagleboard
Hello Walter
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?
Mark
--
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+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/s377cghljsjo1uhfmsn4sbj7bi1206lcnq%404ax.com.
TJF
Jun 13, 2021, 11:38:06 AM6/13/21
to BeagleBoard
wal...@edenconceptsllc.com schrieb am Freitag, 11. Juni 2021 um 18:44:27 UTC+2:
... 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.
Mark Lazarewicz
Jun 14, 2021, 3:23:29 AM6/14/21
to beagl...@googlegroups.com
#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.
--
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
Walter Cromer
Jun 14, 2021, 1:55:30 PM6/14/21
to BeagleBoard
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.
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.
Walter Cromer
Jun 14, 2021, 1:56:38 PM6/14/21
to BeagleBoard
Good info. I'm going to set up some testing. Thank you!
Walter Cromer
Jun 14, 2021, 1:58:06 PM6/14/21
to BeagleBoard
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.
Walter
Walter
TJF
Jun 15, 2021, 8:27:30 AM6/15/21
to BeagleBoard
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).
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.
Mark Lazarewicz
Jun 16, 2021, 12:52:51 PM6/16/21
to beagl...@googlegroups.com
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
DDR is DRAM
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??)
Thanks
--
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
Mark Lazarewicz
Jun 18, 2021, 3:58:19 AM6/18/21
to 'Mark Lazarewicz' via BeagleBoard
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😂👌🤭
Mark Lazarewicz
Jun 18, 2021, 4:20:26 AM6/18/21
to beagl...@googlegroups.com
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 🤭 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 👺 fixed it and documented it properly
On Fri, Jun 18, 2021 at 2:58 AM, 'Mark Lazarewicz' via BeagleBoard<beagl...@googlegroups.com> wrote:
Mark Lazarewicz
Jun 18, 2021, 4:23:33 AM6/18/21
to beagl...@googlegroups.com
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.
On Fri, Jun 18, 2021 at 3:20 AM, 'Mark Lazarewicz' via BeagleBoard<beagl...@googlegroups.com> wrote:
Reply all
Reply to author
Forward
0 new messages