This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to connect 2 image sensors to a 6748 or L138?

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

  • Any TI Employee thoughts on this one?  Does the 375 MHz L138 parallel port have a decent chance of clocking in a 75 MHz 8-bit source?  Thanks, Chris

  • I'd like to order an eval board fast but want to make sure the pin muxing can actually support my usage of the VPIF 8-bit input mode and the uPP 8-bit input mode (one image sensor on each peripheral).

    By my reading of the DS and viewing the pin mux tool, I think we have to let VPIF dominate and take control of pins for VPIF_DIN0-7, VPIF_VS, VPIF_HS which eliminates uPP usage of DATA[15:0] and we're left with only XDATA[0..15] for uPP.

    Referring to page 14 in the uPP User's Guide, it appears that I CAN'T have my 8-bit data come in on XDATA[7:0] which would be the logical path.  Is this correct?

    It appears the best I can do is to bring my 8-bit data in through XDATA[15:8] as part of 16-bit channel A or B usage (arbitrary choice of A/B I think).  My concern here would be that I need to DMA 16-bit data elements then have the DMA or software (yuk) extract my 8-bit data and rebuild it somewhere in mSDRAM.  Or, can I do some sort of 2D or other DMA transfer to handle this?  For XDATA[7:0], will the inputs be pulled/set to some fixed level internally so they don't float since the pin defs will be assigning them to VPIF?

    In summary, if I let uPP use XDATA[15:8], should the VPIF 8-bit input be able to run at the same time as the uPP 8-bit input?

    Thanks, Chris

  • Chris,

    Sorry for my delay in responding.  Here are some answers:

    Why the 20% loss for "realistic"?  Does the DMA not keep up? Typical software not keep up? (poor ISR design?)

    The DMA should certainly be able to keep up with the maximum theoretical throughput; the application software is a bigger concern here.  Depending on your buffer/window size, the CPU overhead associated with maintaining uPP transfers can be significant at high speeds.  For example, if you use a window of 64 bytes in 8-bit mode at 75 MHz, you will need to service an interrupt every 0.85 us to maintain 100% throughput.  You can alleviate this somewhat by using larger buffers (ex. 1024 -> 13.7 us).

    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)?

    Unfortunately, no; uPP is only designed to reach a maximum clock speed of 75 MHz regardless of the CPU speed.

    Referring to page 14 in the uPP User's Guide, it appears that I CAN'T have my 8-bit data come in on XDATA[7:0] which would be the logical path.  Is this correct?

    That's correct.  In one-channel mode, uPP always uses the DATA pins.  It cannot be configured to use XDATA instead.

    In summary, if I let uPP use XDATA[15:8], should the VPIF 8-bit input be able to run at the same time as the uPP 8-bit input?

    There is no "good" way to use uPP and VPIF (in input mode) at the same time.  Attempting to use uPP while some of its used pins (in this case, DATA[15:0]) are muxed and in use by other peripherals is not recommended.  Even if the transfer does go through, there will be considerable overhead in manipulating the data buffer to get just the data from the XDATA pins.  The uPP internal DMA is not flexible enough to do this for you, but maybe you could use the chip's EDMA to extract just the bytes that you want.

    Hope this helps.

  • Good answers.  A lightbulb just went off and it hit me that I might be able to have both 8-bit sources push their data into the uPP and not use the VPIF at all.  It's a bit counterintuitive since the VPIF was meant for video and a bit of a shame to not use it at all, but I think it might make sense.

    Here's my proposal:

    - uPP Channel A input connected to 8-bit 75 MHz peripheral #1

    - uPP Channel B input connected to 8-bit 75 MHz peripheral #2

    - run both in Single Data Rate mode

    Does this have a good chance of working?  Items to watch out for?  Thanks, Chris

  • Chris,

    That should be a perfectly valid configuration.  The biggest concern is simply keeping up (CPU/application-wise) with two channels operating at a full 75 MHz.

    One thing to keep in mind is that the uPP clock signal is transmitter-driven.  This means that you will need to provide an externally-generated 75 MHz clock source to both of the uPP CLOCK pins.