Re: [beagleboard] Re: Reading ADC with both PRUs

['Mark Lazarewicz' via BeagleBoard]

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.


Sent from Yahoo Mail on Android 
 
  On Fri, Jun 18, 2021 at 3:20 AM, 'Mark Lazarewicz' via 
BeagleBoard wrote:   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

Sent from Yahoo Mail on Android 
 
  On Fri, Jun 18, 2021 at 2:58 AM, 'Mark Lazarewicz' via 
BeagleBoard wrote:   Slightly off subject but to 
me this AM64  looks big

https://training.ti.com/sitara-am64x-processors-combine-powerful-communication-and-real-time-performance
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來





Sent from Yahoo Mail on Android 
 
  On Wed, Jun 16, 2021 at 11:52 AM, 'Mark Lazarewicz' via 
BeagleBoard wrote:   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 RAMPRU data and instruction 
RAM( fastest for PRU)The  Shared SRAM between ARM and PRU and any DSP on other 
chips( used by rproc??)


Thanks

Sent from Yahoo Mail on Android 
 
  On Tue, Jun 15, 2021 at 7:27 AM, TJF wrote:   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.

wal...@edenconceptsllc.com schrieb am Montag, 14. Juni 2021 um 19:55:30 UTC+2:

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.On Sunday, June 13, 2021 at 11:38:06 
AM UTC-4 TJF wrote:


wal...@edenconceptsllc.com schrieb am 

Re: [beagleboard] Re: Reading ADC with both PRUs

['Mark Lazarewicz' via BeagleBoard]

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

Sent from Yahoo Mail on Android 
 
  On Fri, Jun 18, 2021 at 2:58 AM, 'Mark Lazarewicz' via 
BeagleBoard wrote:   Slightly off subject but to 
me this AM64  looks big

https://training.ti.com/sitara-am64x-processors-combine-powerful-communication-and-real-time-performance
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來





Sent from Yahoo Mail on Android 
 
  On Wed, Jun 16, 2021 at 11:52 AM, 'Mark Lazarewicz' via 
BeagleBoard wrote:   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 RAMPRU data and instruction 
RAM( fastest for PRU)The  Shared SRAM between ARM and PRU and any DSP on other 
chips( used by rproc??)


Thanks

Sent from Yahoo Mail on Android 
 
  On Tue, Jun 15, 2021 at 7:27 AM, TJF wrote:   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.

wal...@edenconceptsllc.com schrieb am Montag, 14. Juni 2021 um 19:55:30 UTC+2:

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.On Sunday, June 13, 2021 at 11:38:06 
AM UTC-4 TJF wrote:


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 

Re: [beagleboard] Re: Reading ADC with both PRUs

['Mark Lazarewicz' via BeagleBoard]

Slightly off subject but to me this AM64  looks big

https://training.ti.com/sitara-am64x-processors-combine-powerful-communication-and-real-time-performance
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來





Sent from Yahoo Mail on Android 
 
  On Wed, Jun 16, 2021 at 11:52 AM, 'Mark Lazarewicz' via 
BeagleBoard wrote:   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 RAMPRU data and instruction 
RAM( fastest for PRU)The  Shared SRAM between ARM and PRU and any DSP on other 
chips( used by rproc??)


Thanks

Sent from Yahoo Mail on Android 
 
  On Tue, Jun 15, 2021 at 7:27 AM, TJF wrote:   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.

wal...@edenconceptsllc.com schrieb am Montag, 14. Juni 2021 um 19:55:30 UTC+2:

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.On Sunday, June 13, 2021 at 11:38:06 
AM UTC-4 TJF wrote:


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.





-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/229ebebd-2672-449b-a9ac-5ff2c99d2027n%40googlegroups.com.
  


-- 
For more options, visit 

Re: [beagleboard] Re: Reading ADC with both PRUs

['Mark Lazarewicz' via BeagleBoard]

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 RAMPRU data and instruction 
RAM( fastest for PRU)The  Shared SRAM between ARM and PRU and any DSP on other 
chips( used by rproc??)


Thanks

Sent from Yahoo Mail on Android 
 
  On Tue, Jun 15, 2021 at 7:27 AM, TJF wrote:   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.

