Re: [beagleboard] Re: Problems reading PRU data RAM from host side on beaglebone black

2020-07-22 Thread Christopher Hansen 
Hi Daniel,

Thanks for your help.  Unfortunately, I cannot get your scripts to work.
It looks like you enter a string of options when you run the script.  Do
you have an example?  Maybe this is really dumb, but your assembler code
has #include and #define statements that create errors with clpru.  Is
there an option I am missing?  I can use .asg instead of #define, but I am
not sure what to use instead of #include.

Chris


On Tue, Jul 21, 2020 at 8:47 AM Daniel Kulp  wrote:

>
> For the pure asm  part of this
>
> You can look at the FPP PRU code:
> https://github.com/FalconChristmas/fpp/tree/master/src/pru
> and the sh scripts in there used to compile the asm.The FPP PRU code
> is all hand tuned assembly and does NOT use the C runtime/stack at all.
> Thus, the entire memory blocks are available to the pru assembly code.
>
> You basically need to get the "ResourceTable.asm" included, set the "main"
> section text segment, and then pass the right flags to clpru.  The results
> "out" can then be loaded via rproc.
>
> Dan
>
>
> On Monday, July 20, 2020 at 4:58:13 PM UTC-4 hans...@gmail.com wrote:
>
>>
>> Another option I am trying is to have the PRUs write data to DRAM memory
>> directly.  I really want to do this in assembly because my PRU code has
>> some tight timing.  I couldn't find any examples online to do this with the
>> rproc driver however. Any ideas?
>>
> --
> 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/75b11b9a-85e8-4b4d-a13a-e8004bff78ccn%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/CA%2BvnBy--G8XZTh2U%2BxNdHkbcqGHU2SHg%2BFz_DVR8G%2BqDHH3OoA%40mail.gmail.com.

[beagleboard] Re: Problems reading PRU data RAM from host side on beaglebone black

2020-07-21 Thread Daniel Kulp 

For the pure asm  part of this  

You can look at the FPP PRU code:
https://github.com/FalconChristmas/fpp/tree/master/src/pru
and the sh scripts in there used to compile the asm.The FPP PRU code is 
all hand tuned assembly and does NOT use the C runtime/stack at all.  Thus, 
the entire memory blocks are available to the pru assembly code.   

You basically need to get the "ResourceTable.asm" included, set the "main" 
section text segment, and then pass the right flags to clpru.  The results 
"out" can then be loaded via rproc.

Dan


On Monday, July 20, 2020 at 4:58:13 PM UTC-4 hans...@gmail.com wrote:

>
> Another option I am trying is to have the PRUs write data to DRAM memory 
> directly.  I really want to do this in assembly because my PRU code has 
> some tight timing.  I couldn't find any examples online to do this with the 
> rproc driver however. Any ideas?
>

-- 
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/75b11b9a-85e8-4b4d-a13a-e8004bff78ccn%40googlegroups.com.

[beagleboard] Re: Problems reading PRU data RAM from host side on beaglebone black

2020-07-20 Thread Christopher Hansen 
It has the correct label in the assembly code,  START: , so it runs.  I 
fixed that.  Thanks.

Chris


On Monday, July 20, 2020 at 2:21:39 PM UTC-7 Dennis Bieber wrote:

