• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 100 subscribers
  • Views 447 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.

Generating BT.656 graphics data on AM3703 processor - disabling fp, bp and sync

Alex Dunfield
Prodigy 100 points
Other Parts Discussed in Thread: AM3703

Hi,

We are using an AM3703 processor to generate BT.656 graphics data which we are streaming to an LCD driver chip.

We are using an 8 bit parallel bus with a 27MHz clock, and would like to remove the front porch, back porch, and sync which appear to be automatically inserted by the hardware.  The timings are configured with the following command:

echo "27000,1704/4/4/4,522/1/1/1" > /sys/devices/platform/omapdss/display0/timings

This seems close to the minimum allowed lengths of hfp, hbp, etc

Is there any way to disable these timing signals?

Thanks

 

  • 0
    TI__Mastermind 41665 points

    Alex Dunfield said:
    Is there any way to disable these timing signals?

    Unfortunately I do not believe there is a way to remove these timing signals, the AM3703 was not designed with BT.656 display as a requirement and thus there does not appear to be a way to get a perfect BT.656 compliant stream out of the device. You could use the 8 bit bus like you describe with some extra software inserting the SAV/EAV sync codes to make a 'BT.656 like' stream, however it will always have small holes somewhere in the blanking to accomodate the H/V sync periods that the port was designed to be outputting.

    The real question would be if your LCD driver chip can accept there being small gaps during the blanking period, if it cannot deal with there being some null data during blanking than it is unlikely the AM37xx will be able to output a suitable stream for it.

  • 0 in reply to Bernie Thompson TI
    Prodigy 100 points

    Hi,

    When the sync pulses occur, what happens to the data on the parallel bus?  Our observation is that the software continues to output the most recent byte of data until the sync pulse is complete.  I.e. if the byte is 0xFF when the pulse occurs, the state of the data bus remains at 0xFF until the sync pulse is complete.  Similarly, if the output is 0x00, the parallel bus remains low.

    Our plan is to modify the last byte in the video stream before HSYNC, VSYNC, HFP or HBP pixels to be 0x80, so the display system will hold the output lines at 0x80.  This way, the data during the sync pulses will not be interpreted by the LCD driver IC as BT.656 special characters.  Is this likely to be effective?

  • 0 in reply to Alex Dunfield
    TI__Mastermind 41665 points

    Alex Dunfield said:
    When the sync pulses occur, what happens to the data on the parallel bus?  Our observation is that the software continues to output the most recent byte of data until the sync pulse is complete.  I.e. if the byte is 0xFF when the pulse occurs, the state of the data bus remains at 0xFF until the sync pulse is complete.  Similarly, if the output is 0x00, the parallel bus remains low.

    I don't believe this is a well defined characteristic, from the timing diagrams in the TRM it appears that the data during the sync pulses is undefined, so I could not guarantee that it will always output the last data on the bus, though it is possible that it will.

    Alex Dunfield said:
    Our plan is to modify the last byte in the video stream before HSYNC, VSYNC, HFP or HBP pixels to be 0x80, so the display system will hold the output lines at 0x80.  This way, the data during the sync pulses will not be interpreted by the LCD driver IC as BT.656 special characters.  Is this likely to be effective?

    If the output lines do hold all the time than this seems like it could be effective. In any case I would ensure that the final values you send out are not 0x00 or 0xFF to avoid triggering an inadvertent EAV/SAV code even if the sync period data does vary.

    This does still assume that the LCD driver IC has no dependency on the blanking data being a perfect 0x10 0x80 stream (since you would end up with multiple 0x80 values), and that it only triggers on the EAV/SAV codes. With most devices you can get by with 'BT.656 like' streams as long as you only have the 0xFF 0x00 0x00 values during a SAV/EAV codes, but not all devices are as forgiving so you would want to verify with your LCD driver vendor.