Steve Hosgood wrote:
I've written a driver for a USB camera which sends 1600x1200 or 800x600 images across a USB 2.0 bulk pipe. It works fine in 1600x1200 mode, but if switched to 800x600 mode it only gets a couple of frames before it wedges.
I took a look at the USB traffic with a (borrowed) USB analyser. Sadly, I've had to give it back to its owner now, and won't be able to repeat the experiment.
The bulk pipe runs in 512 byte packet mode.
Turns out that 800x600 images don't fit in an integral number of 512
byte packets, and the last packet of every image is sent as 256 bytes
(this seems perfectly legal). However, *that's* what kills linux.
Occasionally it will handle the situation right, but very soon it will
wedge and never poll that endpoint again.
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).
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.
20 FPS should be well within that limitation at 800x600x1, but there may be other constraints that are near the limit. A comparison of the 2610 timing diagrams with the FX2 "Externally Sourced IFCLK" tables might reveal something. A bug in the firmware's programming of the FIFO or GPIF engines might be to blame as well.
The "601 line hack" might be a reasonable solution if you need a longer exposure time than 1/40 sec.
Best regards,
-- 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
