Difference between revisions of "Talk:Circbuf"

Latest revision as of 11:06, 12 November 2007

I have a question regarding the 353 compressor initialization. The imgsrvd program does not work after bootup because the driver has not initialized the FPGA, and not started the compressor running. The only way I can get it to work is to run ccam (via http) first. Is there a way to automatically (upon bootup) initialize both the FPGA and start the compressor running?

I have tried a few things:

I have found that just opening "/dev/ccam_img" causes the init_FPGA() to be called, so one problem solved.

However, after I open "/dev/sensorpars" and call JPEG_CMD_START and nothing happens? How do we start/stop the compressor now ?

I am using 7.1.5 from sourceforge.

--Ekratzer 14:57, 9 November 2007 (CST)

You can just put : wget http://127.0.0.1/admin-bin/ccam.cgi?parameter1=value1&parameter2=value2&... into some init.d script.

We are now designing a some PHP API and Luxigo work on a C/C++ library / API. (now it's only acquisition no programming CMOS)

Or just look in the ccam.cgi source code. (I never did)

--Polto 23:35, 9 November 2007 (GMT)

Yep, you are right - nothing is done for that yet. So while testing I did the same - opened first image with ccam.cgi (even complete camvc.html), then started compressor with "http://camera_ip:81/compressor.php?cmd=run" and only then used imgsrv to access circbuf.

Using ccam.cgi from localhost is a solution, we used it in ftp script in our webcams, but eventually there will be a better solution. You may also try to specify the ccam.cgi parameters from PHP script - similar to Adjusting_sensor_clock_phase--Andrey.filippov 14:06, 10 November 2007 (CST)

I have searched through ccam.c and found necessary code to start compressor after bootup. Some of it may not be necessary, but it works for now. If I change sensor parameters (WOI, exposure, quality, etc.) I must stop the compressor first, and then call this code again, or user-space will lock-up (sorry about the indenting problem...)

   // initialize driver
   fd = open("/dev/ccam_dma.raw", O_RDWR);
   if (fd != -1)
       close(fd);

   fd = open("/dev/ccam_img", O_RDWR);
   if (fd != -1) {

   // do we need to start the compressor going ?
   tmp = ioctl(fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_MONITOR_SEQ ), 0);
   if (tmp != CAMSEQ_RUN) {

   // force update
   ioctl(fd, _CCCMD(CCAM_WPARS ,  P_DONTCARE),  0);
   ioctl(fd, _CCCMD(CCAM_WPARS ,  P_DONTCARE),  1);

   // set parameters, not sure if all (or any) of these are required for minumum
   ioctl(fd, _CCCMD(CCAM_WPARS ,  P_BAYER),   4);
   ioctl(fd, _CCCMD(CCAM_WPARS, P_FPSLM), -1);
   tmp = ioctl(fd, _CCCMD( CCAM_RPARS , P_TRIG), 0) & ~1;
   ioctl(fd, _CCCMD(CCAM_WPARS , P_TRIG ),   tmp);
   ioctl(fd, _CCCMD(CCAM_WPARS , P_UPDATE ),   1);

   // reset pointers and DMA for new clip
   ioctl (fd,_IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_RESET);
   close(fd);

   // start compression now
   fd = open("/dev/ccam_dma.raw", O_RDWR);
   if (fd != -1) {
   ioctl (fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_CATCHUP);
   ioctl (fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_FORGET);
   ioctl (fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_GET);
   while (lseek(fd,0,2)==0);
   close(fd);
   }

   // start compressor
   fd = open("/dev/sensorpars", O_RDWR);
   if (fd != -1) {
   lseek(fd, CSERV_SPARS_START, SEEK_END);
   close(fd);
   }
   }
   }

</verbatim>

--Ekratzer 09:41, 12 November 2007 (CST)

Yes, it is possible but I would still recommend to use file R/W (like in the links above that I posted), not the IOCTL.--Andrey.filippov 10:16, 12 November 2007 (CST)

I need to use ioctl's for an application because I have written a light-weight acquisition server that allows sensor configuration and acquisition over the same TCP/IP interface. It tries to guarantee that no frames can be lost by using an acquisition thread on SCHED_FIFO scheduler, and a condition-copy, scatter-gather queueing mechanism that buffers meta-data about an image. The buffering is important to deal with blocking I/O (TCP, disk, flash, etc) in our minimal logging system. It buffers the following data about an image:

   -first 64 configuration registers at time of acquisition
   -histogram
   -jpeg header (zero-copy)
   -jpeg bitstream (zero-copy)

I will fold the source code into the tree very soon.

Missing Frames ??

I am experiencing an acquisition problem. There appears to be some missing frames. For example, FP100S says 14.41 fps, but I can only capture 13.1. Similarly, with exposure set to 500 and FP100S reading 20.00 fps, I can only capture 17 fps. The method I am using is below, the CPU load is less than 1%.

   lseek(fd, CIRCLSEEK_LAST, SEEK_END);

   while(acquire) {

       // image not ready
       if (lseek(cfd, CIRCLSEEK_READY, SEEK_END) < 0) {

           // wait for image
           jpeg_wp = lseek(fd, CIRCLSEEK_WAIT, SEEK_END);
       }

       // we have valid image at jpeg_wp now (verified)
       ...

       // move to next image
       lseek(fd, CIRCLSEEK_NEXT, SEEK_END);
   }

Has anybody experienced this problem?

--Ekratzer 10:27, 12 November 2007 (CST)

First of all you can troubleshoot the problem with imgsrv, using /meta and /pointers and watching timestamps (you may also extract time stamps from Exif data in the images. So is the lower frame rate because of the frame drops or because it is reported wrong. If the frames are really dropped - where did it happen - on the FPGA->circbuf, or from circbuf to your application.

There was a problem in circbuf (fixed 7.1.5) that it could not read frames that were already ready - that was an ETRAX cache coherency bug. Other than that I did not notice problems with circbuf operation yet.--Andrey.filippov 12:31, 12 November 2007 (CST)

I have looked at circbuf image timestamps for several minutes of capture. When FP100S reads 14.41, the image timestamp are either 0.077 or 0.076 seconds apart (average of 0.0765 is 13.089 Hz.) There are no missing frames at all. It appears that the compressor is not running at the correct frequency. This is the same for all frequencies I have tested: the compressor runs a few FPS lower than what FPS100S reads. --Ekratzer 12:53, 12 November 2007 (CST)

There could be some bugs in either calculation of the frame period (rather complicated on the sensor side, there could be some bugs in the sensor itself) or programming the right period.... The frame time stamps are reliable--Andrey.filippov 13:06, 12 November 2007 (CST)