Talk:Circbuf - Revision history

Andrey.filippov at 19:06, 12 November 2007

2007-11-12T19:06:42Z

← Older revision		Revision as of 19:06, 12 November 2007
Line 124:		Line 124:

	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. --[[User:Ekratzer\|Ekratzer]] 12:53, 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. --[[User:Ekratzer\|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--[[User:Andrey.filippov\|Andrey.filippov]] 13:06, 12 November 2007 (CST)

Ekratzer at 18:58, 12 November 2007

2007-11-12T18:58:11Z

← Older revision		Revision as of 18:58, 12 November 2007
Line 123:		Line 123:


	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 ms 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. --[[User:Ekratzer\|Ekratzer]] 12:53, 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. --[[User:Ekratzer\|Ekratzer]] 12:53, 12 November 2007 (CST)

Ekratzer at 18:53, 12 November 2007

2007-11-12T18:53:42Z

← Older revision		Revision as of 18:53, 12 November 2007
Line 121:		Line 121:

	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.--[[User:Andrey.filippov\|Andrey.filippov]] 12:31, 12 November 2007 (CST)		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.--[[User:Andrey.filippov\|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 ms 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. --[[User:Ekratzer\|Ekratzer]] 12:53, 12 November 2007 (CST)

Andrey.filippov at 18:31, 12 November 2007

2007-11-12T18:31:54Z

← Older revision		Revision as of 18:31, 12 November 2007
Line 119:		Line 119:

	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.		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.--[[User:Andrey.filippov\|Andrey.filippov]] 12:31, 12 November 2007 (CST)

Andrey.filippov at 18:30, 12 November 2007

2007-11-12T18:30:04Z

← Older revision		Revision as of 18:30, 12 November 2007
Line 117:		Line 117:

	--[[User:Ekratzer\|Ekratzer]] 10:27, 12 November 2007 (CST)		--[[User:Ekratzer\|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.

Ekratzer at 16:27, 12 November 2007

2007-11-12T16:27:49Z

← Older revision		Revision as of 16:27, 12 November 2007
Line 81:		Line 81:

	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.--[[User:Andrey.filippov\|Andrey.filippov]] 10:16, 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.--[[User:Andrey.filippov\|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?

			--[[User:Ekratzer\|Ekratzer]] 10:27, 12 November 2007 (CST)

Andrey.filippov at 16:16, 12 November 2007

2007-11-12T16:16:30Z

← Older revision		Revision as of 16:16, 12 November 2007
Line 79:		Line 79:

	--[[User:Ekratzer\|Ekratzer]] 09:41, 12 November 2007 (CST)		--[[User:Ekratzer\|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.--[[User:Andrey.filippov\|Andrey.filippov]] 10:16, 12 November 2007 (CST)

Ekratzer at 15:46, 12 November 2007

2007-11-12T15:46:40Z

← Older revision		Revision as of 15:46, 12 November 2007
Line 28:		Line 28:

	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.		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.		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		// initialize driver

Ekratzer at 15:46, 12 November 2007

2007-11-12T15:46:05Z

← Older revision		Revision as of 15:46, 12 November 2007
Line 29:		Line 29:
	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.		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.		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.

	~~<verbatim>~~

	// initialize driver		// initialize driver
Line 40:		Line 38:
	if (fd != -1) {		if (fd != -1) {

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

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

	// set parameters, not sure if all (or any) of these are required for minumum		// 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_BAYER), 4);
	ioctl(fd, _CCCMD(CCAM_WPARS, P_FPSLM), -1);		ioctl(fd, _CCCMD(CCAM_WPARS, P_FPSLM), -1);
	tmp = ioctl(fd, _CCCMD( CCAM_RPARS , P_TRIG), 0) & ~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_TRIG ), tmp);
	ioctl(fd, _CCCMD(CCAM_WPARS , P_UPDATE ), 1);		ioctl(fd, _CCCMD(CCAM_WPARS , P_UPDATE ), 1);

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

	// start compression now		// start compression now
	fd = open("/dev/ccam_dma.raw", O_RDWR);		fd = open("/dev/ccam_dma.raw", O_RDWR);
	if (fd != -1) {		if (fd != -1) {
	ioctl (fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_CATCHUP);		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_FORGET);
	ioctl (fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_GET);		ioctl (fd, _IO(CMOSCAM_IOCTYPE, IO_CCAM_JPEG ), JPEG_CMD_GET);
	while (lseek(fd,0,2)==0);		while (lseek(fd,0,2)==0);
	close(fd);		close(fd);
	}		}

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

Ekratzer at 15:43, 12 November 2007

2007-11-12T15:43:08Z

← Older revision		Revision as of 15:43, 12 November 2007
Line 29:		Line 29:
	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.		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.		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.

			<verbatim>

	// initialize driver		// initialize driver
Line 75:		Line 77:
	}		}
	}		}

			</verbatim>

	--[[User:Ekratzer\|Ekratzer]] 09:41, 12 November 2007 (CST)		--[[User:Ekratzer\|Ekratzer]] 09:41, 12 November 2007 (CST)