In addition to the above . . . It sounds as though you're not clearing your data once you're done with it.
So perhaps, and I'm speculating here. The value the PRU is put into a variable initially - Where then you copy that value into a ring / circular buffer. If you're getting identical time stamps, and data into your circular buffer, then you're not clearing your initial variable(s) once done with that particular data value. Still, the whole situation seems more like a synchronization issue to me more than anything. Still, you should probably be clearing your data fields as well - Once done with them. On Wed, Sep 9, 2015 at 4:16 PM, William Hermans <[email protected]> wrote: > 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.