> On Mon, 20 Jul 2020 13:58:13 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Christopher Hansen
>  wrote:
>
> >My code on the PRU is in assembly, but it gets called from c, like this 
> >(PRU code here):
> >
> >#include 
> >#include 
> >#include "resource_table_empty.h"
> >
> >// The function is defined in ledFlashASM.asm in same dir
> >// Declaration is here, defination is linked to the .asm
> >extern void start(void);
> >
> >void main(void)
> >{
> > START();
>
> Uhm... C is case sensitive, no? In which case your START() is not the
> same as the extern start().
>
>
> -- 
> 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/9e2b998a-ddb6-4978-a3c6-7c22730007cbn%40googlegroups.com.

[beagleboard] Re: Problems reading PRU data RAM from host side on beaglebone black

2020-07-20 Thread Dennis Lee Bieber 
On Mon, 20 Jul 2020 13:58:13 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Christopher Hansen
 wrote:

>My code on the PRU is in assembly, but it gets called from c, like this 
>(PRU code here):
>
>#include 
>#include 
>#include "resource_table_empty.h"
>
>// The function is defined in ledFlashASM.asm in same dir
>// Declaration is here, defination is linked to the .asm
>extern void start(void);
>
>void main(void)
>{
>   START();

Uhm... C is case sensitive, no? In which case your START() is not the
same as the extern start().


-- 
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/3j2chfhdmo9kd42bnfo7fc02e0gt8rt3qp%404ax.com.

[beagleboard] Re: Problems reading PRU data RAM from host side on beaglebone black

2020-07-20 Thread Christopher Hansen 
My code on the PRU is in assembly, but it gets called from c, like this 
(PRU code here):

#include 
#include 
#include "resource_table_empty.h"

// The function is defined in ledFlashASM.asm in same dir
// Declaration is here, defination is linked to the .asm
extern void start(void);

void main(void)
{
   START();
}

So maybe some stuff gets written into the area once, on the call to START?  
After that it should not change, right?

I am wondering if I should only be reading the PRU memory from the ARM side 
while the PRUs are halted.  I don't want to do that, because I am trying to 
sample some data continuously.

Another option I am trying is to have the PRUs write data to DRAM memory 
directly.  I really want to do this in assembly because my PRU code has 
some tight timing.  I couldn't find any examples online to do this with the 
rproc driver however. Any ideas?

Thanks.


Chris


On Monday, July 20, 2020 at 11:31:59 AM UTC-7 Mark A. Yoder wrote:

> Chris:
>   The code you give is running on the ARM side.  It's copying data from 
> the PRUs by mmap().  What's running on the PRU side?  If it c code, did you 
> take into account the PRU c compiler stores it's stack and heap at the 
> beginning of the shared ram?
>
> --Mark
>
> On Saturday, July 18, 2020 at 3:47:28 PM UTC-4 hans...@gmail.com wrote:
>
>> I'm using both PRU0 and PRU1 for data acquition.  The PRUs write data to 
>> their respective memory blocks and I read the data from the host arm core 
>> via mmaps.  I.E.,
>>
>>  pru0mem = (int32_t *) mmap(0, MAP_SIZE, PROT_READ, MAP_SHARED, fd, 
>> PRU0_RAM & ~MAP_MASK);
>>   pru1mem = (int32_t *) mmap(0, MAP_SIZE, PROT_READ, MAP_SHARED, fd, 
>> PRU1_RAM & ~MAP_MASK);
>>   pru0point = (int32_t *) mmap(0, MAP_SIZE, PROT_READ, MAP_SHARED, fd, 
>> PRU_SHARED & ~MAP_MASK);
>>
>> bigbuf[k] = prumem0[k];
>> ...
>> where bigbuf is a big array on the arm side.
>>
>> It seems to work, however, when it runs continuously it seems like there 
>> is some type of random glitch where occasionally I am getting bad data.  
>> Any idea how this could happen?  Could it be something with the pru_rproc 
>> driver?  Is there a better way to do this?
>>
>> Thanks.
>> Chris
>>
>>

-- 
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/d3e9f25c-ca82-4a58-8929-5c5797c11d6en%40googlegroups.com.

[beagleboard] Re: Problems reading PRU data RAM from host side on beaglebone black

2020-07-20 Thread Mark A. Yoder 
Chris:
  The code you give is running on the ARM side.  It's copying data from the 
PRUs by mmap().  What's running on the PRU side?  If it c code, did you 
take into account the PRU c compiler stores it's stack and heap at the 
beginning of the shared ram?

--Mark

On Saturday, July 18, 2020 at 3:47:28 PM UTC-4 hans...@gmail.com wrote:

> I'm using both PRU0 and PRU1 for data acquition.  The PRUs write data to 
> their respective memory blocks and I read the data from the host arm core 
> via mmaps.  I.E.,
>
>  pru0mem = (int32_t *) mmap(0, MAP_SIZE, PROT_READ, MAP_SHARED, fd, 
> PRU0_RAM & ~MAP_MASK);
>   pru1mem = (int32_t *) mmap(0, MAP_SIZE, PROT_READ, MAP_SHARED, fd, 
> PRU1_RAM & ~MAP_MASK);
>   pru0point = (int32_t *) mmap(0, MAP_SIZE, PROT_READ, MAP_SHARED, fd, 
> PRU_SHARED & ~MAP_MASK);
>
> bigbuf[k] = prumem0[k];
> ...
> where bigbuf is a big array on the arm side.
>
> It seems to work, however, when it runs continuously it seems like there 
> is some type of random glitch where occasionally I am getting bad data.  
> Any idea how this could happen?  Could it be something with the pru_rproc 
> driver?  Is there a better way to do this?
>
> Thanks.
> Chris
>
>

-- 
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/6c68d818-fabc-45a7-ab01-6f521b8111fcn%40googlegroups.com.