wal...@edenconceptsllc.com schrieb am Montag, 14. Juni 2021 um 19:55:30 UTC+2:

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.On Sunday, June 13, 2021 at 11:38:06 
AM UTC-4 TJF wrote:


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.





-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/229ebebd-2672-449b-a9ac-5ff2c99d2027n%40googlegroups.com.
  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1443649067.432564.1623862352620%40mail.yahoo.com.

[beagleboard] Re: Reading ADC with both PRUs

[TJF]

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.

wal...@edenconceptsllc.com schrieb am Montag, 14. Juni 2021 um 19:55:30 
UTC+2:

> 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.
> On Sunday, June 13, 2021 at 11:38:06 AM UTC-4 TJF wrote:
>
>>
>> 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.
>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/229ebebd-2672-449b-a9ac-5ff2c99d2027n%40googlegroups.com.

Re: [beagleboard] Re: Reading ADC with both PRUs

[Walter Cromer]

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

On Friday, June 11, 2021 at 5:28:54 PM UTC-4 lazarman wrote:

> 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?
>
> Mark
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Fri, Jun 11, 2021 at 12:33 PM, Dennis Lee Bieber
>  wrote:
>
> On Fri, 11 Jun 2021 09:44:27 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  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
> 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
>
>
>
> -- 
> 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
> .
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b8503d7a-30a7-4ef8-96b4-7bf6033dd3cen%40googlegroups.com.

Re: [beagleboard] Re: Reading ADC with both PRUs

[Walter Cromer]

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

On Monday, June 14, 2021 at 3:23:29 AM UTC-4 lazarman wrote:

> #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
>
>
> https://elinux.org/Ti_AM33XX_PRUSSv2
>
>
>
> 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 
> portAccess 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 PRUsScratch pad3 
> 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 memoryAccessed over the 32-but bus, not 
> single-cycle.
> Sent from Yahoo Mail on Android 
> 
>
> On Sun, Jun 13, 2021 at 10:38 AM, TJF
>  wrote:
>
>
> 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.
>
>
> -- 
> 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/f4f5965c-6350-442a-b91a-47b7535d9cecn%40googlegroups.com
>  
> 
> .
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/05e4f1e0-f0e1-4e62-9652-7a696e58e1e3n%40googlegroups.com.

[beagleboard] Re: Reading ADC with both PRUs

[Walter Cromer]

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.
On Sunday, June 13, 2021 at 11:38:06 AM UTC-4 TJF wrote:

>
> 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.
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fc828903-9075-412a-9f1a-ca8aec37eb1an%40googlegroups.com.

Re: [beagleboard] Re: Reading ADC with both PRUs

['Mark Lazarewicz' via BeagleBoard]

#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

https://elinux.org/Ti_AM33XX_PRUSSv2

   
  - 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 
 
  On Sun, Jun 13, 2021 at 10:38 AM, TJF wrote:   
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.



-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f4f5965c-6350-442a-b91a-47b7535d9cecn%40googlegroups.com.
  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1993917417.3764103.1623655390603%40mail.yahoo.com.

[beagleboard] Re: Reading ADC with both PRUs

[TJF]

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.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f4f5965c-6350-442a-b91a-47b7535d9cecn%40googlegroups.com.

Re: [beagleboard] Re: Reading ADC with both PRUs

['Mark Lazarewicz' via BeagleBoard]

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?
Mark

Sent from Yahoo Mail on Android 
 
  On Fri, Jun 11, 2021 at 12:33 PM, Dennis Lee 
Bieber wrote:   On Fri, 11 Jun 2021 09:44:27 -0700 
(PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 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
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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/s377cghljsjo1uhfmsn4sbj7bi1206lcnq%404ax.com.
  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1034361247.3488153.1623446916131%40mail.yahoo.com.

[beagleboard] Re: Reading ADC with both PRUs

[Walter Cromer]

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

On Friday, June 11, 2021 at 1:33:05 PM UTC-4 Dennis Bieber wrote:

> On Fri, 11 Jun 2021 09:44:27 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  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
> 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
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/78f2bd55-726a-4b03-9cf4-345d6486ec59n%40googlegroups.com.

[beagleboard] Re: Reading ADC with both PRUs

[Dennis Lee Bieber]

On Fri, 11 Jun 2021 09:44:27 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 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
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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/s377cghljsjo1uhfmsn4sbj7bi1206lcnq%404ax.com.