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

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

Hello Tim,

sorry, You don't have overseen any documentation, because there is no
documentation,
that is 'up-to-date' :-(

iti...@li... wrote on 18.03.2008 15:34:05:

> Hi again Mattias,
>
> I'm trying to get a camera (dalsa cad6 256x256) to run with the itifg
> driver. It works with the test_itifg routine supplied with the driver
> after you helped my figure out how to tell the driver to use a
> specific .exo file (thanks again). I'm now trying to write my own
> routine which reads out the camera such that I can incorporate it in
> my program. There are however a few things that I have some difficulty
> finding out, and I hoped that you could help me. I've looked through
> the documentation supplied with itifg 8.4.0 (which is the version I'm
> using), but this seems rather old, and browsing through the changelog
> is unclear at best.
>
> The things I'm trying to find out are:
>   - What is the normal mode of operation to get a camera to run,
> specifically the (fast) mmap mode? What ioctl calls are needed in what
> order?

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

2. The 'snap' mode
   You are interested in EVERY image you can get. No image should be
   lost. The number of images is limited by the main memory You have.

   same call sequence except:
      no mmap/munmap
      lseek number_of_bytes_to_read SEEK_END
   into the loop:
      only read - it is blockin till a new image is there

When working in grab mode - mmap makes sense, in snap mode - read is
the better solution.

>   - What is the difference between the /dev/ic0??? descriptors? when
> are they used?

There are cfg, acq, dma, exs, lut, iop.

cfg - FPGA download
acq - camera to board acquisition
dma - on-board memory to host memory transfer
exs - trigger/shutter/exposure handling
lut - on-board lookup table handling
iop - on-board i/o ports

For common image acqustion usage, You never use acq directly! You open
dma instead and if acq isn't open at this moment, dma couples acq
internally.

>   - How do I start and stop the framegrabber? The changelog mentions
> lseek() ('ioctls STRT/STOP replaced by one lseek interface'), where
> and how can I use that with itifg?

to start an image acquisition, You have to do

grab mode: lseek +LONG_MAX SEEK_END

snap mode: lseek number_of_images * number_of_bytes_per_image SEEK_END

to stop acqusition, you alwas do

lseek -LONG_MAX SEEK_END

For the grab mode you need some additional calls lseek SEEK_CUR/SEEK_END
to get the offset of the most recent image/to confirm this image

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

>   - Are all camera specific settings in the .cam files or do I need to
> do some things myself? I.e.: do certain cameras require a different
> mode of operation, or is this all the same for all cameras?

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.

> And more specifically:
>   - How do I find out the module that I need to use with
> iti_read_config() (fourth argument)? I currently use 48, but I don't
> know why (this is what itifg_test uses).

There is a function iti_parse_info, that reads /proc/itifg8 and fills
You a 'setup' structure, You can the it from that. Other approach:
You tell me Your board an I tell You the number.

> If I overlooked certain documentation, please tell me. Also, if these
> questions are too general for the itifg driver, let me know. However I
> could not find the answer to these questions (easily). An alternative
> would be to take your test code and cut out the parts I need, but
> that's a rather hacky approach in which case I wouldn't fully
> understand what I would be doing.
>
> Thanks in advance,
>
> Tim van Werkhoven
>

Sorry to be short at some points, the time...

Happy Easter! (I'm back next Tuesday)

                                                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.