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.

DLPC900: DLPC900 RGB data continuity

Part Number: DLPC900

I am trying to avoid a frame buffer and use a USB3 to RGB conversion IC (Cypress FX3) for direct input to the RGB pins of the DLPC900. The FX3 IC would generate the PCLK, HSYNC, VSYNC etc.

The on-board buffering of that FX3 IC could buffer only one or two rows of DMD pixels data.

If I can guarantee the PCLK/HSYNC/VSYNC timings for at least one row of pixels will the DLPC900 work correctly?

Another way to think of it: if I were to add a variable delay to HSYNC after one row has completed and before starting the next row, WHILE keeping the PCLK continuous, will that cause issues with the DLPC900?

Subsequent question: what if I can only buffer a subset of a single row in which case I would effectively have to clock-stretch while transmitting data to the DLPC900, would the DLPC900 be OK with this?

Thanks.

  • Hi Andrew,

    Thank you for your detailed question.

    I have asked our applications and systems leads to look into this configuration you put forth. New configurations like this take time for us to review. Should have feedback for you soon.

    Thank you,

    Matt

  • Andrew,

    As long as the chip can generate a continuous stream coming into the receiver the DLPC900 should not have an issue.

    If you are suggesting only sending one or two rows and stopping to generate more data and then send again, I do not know if that will work.

    I am consulting with the video team on this, but I suspect that since v-sync is related to the frame rate, that there could be an issue.

    It may be as late as Monday before I can get an update to you.

    Fizix

  • Andrew,

    I spoke with some of our video guys on this and they are of the opinion that without a continuous v-sync the system will likely not work correctly.

    This is not a typical scenario.  If you were able to buffer two rows worth of RGB data and have one row sending while loading the next row, that might work.  

    Actually, as long as the data stream looks continuous from the RGB input lines, you might be able to employ a smaller ping-pong buffer.