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

[<M....@go...>]

Hello Tim,

Tim van Werkhoven <T.I...@ph...> wrote on 12.04.2008
20:21:08:

> Hi again Matthias,
>
>> ...
>
> 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?

When You are doing a normal blocking read with page_size, it is easy
for You and the driver. The call blocks until a new frame has arrived
an then the frame is copied out. If You call read the next time, You
block and read the next frame.

With select/mmap the things get more difficult:

1. How to wait for a new frame? -> with select, You have done this.

2. How to get the information, at with offset into Your mmap space
   the most recent frame resides, at 0 * page_size, 1* page_size,
   2 * page_size, 3 * page_size (assuming mmap size is 4 frames).

   This is done by lseek 0 SEEK_END

3. You have to tell the driver, that You have read/accepted the frame.
   This is important for Your problem, thar select always signals
   incoming data.

   This is done by lseek paged_size SEEK_CUR

The lseek interface is as follows

SEEK_END refers to the producer (the device driver that generated frames)
SEEK_CUR refers to the consumer (You)

offset == 0 means: don't change anything, query the current value
offset != 0 means: adjust somthing (paged_size based)

> - 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?
>

I'm don't have used this for a longer time. I have to check it. Is the
dma.transfered count updated!?

>
>> ...
>
> 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.

Please read the man/extime_itifg.txt manpage, it seems to be up-to-date
an describes it a little bit. Further You should have a look at
conffiles/vossk-ccd1300b-12bpp-pcd.cam. The values into this file are
setup for a free running mode with fps = 1/121ms and an exposure time
of 40ms (readout is 80ms, safety is 1ms)

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

If You have setup the camera in a manner, that it needs a trigger
input (edge) to make images and/or a shutter input (level) to control
the exposure time You have to use the exs device.

> 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

Thanks, I have fixed it.

> 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?

I don't know, what I have programed there. In EVERY case, it is wrong.
Thank's.

> Again thanks for your time and help,
>
> Tim

If some statement are too short, please ask again! You know, the time...

                                                matthias
_________________________________________________
Matthias Stein,
GOM Gesellschaft fuer Optische Messtechnik mbH,
Mittelweg 7-8, 38106 Braunschweig, Germany
E-mail: M....@go..., Internet: http://www.gom.com
Tel.: +49 (0)531 39029-0, Fax: +49 (0)531 39029-15
Amtsgericht Handelsregister Braunschweig, HRB-Nr.: 3131
Geschaeftsfuehrer: Dr.-Ing. K. Galanulis, Dr.-Ing. D. Winter


This e-mail is confidential. If you have received it in error, you are on
notice of its status.
Please notify us immediately by reply e-mail and delete this message from
your system.
Please do not copy it or use it for any purposes, or disclose its contents
to any other person;
to do so could be a breach of confidence.
Thank you for your co-operation.