0
\$\begingroup\$

I need to process image data from 10 image sensors simultaneously (namely from OnSemi MT9V022s or similar). All 10 sensors will be externally triggered by a common signal. Ideal solution would be to do the processing on some high-level CPU like ARMv7/8 or x86 but I dont know how to connect all the cameras to the CPU. I would like to avoid using USB for the connection since I dont need the USB stack for anything (maybe except transfer speed).

The image sensors have either serial or parallel output. Since there may not be 10 similar data input types on a given CPU, is the only way to multiplex the image data to fewer (or single) streams? If so, how could such multiplexing be done? Are there some ICs that could be used for that or do I have to design a custom FPGA? As I see it, may I need to develop a custom "multiplexer" device that would input all 10 sensors and join them to a common output?

Given I would like at least 10 x 320x240 8-bit grayscale at 10-30 FPS what are the IO options for the common output (SPI, USB etc.)? Can I use a CSI interface for the common output and write a driver that would do the de-multiplexing? Or can I just multiplex the sensors for transfer and then de-multiplex them in CPU and use a Linux image sensor driver? A target CPU would be ideally a strong multicore ARM with OpenCL support - maybe something like nVidia Tegra K1 or X1.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ While i think you coukd probably multiplex all cameras to a single camera interface on the processor (lvds multiplexer if the cameras use lvds) I think a better solution is to use an FPGA for this job. FPGA coupled to some memory can easily (and if required even simultaneously) acquire images from the cameras and then pass them onto the application processor (Linux) any way you wish. \$\endgroup\$
    – IgorEE
    Commented Apr 6, 2016 at 11:08
  • 1
    \$\begingroup\$ 10*320*240*8bit*30/s = 23Mbps. Not a huge bandwidth, but still large enough to be significant. I'd agree with Igor, an FPGA coupled to some memory is the best way to interface this, it will move the processing load away from the processor, and can interface very flexibly. Because of the relatively slow speeds and low bandwidth, your RAM and FPGA needn't be expensive or super fast. \$\endgroup\$
    – uint128_t
    Commented Apr 6, 2016 at 15:03

1 Answer 1

Reset to default
2
\$\begingroup\$

This seems like a perfect application for a "SoC" FPGA like a Xilinx Zynq or Altera Cyclone V SoC. These parts combine a dual-core ARM CPU core with FPGA fabric on the same package, with high-speed interconnect in between. You could instantiate whatever glue logic required in the FPGA half (SPI interfaces, LVDS, etc.), and then use one of the various AXI interconnects to pipe that data into the CPU domain, for streaming over network or similar. Of course, since you have a FPGA, you can see how "nice" the tools from Xilinx/Altera have gotten in terms of implementing an OpenCL pipeline. Additionally, depending on data throughput, you can implement framebuffer memory and connect to the FPGA if the built-in DDR is not enough.

Designing a board with this level of part on it is not the easiest, but luckily, there are many vendors who build SoMs (system-on-module) that implement the "core" hardware like the chip, DDR, etc. You can "simply" build a carrier card / board for a given SoM that acts as your camera / sensor interface board. This will let you worry less about the burdens of high-speed layout / high-complexity design and focus on your portion of the design.

\$\endgroup\$

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.