Just wanted to share my current thoughts on this challenge. Note that I don't think I'll really go for the bounty myself since this would be quite a bit of work on the software side too and I have no real interest in that, but the hw interfacing is interesting to me.
Here's a few of the relevant points :
RPi Camera board has no schematics
This part of the RPi is closed. The pinout is known though and we also know the sensor is a OV5647.
The things to notice that aren't clear from the pinout are :
* CAM_GPIO is the "enable" pin. It must be pulled high to enable the onboard voltage regulator. When low, it's all shutdown in a low-power mode
* CAM_CLK is not a clock at all. It controls the red LED on the board, apply 'high' signal to light it up. (current limit resistor is on the camera board already)
* The clock for the sensor is generated on-board and it's 25 MHz
OV5647 sensor
The datasheet for the sensor is in theory under NDA.
But it's easy enough to find a leaked preliminary version : http://www.seeedstudio.com/wiki/images/ ... 7_full.pdf
However the register description is not perfect, some are missing and some are just wrong (for some regs you can actually find two different description in the same PDF ... neither of which seems to match reality). But it's better than nothing.
The code configuring the sensor from the RPi is closed-source AFAICT, and it wouldn't be all that useful anyway because the RPi uses the GPU to manually control exposure / white balance / pixel defect correction / ... and a bunch of other stuff that the camera can do on its own. Thankfully you can find source code for other SoC that use the OV5647 and find some pre-built register set that can be used as a base.
CSI-2 & D-PHY specs are not public
Not really an issue, google finds them without too much issues.
http://electronix.ru/forum/index.php?ac ... t&id=67362
Electrical nterface
The LVDS25 receiver of the Zynq should be able to interpret the HS signal from the sensor, it's within its speicified range, especially when configuring the sensor to its maximum HS output common mode.
Another potential issue is that the 100ohm termination resistor is going to be present all the time and not just when in HS mode, so each LP signal will influence the other (and that's visible on the captures below). One way to fight this a bit is to set the LP drive strength to it's maximum in the sensor configuration. Or possibly not use the internal 100ohm resistor and use an external one of slightly higher value.
Finally the main problem is that the packet start detection and alignement relies on the LP->HS transition ... and the LVDS receiver won't be able to detect that. We may need to use another GPIO and a transistor/mosfet to detect the LP 1->0 transition so that alignement can be performed. The porcupine board will need mods for this.
I2C might also be an issue. The camera board has 18k pulldowns on the I2C lines, so the pullups will need to be strong enough to
drive the line high enough for the Zynq to detect as '1'. That I2C bus was originally designed to work
Sample captures
Here are a few capture looking at the 'P' signal of data lane 0.
* This is a capture of a "Frame Start" packet :
- img_frame_start.png (20.19 KiB) Viewed 49140 times
You can clearly see the influence of the termination resistor on LP-mode. When this signal goes to '0' but the other one is still at '1', this signal isn't going down all the way to 0v but more like 200mv. Then finally when the other signal goes to 0 too, then both are at 0V until the HS drivers are enabled.
* This is a capture of several lines of data when shining a flashlight at the camera.
- img_flashlight.png (34.54 KiB) Viewed 49140 times
You can see the block of data stuck at '1' where the image is saturated.
* This is a zoomed in view of the header of a line of data
- img_data.png (20.24 KiB) Viewed 49140 times
You can see the SoT sequence followed by the data type identifier for 'RAW10'.