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.

DLPC350: Altering DLPC350 firmware for custom processing

Part Number: DLPC350
Other Parts Discussed in Thread: DLP4500

Hi,

I am using the DLP4500 in conjunction with the DLPC350 for a structured light application.  Due to the 48-bit plane limitation in RAM, I am forced to pause the processing when the 48-bit planes have been displayed, load the the next ones, and continue, which of course incurs a delay in the processing.

My question is, is there a way to work around this limitation?
Otherwise is it possible to have the DLP350 firmware source code so that we can implement our own processing to generate patterns on the fly?

Many thanks

  • Hello,

    You are correct about the buffer limitation. Can you provide more information on your application? Many of our structured light users find that 48 patterns well placed can suit many needs. Also, an alternative is to use external streaming mode.

    Best,
    ~Danny W
  • Hi Danny,

    We are essentially using this for a structured light application where we need to display ~200 unique patterns on the DMD. Can I not increase the 48 pattern limit to 64 by compressing my 200 images into several 24-bit bitmaps, uploading these in firmware, and then entering 64 look up table entries to read? Would this run at full speed?
    Of course this still means I have to generate new set of look up table items at the end of the 64 patterns, validate them and restart, which will add time.
    Is there a way to improve this?


    As for external streaming mode, we can do this, however we also want to synchronise this with a camera. Then the problem becomes synchronising the first pattern with the first collected frame of the camera (since in this case the VSYNC is triggering, and we can't to my knowledge stop the VSYNC and then start).
    Have any of your customers used this for similar applications? in particular using HDMI streaming and synchronising with a camera?

    Thanks,
    Oliver.
  • Hello,

    You can investigate the DLPC350 datasheet and the DLPLCR4500 EVM users guide to understand the buffer (see below). The delay comes from reloading the bit-planes from flash to the rotating display buffer.

    You can get creative with the 'external source'.  As long as the data comes to the DLPC350 in a format it expects you can use that mode.

    Have you seen the features present in the DLPLCR6500? It sounds similar to what you are looking for.

    Best,

    ~Danny W

  • Hi Danny,

    Thankyou for your reply. Yes, shortly after sending the e-mail I figured out the rotating buffer thing, but thankyou! Along those line I have a question. I want to display a set of patterns, which I do by creating a set of pattern LUT items and uploading them to the DMD, selecting them to play once. The patterns come from bit-planes of 24-bit images in the flash. This works fine.

    What I now want to do is play this long sequence several times, but still operating them in "Play Once" mode and triggering repeats by issuing a start command over USB. this also works fine but in order to minimise the delay I want to make sure that at the end of the sequence, the first image is loaded back into the back buffer of the DMD. How can I do this? My thought was to insert a final "dummy" pattern at the end of the sequence which loads a single bit-plane from the first image in the flash. Is there a better way?
    I would rather not have the sequence on repeat because then i can't specify how many times I want the pattern to repeat (I don't have access to the trigger in pins).

    Thanks,
    Oliver.
  • Hello Oliver,

    Is this still an active issue for you?

    Best,
    ~Danny W
  • Hi Danny,

    Yes, partially still open.  Please see my questions from the previous post.

    Thanks,

    Oliver.

  • Please see my response below.
  • Hi Oliver,

    On your second question about "Play Once" for restarting pattern sequence are you issuing 'validate command' and then 'start'?

    Regards,

    Sanjeev 

  • Hi Sanjeev,

    Once the pattern has completed playing, I am just issuing another 'start' command.  I only validate at the beginning before the first 'start' command (when I am setting up the pattern LUT items).  My priority is to be able to do a 'start' command, let the pattern play once, then as quickly as possible issue another 'start' command and play again etc.

    Thanks,

    Oliver.

  • Oliver,
    Only Validate command would setup the buffers, start would begin immediately, are you seeing the behavior (controller response) to consecutive start in play once mode is not consistent, is it always taking different time or do you mean it is taking same time but it is too high for your application...
    Regards,
    SAnjeev