• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 97 subscribers
  • Views 400 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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 8-bit BT656 output camera module with AM3715?

David Hoadley
Prodigy 20 points
Other Parts Discussed in Thread: TVP5158, AM3517, TVP5150

Hello

I too have basically the same question as yang zaiqi - ultimately I am trying to
 interface a TVP5158 in 8-bit BT-656 mode to the AM3517. But as a first step, I
trying with a TVP5150, and then I hope to try the TVP5158 in single-camera mode
(no interleaved channels).

As I understand it, the VPFE is supposed to recognise the SAV and EAV codes in
the BT656 data stream, and from them generate horizontal line sync and vertical
blanking signals. These then generate the interrupts VDINT0 and VDINT1. The code
to set this up is found in driver dm644x_ccdc.c. (I am working with Linux kernel
2.6.37)

Am I right so far?

Our 8-bit data is being fed to the AM3517 on data lines CAM_D[7:0]. Can this
ever work, or must we feed the data in on lines CAM_D[9:2]?

Table 6-4 on page 1087 of SPRUGN4Q (AM/DM37x Multimedia Device Technical Reference Manual)
and table 10-4 on page 1134 of SPRUGR0B (AM35x ARM Microprocessor Technical Reference Manual)
both show the SAV and EAV patterns in BT.656 10-bit form, not 8-bit form. Does
this mean that the patterns are only recognised if they appear on CAM_D[9:2]?

Can we shift the bits, if we have fed them into CAM_D[7:0]? I noticed the other
comments here about register ISP_CTRL[7:6]:SHIFT and ISP_CTRL[3:2]: PAR_BRIGE,
but manual SPRUGR0b doesn't mention it. Does it exist on AM3517? In any case, it
looks like it shifts bits right, but not left. Is this correct?

A bit more info - our symptoms are that we never get interrupts VDINT0 or VDINT1
(well, what I see is that vpfe_isr (from vpfe_capture.c) is never called, and
neither is vdint1_isr). I believe that these ISRs are set up, because during
boot-up, I do see the message
    vpfe-capture vpfe-capture: v4l2 device registered
which suggests that vpfe_probe() runs OK.

When I run my test application, I also see
    dm644x_ccdc dm644x_ccdc: Starting ccdc_config_ycbcr...
    dm644x_ccdc dm644x_ccdc: Starting ccdc_setwin...
    dm644x_ccdc dm644x_ccdc: End of ccdc_setwin...
    dm644x_ccdc dm644x_ccdc: End of ccdc_config_ycbcr...
so I believe the interrupts are being set up OK. But they never arrive.

This is what makes me concerned that the VPFE does not recognise the SAV and EAV
codes unless they arrive on lines CAM_D[9:2].

Any help would be greatly appreciated. Thanks,
David



  • 0
    Prodigy 20 points

    This problem is now solved, and the answers to the questions (for anyone else that might be struggling with this) are:

    8-bit BT.656 video does work when connected to the CCDC_DATA[7:0] pins. It is not necessary to connect them to CCDC_DATA[9:2] (even though Table 10-4 of the TRM seems to imply that it is).

    10-bit BT-656 also works when connected to CCDC_DATA[9:0] pins.

    The PAR_BRIDGE and SHIFT are not relevant here. They are not available on AM3517.

    The problems turned out to relate to the hardware timing of the camera signals, which were fixed by an improved layout of the makeshift test rig we are using.

    Regards,

    David