Well, buffer in my case was actually fixed size buffer[<some value>], and not a pointer type character array, but you get the idea I hope.
On Wed, Sep 9, 2015 at 4:10 PM, William Hermans <[email protected]> wrote: > 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.
