0
\$\begingroup\$

I need to create a circuit that will have many cameras. Possibly the OVM7692. I will connect this array to my host processor via DVP.

The cameras are controlled via SCCB which seems to be a name that Omnivision gave to I2C. They will act as slave devices while the master (host processor) issue the commands (no problem here so far).

Now, to my question:

is it possible to interface a bus of DVP lines from all cameras (connect all outputs in parallel with each other) so I don't have to use one processor per camera? The idea is that only one camera will be used at a time. So control-wise: camera 1 to 6 are off and camera 7 takes a picture.

According to what I have seen on the image sensor datasheets, pins are in high-z while the device is set to low power mode.

However, I think adding some series resistances (22 to 51ohm) will be good in order to prevent an odd timing event and avoid a short.

Also, what about clock lines? will it be better to put some kind of buffer such as a NOT gate in between?

Thank you

\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

is it possible to interface a bus of DVP lines from all cameras (connect all outputs in parallel with each other) so I don't have to use one processor per camera?

Probably, yes, but it's probably way harder than you think: even if the resolution and precision of these frames coming out of the camera module are crappy, these are still relatively high-speed signals. You'd need to power-combine them with good matching and high isolation between the cameras.

Also, what about clock lines? will it be better to put some kind of buffer such as a NOT gate in between?

And then you'll have to compensate the skew of your NOT gate? Um, good luck. Hope your host processor's DVP interface has adjustable delays... It probably has, but quite possibly not in the range you'd need it.

All in all:

It's not worth it; it's harder than having a single chip with many receivers, one for each lane of each DVP port, and then doing the muxing in digital logic.

Honestly, go for MIPI CSI (that camera supports it), and get an FPGA with sufficient SERDESes. You need two differential SERDESes per camera. Otherwise, you'd need 8 single-ended ones, and the routing of that alone will be challenging, to say the least!

Re: Host processor: you probably have an FPGA there, anyway, right? Aside from smartphone SoCs, and maybe a few very specific DSP cores, video interfaces (especially, video interfaces like DVP, which are almost forgotten today) aren't that common. DVP is especially problematic, because it's self-clocked, and fairly high rate. Sounds like a pretty terrible bus to interface with software alone.

Also, note, that you'll need much more than the publicly available product brief to actually interface with the camera. Ask the supplier now for complete documentation. You really can't simultaneously try to reverse-engineer the control messages, the data format of the video interface, the physical format of the DVP interface (these are not as tightly standardized as say, USB, there's no "plug and play" there)...

\$\endgroup\$
5
  • \$\begingroup\$ Thanks for your thorough answer. Could you please recommend me a suitable processor? The one I was planning to select was the SiPEED M1. I am used to working with MCUs but quite new to these different kinds of devices. \$\endgroup\$
    – RWeiser
    Apr 20, 2020 at 13:48
  • \$\begingroup\$ @RWeiser ah, interesting! That actually comes with a DVP interface, so, yes, sounds like a viable choice! \$\endgroup\$ Apr 20, 2020 at 14:13
  • \$\begingroup\$ It does, but I still have the problems you mentioned about interfacing them in parallel? \$\endgroup\$
    – RWeiser
    Apr 20, 2020 at 14:15
  • \$\begingroup\$ I honestly don't know what the data protocol of DVP looks like in detail. \$\endgroup\$ Apr 20, 2020 at 14:46
  • 2
    \$\begingroup\$ OK if I prototype it I'll come back to you with either my disaster or successful implementation \$\endgroup\$
    – RWeiser
    Apr 21, 2020 at 2:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.