Hello. I know the larger A8 Integra parts support 2 video inputs, but I'd only like to consider that as a last resort since the cost of those parts and the layout/thermal issues are so much more involved.
My 2 video sources (image sensors) are identical, Aptina MT9M023, MT9M024, MT9M033, MT9M034 (one of these parts will be selected and I will use two of the same type). They're all identical from an interface standpoint and quite simple:
PIXCLK = 74.25 MHz, 8 data lines (I'm only using high order 8 bits out of 12 available), FV (Frame Valid), LV (Line Valid)
So...it's easy to pick the 6748/L138 for their VPIF and I can support one camera. How to connect the 2nd camera is the trick.
Ideas:
1. Push both camera bytes into the VPIF (it supports 16-bit data), software figures out where lines and frames are. A bit ugly and we're clocking in a lot of unused pixels (dead time at line ends). This also assumes the two cameras are in identical clock for clock sync and that might not turn out to be the case.
2. HPI, not bad, but it seems like I might need a bit of glue logic for the CS, R/W stuff...
3. EMIFA. I'm using the mDDR interface for my bulk memory needs so EMIFA is unused but not designed for peripheral driven source like these image sensors. I could place a FIFO/CPLD or FPGA acting as a FIFO/glue logic, but cost/space.
4. PRU. Good looking peripheral but the math doesn't work, 187.5 MHz (375 MHz DIV 2) trying to sample a 148.5 MHz pulse (half the 74.25 MHz clock). It's a shame it doesn't support some sort of peripheral driven latching, then allow the little RISC to manage the bytes/words...
5. uPP, Universal Parallel Port, ah maybe. The Wiki says:
Mode | Theoretical (MB/s) | Realistic (MB/s) |
1 Ch, 8-bit | 75 | 60 |
Why the 20% loss for "realistic"? Does the DMA not keep up? Typical software not keep up? (poor ISR design?)
The sensors output 1280 active pixel bytes (17.23 us) on each line, then there are 370 dead clock slots (4.98 us) for the horizontal blanking, so the effective rate above the line level is 57.6 MB/s (74.25 * ( ( 1280 / ( 1280 + 370 ) ) ).
I'm assuming the Wiki table is for a 300 MHz part. If I use the 375 MHz part, does it move up to 93.75 MHz theoretical and 75 MHz realistic (using same 80% ratio at 300 MHz)?
For connecting the uPP, I would ignore the FV signal and tie it to a GPIO or INT and let software follow it. Tie LV to ENABLE to qualify the pixel byte latching for only valid pixels within a line.
To me, it looks like the uPP has a decent chance to work. What do you think?
Thanks for the help, Chris