Problems reading PRU data RAM from host side on beaglebone black

[Christopher Hansen]

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

[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

[Christopher Hansen]

My code on the PRU is in assembly, but it gets called from c, like this (PRU code here):

#include <stdint.h>

#include <pru_cfg.h>

#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

[Dennis Lee Bieber]

On Mon, 20 Jul 2020 13:58:13 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Christopher Hansen

<hansencj-Re5JQE...@public.gmane.org> wrote:

>My code on the PRU is in assembly, but it gets called from c, like this
>(PRU code here):
>
>#include <stdint.h>
>#include <pru_cfg.h>
>#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

[Christopher Hansen]

It has the correct label in the assembly code,  START: , so it runs.  I fixed that.  Thanks.

Chris

[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

[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

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