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
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 [email protected] 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/d3e9f25c-ca82-4a58-8929-5c5797c11d6en%40googlegroups.com.
