[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems clearing PC-Dig - again



> OK. It looks like I still have problems clearing the buffer on our
> PC-Dig - remember, I'm trying to read out lines from the line scan
> camera using GIOC_CR_SET_START to make sure the frame grabber will
> return data starting from the first line after everything is initialized
> (not after the next full frame.)
>
> Now, we've been running a test version of the code for quite some time
> now, and it works fairly well most of the time, but on
>
>   1. There seems to be a constant offset at the start - a number of
>      lines are missing initially. Internal consistency is still
>      maintained (but see below), i.e. I'm able to restart where I left
>      off when I have to stop due to a "buffer overrun" or similar as the
>      offset will be exactly the same when I do.
>   2. Everything does get completely out-of-sync from time-to-time, but
>      I'm unable to work out under what conditions.
>
> I thought I might ask once again if there isn't a better way to reset
> the state of the grabber. - As you will probably recall, I'm no stranger
> to updating the kernel source, but I'll need some pointers to the
> relevant sections of the code.

I've now re-written my code a bit, and it seems like I have more control
over what happens now. I've modified the sequence of operations so that I'm
absolutely sure the "clear" is complete when real data starts arriving, and
the routine also waits for a while before checking if a frame is available
when it has sent a trigger to make sure that the "filled" state has been
updated. The relevant section of the updated code is included below.

After introducing these updates, I have not seen any cases where
synchronization is lost (although I thought I tried more or less the same
changes yesterday and still couldn't get anything right, but I guess it was
just one of those days where nothing will work), but there is still a
constant offset involved. In fact, it looks like an additional line has
been transferred when lseek() output changes, so that the first <lines in
frame>-1  lines are discarded in the subsequent grab cycle. Comments,
anyone?


           camconf.pcd_cam.extime=10; // *** As low as possible
           camconf.pcd_cam.rotime=0;
           camconf.pcd_cam.exsmd=PCD_EXSYNC_SW_TRIG0;

           if(ioctl(camFd, GIOC_GE_SET_CAMCNF, &camconf)==0 &&
              ioctl(camFd, GIOC_CR_SET_START, NULL)==0) {
             int trigCnt=0;
             // We _know_ lseek() returns 0 is when first valid buffer is
             // filled - offset of the last one is returned before that.
             usleep(110);
             do {
               if(ioctl(camFd, GIOC_CR_SET_TRIG, NULL)==0) {
                 trigCnt++;
                 usleep(110);
               }
             } while(lseek(camFd, 0UL, SEEK_CUR)!=0);

- Toralf