Re: [Itifg-tech] Camera readout using itifg 8.4

[Tim v. W. <T.I...@ph...>]

Hi again Matthias,

> There are two basic operation modes:
>
> 1. The 'grab' mode
>  You only want to have one image at a time and You want to have the
>  most recent image. You don't care, if there are images lost, when
>  You process one.
>  Often used for live video and quick processing.
>
>     call sequence:
>     open
>     mmap ringbuffer size (min 2 images)
>     ioctl GET_CAMCNF
>     modify via iti_read_config
>     ioctl SET_CAMCNF
>     ioctl GET_RAW|PAGED_SIZE
>     lseek +LONG_MAX SEEK_END
>
> loop:
>     wait for image (poll/select/signal)
>     lseek 0 SEEK_CUR to get the offset of the current image into Your
> memory
>     Image Processing
>
>     lseek -LONG_MAX SEEK_END
>     munmap
>     close

I've been trying this but there are a few things that don't work, or  
at least not as I expected it to work.

Opening the board(/dev/ic0dma) and configuring it works without a  
problem as far as I can tell. Starting the camera with lseek +LONG_MAX  
works, but then I run into some problems.

My test program opens the device, reads configuration from the FG,  
reads the .cam file, sets the configuration, and then gets several  
camera variables (width, height, decimation etc). Finally I set the FD  
to nonblocking. After configuring the FG board I setup my mmap buffer.  
I reserve 4 * PAGEDSIZE bytes, giving me space for 4 frames. If I'm  
correct this procedure more or less mimics test_itifg.

First of all, select() does not seem to block until an image is ready,  
it returns immediately with return code 1, i.e. one FD would be ready  
for reading. When I run `lseek(cam->fd, 0, SEEK_CUR);` after that  
however, it returns 0, implying that nothing happend. Also the image I  
read out is the same every time lseek returns 0.

Second, I do not exactly know what to do with the lseek return value.  
In my test program I ran select() followed by lseek() several times,  
the first times lseek returned 0 and the images were identical. After  
a while, there appeared to be a new image as lseek returned exactly  
PAGEDSIZE, and the image I read out was different. However, I did not  
change my mmap'ed pointer at all, it was still pointing to the  
beginning of the mmap buffer. Another thing that I noticed is that  
lseek does not wrap, the values it returns can be anything, sometimes  
several times the mmap size.

The questions I have are:

- Do you know why select() does not block?

- What does lseek SEEK_CUR return, and what should I do with that? Do  
I need to adjust a pointer to the mmap'ed area myself, or is the mmap  
window modified by the driver?

- I noticed in test_itifg that you lseek with `int whence` set to  
SEEK_END with offset 0 several times as well. What does this do  
exactly, and do I need that?

- If I'm correct the data beyond the frame itself (after RAWSIZE)  
holds a iti_info_t struct. However, although I can read out the  
timestamp, I cannot read out the frames captures or lost, do you know  
how  to do this correctly? The methods I use is (after SEEK_CUR):

	buf->info = (iti_info_t *)((char *)buf->data + cam->rawsize);
	struct timeval timestamp; // copying unnecessary, I know
	memcpy (&timestamp, &(buf->info->acq.timestamp), sizeof(struct  
timeval));

after this, I would assume that buf->info->acq.captured and buf->info- 
 >acq.lost would hold the captured and lost images, however their  
values are 0. (int) timestamp.tv_sec does appear to work however, so I  
assume I'm reading the right part of memory. How can I get the frames  
captured and/or lost?

>> - What do the various parameters in the .cam files mean?
>
> You setup the board for a specific camera. The parameters are  
> different
> for the different boards and different cameras. There are some more
> exapmles into the conffiles dir and some of the parameters are self
> explaining. If You are unsure ask me for the behavior of a a specific
> switch.

I would like to set the camera runmethod (if I'm correct this is set  
with 'EXSYNC_MODE = EXSYNC_FREE_RUNNING'), what modes are available?

Also I would like to set the framerate and exposure time  
independently. There are multiple timings however, and I do not know  
which times the various parameters control. I noticed that  
EXT_SYNC_TIME appears to be rejected by test_itifg, when I uncomment  
the line '#EXT_SYNC_TIME = 572.000   # us (140ns ... 572us)',  
test_itifg tells me 'parse error line 24: EXT_SYNC_TIME = (null)',  
when setting it to 'EXT_SYNC_TIME = 0.572000' I get a segfault.

Furthermore, I noticed that EXT_SYNC_PERIOD_TIME must be longer than  
PRI_MIDPOINT_DELAY, is it correct that the first controls the  
framerate (period) and the other the exposure time or something?

In short: what do the timings mean? I'm using the PCDIG board in  
combination with a dalsa CA-D6 camera.

> There can be various operation modes for one camera. One of the most
> important choise it weather the camera makes images from itself (free-
> running mode) or it is controlled by the board (trigger and/or  
> exposure
> time). Then the exs device gets involved.

With respect to the above questions, how/when is the exs device  
relevant?

Also, I noticed a typo/error in pcdigIface.c. It statically fills a  
struct for setting a board to default config, which goes like:

  96                 /* next both values are adjusted by the fpga  
download!!! */
  97                 8,              /* most used pixel size */
  98                 PCD_1CHAN_L2R,  /* standard geometry */
  99                 PCD_DISABLE     /* non-interlaced is standard */

However, the struct is declared in itifgExt.h as:

714   int geometry; /* this we need to load the source scatter gather  
right */
715   int pixelsize; /* this value we need to load the lookup tables  
right */
716   int interlaced; /* we have to collect even and odd frame for one  
image */
717 };

suggestiong that line 97 and 98 are swapped in pcdigIface.c

Another thing that I found was that test_itifg does not accept mmap'ed  
mode, after calling

1596     if (ioctl (devdesc, GIOC_SET_CAMCNF, &camcnf) < 0)

it says

1602     if (args->other[args->other_i])
1603       Clean_Up (EXIT_SUCCESS);

which quites mmap mode immediately without capturing frames. Is that  
correct?

Again thanks for your time and help,

Tim