Sorry for the late reply.
Daniele Nicolodi wrote:
> Daniele Nicolodi wrote:
> > Alexis Berlemont wrote:
> >> If you want to test infinite acquisitions right now, you can clone my
> >> git repository. I just pushed the modifications on it. I have not made
> >> a pull request yet because I want to be sure there is no regression.
> > Thanks! I'll test it as soon as possible.
> I'm testing it now.
> > I think I just stumbled into the ring buffer bug you fixed in your
> > repository :-) It took me a while to understand if the problem was in
> > the hardware, in my code, or somewhere else in the stack...
> Unfortunately my ring buffer problem is not fixed by you patch. What I'm
> experiencing is exposed by this (pseudo) code:
> a4l_open(dsc, device)
> a4l_mmap(dsc, subdevice, bufsize, &map)
> a4l_snd_command(dsc, cmd)
> /* preload buffer */
> written = write_to_buffer(map, bufsize)
> /* send internal trigger */
> cnt = 0;
> while (1)
> a4l_mark_bufrw(dsc, subdevice, written, towrite);
> cnt += written;
> /* 1 */
> written = write_buffer(map + (cnt % bufsize), towrite)
> The problem is that at the place marked with (1) the total extension of
> the buffer region that gets written exceeds the ring buffer allocated
> memory. That is ((cnt % bufsize) + towrite) > bufsize !
> I do not know if this should be handled in my code, or in the driver.
> This situation is not handled in the cmd_write example code (where a
> simple memcpy() is done).
There is a bug in cmd_write and cmd_read. I have should have taken
into account the buffers edges. I will fix it. The function
a4l_mark_bufrw() is not designed to handle boundaries, that is why its
arguments represent data size not addresses.
> What do you think?
Xenomai-core mailing list