Hard to guess, but if I were to guess I would guess that the OS side of
things is reading the memory faster than the PRU can build the buffer -
Sometimes.
I also experienced using POSIX shared memory between two process in Linux.
How I dealt with this was pretty simplistic.
struct shared {
char *buffer[length];
int access;
}
/* write side process */
struct shared *s;
s->access = 0;
. . .
while(s->access != 0)
usleep(<some value>);
/* Do stuff when this process has access */
. . .
s->access = 1;
/* Read side process*/
struct shared *s;
. . .
while(s->access != 1)
usleep(<some value>);
/* Do stuff when this process has access */
. . .
s->access = 0;
*s in this case is a pointer to a mmap()'d region of shared memory. Which
both processes have access too. This virtually guarantees that each process
only has access to *buffer at the appropriate time. Meaning, the write
process starts off with access, and does not relinquish access until it is
done writing to the buffer. After which, the read process gains control,
does it's thing, and passes access back to the write process.
One caveat here that I can think of. The reading process should copy the
buffer data, and return control to the write process as fast as possible.
As the write process will be getting data in fairly fast I'm assuming, and
will have no place to store the data, *Unless* you use two buffers on the
PRU side.
On Wed, Sep 9, 2015 at 3:31 PM, Carlos Novaes <[email protected]> wrote:
>
> Hi
>
> I am facing a strange problem with my application. I have some code
> running on PRU0 and PRU1 that share some data using scratchpad. PRU1 also
> send some data to ARM, 32 bytes at each time with a counter value as
> timestamp. each time a new chuck of data is ready, it is written in a
> circular buffer on shared memory, also a pointer is updated in a fixed
> position of the shared memory and a interrupt is sent to the ARM. On the
> ARM side, each time the interrupt is received, the pointer is read so it
> can get the last chunk of data. So far so good.
> Analyzing the data received on the ARM side, we note some samples are
> missing, eg: timestamps are 1000, 1001, 1003, 1004, 1005.... (1002 is
> missing) and this is expected. That is the point in having a ring buffer.
> The problem is that sometimes, some samples are repeated. ex: 1004, 1005,
> 1005, 1006, 1008.... The only way I can think of this to happen is that for
> some reason the PRU flush data to the shared ram but this write is not
> completed before the interrupt is sent to the ARM... the ARM read the
> shared memory but finds old data.
> Here comes my question: I can deal with it as it happens here and there,
> but where and how can I investigate it further and maybe, how to ensure
> that this will not happen or at least, do not get worst?
>
> Thanks,
>
> Carlos Novaes
>
> --
> 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].
> For more options, visit https://groups.google.com/d/optout.
>
--
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].
For more options, visit https://groups.google.com/d/optout.
