• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 28 subscribers
  • Views 585 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.

Displaying monochrome images using custom GUI - some implementation queries

Victor Leong
Prodigy 10 points
Other Parts Discussed in Thread: DLPC200, DLPC350

Hello there,

In our application, we are displaying monochrome images one at a time (e.g. display image 1, wait for 10 seconds, then disable the LED, switch to image 2, enable the LED again, wait for 10 seconds....and so on). For application purposes we are only using 1 LED for illumination (e.g. green is enabled, then red and blue are disabled).

Previously, we were using the DLPC200, where the API contains a function for us to directly download images to the external memory on the DLPC200. The customer has now decided to implement the same setup using the DLP LightCrafter 4500 with DLPC350.

I have looked at the GUI v2.0 source code from TI, as well as from Github (https://github.com/jaybo/LightCrafter4500 ), and other threads on this forum, I would like to seek your advice on a few areas:

1) From the user guide, it is possible to download the monochrome images as 1-bit images to the 32MB flash memory, such that each 1-bit image occupy 1 bit-plane in a 24-bit image. I notice that during when creating the 24-bit images in the GUI, the 1-bit images are allocated to individual bitplanes (E.g. B0 - B7, G0 - G7...). Is the LED color control independent of this color bitplane arrangement? That means, can the 1-bit images I stored at B0-B7 and R0-R7 in the 24-bit image be displayed with the green LED only? (as per our application where we only enable the green LED)

2) If the answer to (1) is yes, does this mean the maximum number of 1-bit images I can pack onto the flash memory is 1536? I got this from Rob's reply on this thread (https://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/f/924/p/335981/1174000#1174000), 

3) The GUI v2.0 provides features to (a) create images, (b) add images to firmware and then (c) upload the firmware, which makes use of low level functions in Section 2.2 in the DLPC350 Programmer's Guide (such as Download Data and Erase Sector), as well as functions from "firmware.cpp", which is not documented in the user guide nor the programmer's guide. Is there any workflow or documentation on how to use these (besides the GUI source code), or is this advisable if at all? The reason I ask is because I will like to integrate this image download capability into a custom GUI for our application, but as I am not familiar with firmware control this can be quite daunting and may carry certain risk.

4) If we do not use the flash memory which involves uploading the firmware+images everytime, is there an alternative method that is simpler?  Such as using the HDMI input to stream the video to the DLPC350, where each frame is 24-bits but contains only the image data in the green plane. The HDMI output will come from another device (such as a raspberry Pi or another PC video output that I can perform software control on). Will this be advisable?

Thank you in advance.

Best regards,

Victor  

The reason I ask is because we will like to incorporate these features into our custom GUI we write in LabVIEW.

  • 0
    TI__Mastermind 30875 points

    Hello Victor,

    #1.

    Yes, the LED color control is independed of bitplane arrangement.

    Yes, it is possible to display any bitplane with any user selected color. In short, yes, it is possible all bitplanes with green color.

    #2.

    Actually it depends on how much each 24-bit image can be compressed. Note the GUI tool performs LOSSLESS RLE (Run Length Encoding) compression and the compressed data is what is stored in the Flash. Now the DLPC350 has in-built RLE de-compression logic that will be uncompress before loading into the pattern frame-buffer. So, you can think there is about 30MB of space available on the flash for 24 bit image and then depending upon the image compression we can store that many number of 1-bit images.

    #3

    Yes we are aware of the complexity; unfortunately there is no immediate solution to workaround it.

    The DLPC350 firmware download steps can be found from mainwindow.cpp function void MainWindow::on_FirmwareLoadBut_clicked() function; basically you can follow the API call order in the function LCR_xxx also need to replace the Qt related function (like time delays and waits) with your application delay functions.

    #4

    Yes HDMI is another option; the video source timings must be as per the DLPC350 Video Port timing specifications; yes, for configuration and control you can send commands via I2C and/or USB of the device.

    Regards,
    Sanjeev