Hi, 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 */ > a4l_snd_insn(dsc, > > 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? > > Cheers, > -- > Daniele -- Alexis. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
