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.

CCS/DLPLCR9000EVM: Upload Images

Part Number: DLPLCR9000EVM

Tool/software: Code Composer Studio

Hello all,

I am currently working with the DMD Lightcrafter 9000. I control the device using python (and USB communication described in the programmers guide) which works (in principle) quite well. To check my code I used batch files genereated by the TI GUI. I could upload an erle encoded image (I just copied the transmitted image data from the GUI). Now I wanted to upload a custom uncompressed image (bit depth = 1). I generated a bmp file (2560x1600) pixels and read them in. I addressed Master and Slave seperatly and started a sequence (1000000 us exposure and 1000000 us darktime in pattern on the fly). Something weird happened:

The DMD displayed the desired pattern just at the upper third of the screen. The image was exactly scaled by the factor 1/3 such that I saw one row with six seperate images. First 3 times the image for the master controller then 3 times the image for the slave controller. To check my code I uploaded the uncompressed image using the GUI. The DMD displayed the image properly. I checked the batch files again and I got really confused because I saw that the device uses 12190 times each the PATMEM_LOAD_DATA_MASTER / PATMEM_LOAD_DATA_Slave command. I used exactly a third +1 command so 4063 and one command. I mean the device has 2560 x 1600 pixels that means that each controller gets 2560 x 1600 / 2 + 48 bytes of data (+48 = +header). Now I know that the buffer can be filled with 504 bytes of image data such that I have to send (2560 x 1600 + 48) / 2 / 504 packets of data (or PATMEM_LOAD_DATA_MASTER / SLAVE commands or 1a2b / 1a2d commands). But (2560 x 1600 + 48) / 2 / 504 = 4063,...and not 12189,...

I don't get the additional two thirds of data. Is there someone who can help me resolving this issue?

Thanks
C

  • Hello Carl,

    I can help with this.  Did you try sending these uncompressed from the GUI and capture the batch file to compare to what you are sending.  Part of the header should tell the system whether the data will be compressed, RLE, or ERLE.  It sounds, like the system is expecting one type and you are sending another.

    I created a batch file for a 1-bit Uncompressed, RLE, and ERLE load.  the file sizes were:

    1. Uncompressed:  60,894 KB   [ 24,387 lines ]
    2. RLE:                             446 KB   [      183 lines ]
    3. ERLE:                             66 KB   [        31 lines ]

    My pattern was very simply a reset block tall white stripe, the rest was all black.  

    I think what is missing is that because the way the controller works, it must always send a 24-bit pattern, which it then parses up depending on the pattern bit depths you have chosen.  Therefore, you have to send  0x00 0x00 0x01 for each bit that in the 1-bit pattern.  

    Next I built a solution with 24 1-bit patterns and sent them uncompressed.  The batch file was only 2 KB larger and only 22 lines longer.  The extra space was the information about the 23 other patterns exposure time, dark time, LED color, and trigger/frame information.

    The file would be the same size if you sent one 8-bit pattern or three 8-bit patterns.

    Fizix

  • Hello Fizix,

    Thank you for your fast answer. That is exaclty what I did. That is why I mentioned this factor of three (I was comparing my file with the batch file). But nevertheless, I think the problem was that I did not send the data in rgb format but directly as a greyscale image (just one byte for each pixel and not three). I tried to expand my data to rgb format and that worked. I just saw a third of my pattern because the controller read in three bytes for each pixel such that two third of information were missing in the end.

    But I have another question concerning the upload:

    Probably the main purpose of the device is not to display greyscale images but is there a way to change the modus from rgb to greyscale? I mean this would increase the upload speed by a factor of three (I would send one byte instead of three to describe every pixel). First, I was a bit confused that one has to send the images in 24 bit rgb format because the example patterns (included in the sofware bundle with the GUI) were also greyscale images (512 kB). So one uploads 512 kB to the GUI and the GUI transmits even more data to the controllers.

    Carl

  • Hello again Carl,

    The DLPC900 is an RGB video controller with very specialized firmware to allow the functionality that can choose to display the data in very different ways, but the internal memory itself is stored in 24-bit blocks.  

    The DLPC410 and DLPC910 are FPGA based and have much lower level control, but require that you build everything yourself.  You must build your own grayscale sequence, etc. . .

    Is there some reason that you do not wish to use compression?  It is true that some patterns compress very poorly, so setting it to Auto is usually the most effective.  Be aware that the compression is completely lossless.  Any pattern with vertical or horizontal patterns will compress very well.  In Pattern On-the-Fly mode what gets loaded into the controller's DDR memory is decompressed.

    Fizix

  • Ah, ok.

    I am using compression but I was wondering if it would be possible to speed it up. But thank you for your immediate response I think my issue is solved.

    Best

    Carl