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.

DLPDLCR2000EVM: Raspberry Pi access to the DLPDLCR2000EVM

Part Number: DLPDLCR2000EVM
Other Parts Discussed in Thread: DLP2000, DLPC2607,

Dear Forum,

Ia am having a harrd time getting a response when accessing the DLP2000 evm from my Rpi3, "Raspberry Pi". Ihave used I2cset and I2cget to interact with the EVM.

I2cdetect identifies the 0x1b for the 2607 and 0x57 for the EEprom. Reading from any of the preset registers returns 00 in all cases. Have tried to activate any of the test images, using reg 0x11 for test pattern generation, with no result, my commands were:

i2cset -y 1 0x1b 0x11 0x3 i   # This should show a green screen 

No change!!1

Has anybody been succesful with using an Rpi3 with the eval module?

Thanks for your assistance

regards

Samir Lehaff

  • Samir,

    Keep in mind that registers in the DLPC2607 are 32-bits wide. Hence you must write to them with zero padding. In my experience failing to do so causes the I2C transaction to fail.

    For instance I would write 0x00 0x00 0x00 0x03 instead of 0x3. Let me know if this helps

    Best Regards,
    Philippe Dollo
  • Philippe,
    Thanks for the suggestion, it did raise my hopes, the outcome was still the same, cannot affect the evm in any way!
    I have downloaded the 2607 GUI interface, will have to wait for a usb to i2c plug, looking at the commands that the GUi issues, they do look similar to the ones that I composed based on hte programmer's guide.
    I will welcome any addditional suggestions.
    Best regards
    Samir
  • With that approach you will be able to interface with the EVM without the use of the BeagleBone Black. Also, you are correct that the I2C commands issued by the GUI interface are the same as those issued using the BeagleBone's I2C bus.

    As an alternative to i2cset/i2cget, you can also employ the python library that helps facilitate some of the communication between the BeagleBone Black and the DLPDLCR2000EVM. In particular, I am referring to the "/opt/scripts/device/bone/capes/DLPDLCR2000" directory in the BeagleBone Black's disk.

    I am glad that, using either of these solutions, you have a means to reliably read data from the system. In the meanwhile, I will see if I can reproduce your issue and better document it for other users.

    Best Regards,
    Philippe Dollo
  • Philippe,

    I have been looking for the above mentioned python code, could you point me to a link where I can access the python scripts that you refer to.

    Thanks in advance,

    Samir

  • Samir,

    Now that you mention it, I forgot to mention that these scripts are supplied in with the BeagleBone Black disto featuring DLPDLCR2000EVM support.

    If you do not have the BeagleBone setup on hand, I can provide the scripts here for you to download. It may actually be convenient for other Raspberry Pi users who do not have access to a BeagleBone as well.
  • Please see the attached software below. Note that the software exists under an open-source license.

    /cfs-file/__key/communityserver-discussions-components-files/94/7776.nhd_5F00_python_5F00_demo.zip

    /cfs-file/__key/communityserver-discussions-components-files/94/2402.README.txt

    I hope this helps.

    Best Regards,
    Philippe Dollo

  • Thanks Philippe, will work on it first thing tomorrow.
    Will give you feed back such that others may benefit from it.

    Regards
    Samir
  • The python package link is exactly what I needed, it will take me a couple of days to adjust it to my application and environement. It is a nice and complete interface to the 2607 that makes a sound basis for driving the DMD.
    I will keep you posted with my progress.
    Best Regards
    Samir
  • I have installed the dlp_lightcrafter-1.0.19 on my Rpii3, changing the I2c bus address from 2 to 1, allowed me to test the 2607 I2c control interface successfully.
    Remainding task is to wire the paralell video bus to verify that part.

    Regards
    Samir
  • As DPI on RPI disables both hardware I2C busses you need to use 18Bit RGB output for DPI and add in your /boot/config.txt following line to add a software I2C, which uses GPIO23/24 by default:

    Name:   i2c-gpio
    Info:   Adds support for software i2c controller on gpio pins
    Load:   dtoverlay=i2c-gpio,<param>=<val>
    Params: i2c_gpio_sda            GPIO used for I2C data (default "23")
    
            i2c_gpio_scl            GPIO used for I2C clock (default "24")
    
            i2c_gpio_delay_us       Clock delay in microseconds
                                    (default "2" = ~100kHz)

    Which gives you then:

    pi@raspberrypi:~ $ i2cdetect -r -y 3

         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

    00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 

    10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- -- 

    20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

    30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

    40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

    50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- 

    60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

    70: -- -- -- -- -- -- -- --                         

    Remember to use pullups on those GPIO pins then...

  • Hmm...picture looks weird....especially that the white text is not evenly white over the screen...

    BTW: Which of those BBB lcd_data lines correspond to red/green/white ?

  • Well done Richard, looks like it's working, i better get busy getting my installation working too.

    Thanks for posting your results.

    Best Regards

    Samir Lehaff

  • Thanks for detailing the interface Richard. I will use it for a first step integration.

    My actual application is using structured light by means of the pico DMD device. the 2607 controller has some limitations  when managing patterns, ( Splash screens) as the controller has a 16Mbyte flash memory size limit, this can only give room for 4 splash screens ( 0..3) in the memory map, I will need to double or triple this flash memory size limit.

    Do you have any thoughts on the subject?

    Thanks in advance

    Ssamir Lehaff

  • Hmm..

    640 x 360 x 24Bit RGB gives me 691200 Bytes per Screen...so 16MByte flash has room for 24 splash screens...

  • The 2607 uses the 16 MB flash for multiple purposes, LUTs, maailboxes, boot code, still it may be possible to identify some functions that I can do without, eliminating the need for their space, while maintaining compatibility with 2607 ASIC software.
    I actually only need 8 bits of data per pixel, 3 doubling hte mem capacity, may require the ability to synchronize my camera with the color refresh rate, I will be looking into it shortly.
    Thanks for your input.
    Samir
  • From my short experience with the RPi attaching to the DLP it seems that the DLP will continue to display the last frame it received over the parallel interface...but I might be wrong (o;

    Maybe add a simple FPGA with attached flash memory which then just generates one frame for storing into the video RAM?
  • Richard & Samir,

    This thread appears to have answered most of the outstanding questions. For followup questions, I recommend that a new thread be created as this one is stale.

    Best Regards,

    Philippe Dollo
  • Just to add some confirmation for others reading this thread. I can confirm that I have been able to send I2C control info to the DLPDLCR2000EVM using a RPi Zero. I haven't yet completed the video integration, just the I2C part. In preparation for setting up the parallel video (which will be the RGB666 format as discussed on www.raspberrypi.org/.../README.md I followed the advice on this thread by Richard K, and set up the software i2c on BCM pinout 23 and 24 (physical pins 16 and 18 on the Pi Zero, plus common GND connection).

    With command 'i2cdetect -r -y 3' ont he RPi, I got the same scan table results as the Richard K post above.

    I then entered the command 'sudo i2cset -y 3 0x1b 0x0b 0x00 0x00 0x00 0x01 i' which switched the video output from the default splash screen to an internally generated screen pattern output.

    I then entered the command 'sudo i2cset -y 3 0x1b 0x0c 0x00 0x00 0x00 0x1b i' which made the video pattern full screen.

    I then entered the command 'sudo i2cset -y 3 0x1b 0x11 0x00 0x00 0x00 0x00 i' which switched the output pattern to a fine check-grid pattern.

    The command register to switch from splash screen to internal test patterns is defined in section 2.4.1.3 and then the command to switch the patterns is defined in section 2.4.1.10 of the DLPC2607 Programmers Guide www.ti.com/.../dlpu013.pdf

    I hope this helps others getting started. You can use this as a first step since it uses the internal video patterns, without the extra complications of the parallel video config/setup. That's my next step...

  • Philip,

    Thanks a lot for your comments. It's invaluable for other E2E users who are working on the RPi as well.

    - Philippe Dollo
  • For instance...me. I just turned on my DLP and I do get the splash screen. My RPi3 boots just fine, and still sees the LCD display across i2c from a previous project. My understanding is that I can take those SCL and SDA lines that are talking to that LCD, and also connect them to another i2c agent, such as this DLP. But my i2cdetect -y 1 still sees the LCD display at 0x27, and nothing else. I'm pretty sure I have the SCL and SDA wires connected to pins 19 and 20, respectively, of the DLP's P2 connector. (Plus a ground wire from P2 pin 2 to the RPi3.) Can anyone spot my problem, before I get desperate and haul out the old oscilloscope?
  • Robert,

    The DLP EVM has a "VINTF" line which is used to dictate the I2C level used by the device. This is referenced in the DLPDLCR2000EVM User's Guide at:
    www.ti.com/.../dlpu049c.pdf

    Have you tried checking these other pinouts on the system? It is possible that the VINTF pin is not being driven so the DLP EVM is not expecting the correct I2C levels.

    Best Regards,
    Philippe Dollo