Steve Hosgood wrote:
On Wed, 2005-02-09 at 15:57, Mark McClelland wrote:
I just noticed this in one of the Windows driver files (2610.set):
====================
;************* Frame Rate = 40fps
HKR, %2610Vid800RGB24%\FrameRate0, CameraSetting, 1, 11,80,ff
HKR, %2610Vid800RGB24%\FrameRate0, AlternateSetting, 0x10001, 0
HKR, %2610Vid800RGB24%\FrameRate0, FrameRate, 0x10001, 40000
HKR, %2610Vid800RGB24%\FrameRate0, QualityLevel, 0x10001, 1
HKR, %2610Vid800RGB24%\FrameRate0, RawData, 0x10001, 1
HKR, %2610Vid800RGB24%\FrameRate0, RawFrameLength, 0x10001, 480000
HKR, %2610Vid800RGB24%\FrameRate0, OneLine, 0x10001, 1
;@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ; ;HKR, %2610Vid800RGB24%\FrameRate2, CameraSetting, 1, 11,83,ff ;HKR, %2610Vid800RGB24%\FrameRate2, AlternateSetting, 0x10001, 0 ;HKR, %2610Vid800RGB24%\FrameRate2, FrameRate, 0x10001, 15000 ;HKR, %2610Vid800RGB24%\FrameRate2, QualityLevel, 0x10001, 1 ;HKR, %2610Vid800RGB24%\FrameRate2, RawData, 0x10001, 1 ;HKR, %2610Vid800RGB24%\FrameRate2, RawFrameLength, 0x10001, 480256 ;HKR, %2610Vid800RGB24%\FrameRate2, OneLine, 0x10001, 1 ===================
Apparently, OmniVision ran into the same problem, and at one point resorted to increasing the amount of data transferred per frame size by 256 bytes. I'm guessing they did this by bumping the sensor window size to 800x601 (the max window height is 606 according to the datasheet).
Interesting point, but 800x601 would generate 800 bytes more data, not
256. I notice also that they seem to think that the frame-rate in this
mode is 15fps, but the "CameraSetting" of 0x83 to register 0x11 in the
sensor actually runs the sensor at 10fps as far as I know [0x80 is
40fps, 0x81 is 20fps, 0x82 is 13.3fps and 0x83 would be 10fps].
Correct. Looks like they made a cut-and-paste error.
I am suspicious that some of the .set file stuff seems to be dead cruft
left over from editing .set files for completely different cameras!
Your suspicions are correct! It actually turns out to be useful for reverse engineering, because sometimes there's stuff in there for cameras that were never released. It makes figuring out the ones that *were* released a bit easier.
For example, the various picture control registers (0xe9-0xee) mentioned in the .SET files have no function (AFAIK). I presume they tried to implement them, realized that the FX2 can't compute those corrections fast enough, and then did it all in software instead.
BTW, I have a (somewhat out-of-date) list of registers at http://alpha.dyndns.org/ov511/ovfx2_regs.html
Fortunately, running the sensor at 40 FPS also seems to fix the problem, assuming that the FrameRate0 settings above actually work. The FX2, at least with this firmware, is extremely sensitive to the incoming data rate. The FX2 datasheet lists some timing constraints that must be met, otherwise the chip will stop working. If the IFCLK (pixel clock) rate is too high, you will simply get a corrupted frame due to overflow of the internal FIFOs, but if it is too low, the 200ns minimum IFCLK period will be exceeded and the chip will freeze up.
I'm avoiding all that (in theory) by trying to run 1600x1200 at 10fps or
800x600 at 40fps. The data rate in those two modes is identical, both at
the FX2 end and at the USB software in linux.
Unless I'm missing something, it looks like you're actually running it at [EMAIL PROTECTED] FPS. From ovfx2.c:
#define SVGA_SPEED 0x81 /* speed: 0x80 = 40fps, 0x81 = 20fps, 0x82 = 13.3fps, 0x83 = 10fps ( >= 0x84 doesn't work) */
-- Mark McClelland [EMAIL PROTECTED]
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
