Suggestions for future improvements

  1. Lower the resolution to the DLP2000 native 640x360. This requires no hardware changes, but has a couple of benefits. The DLP2000 EVM no longer needs to do the 4:3 interpolation from the 854x480 in the original example. It also lowers the bandwidth required, making it more reliable with hand wiring. To do this, you use different parameters in your /boot/config.txt to set the resolution and display timings.
dpi_timings=640 0 14 4 12 360 0 2 3 9 0 0 0 60 1 13824000 3

You also need to change the I2C commands you use

# Set resolution to 640x360
/usr/sbin/i2cset -y $BUS 0x1b 0x0c 0x00 0x00 0x00 27 i
# Set input to parallel bus
/usr/sbin/i2cset -y $BUS 0x1b 0x0b 0x00 0x00 0x00 0x00 i

If you still have signal integrity issues, you can also drop the framerate from 60 to 30. I haven’t tried this myself, but I believe it would be setting dpi_timings=640 0 14 4 12 360 0 2 3 9 0 0 0 30 1 6912000 3 and i2cset -y $BUS 0x1b 0x19 0x00 0x00 0x10 0xb1 i to set the timings.

  1. Use I2C on GPIO 22/23 (header pins 15/16). This only really applies to the Pi 4, but works fine with the i2c-gpio driver. People have reported trouble with the GPIO I2C driver on the Pi 4. By moving I2C to these pins, you can use hardware I2C bus 6. You configure this by removing whatever other I2C configuration you have in your /boot/config.txt and replace it with dtoverlay=i2c6,pins_22_23. You then need to use bus 6 in your i2cset commands.

  2. Use a SystemD service to configure the DLP2000 EVM, rather than /etc/rc.local. Create a file /etc/systemd/system/dlp.service like this. I’m assuming I2C bus 6, but change to match your setup. You can then configure the display with systemctl start dlp or turn it off with systemctl stop dlp. You can set it to start on boot with systemctl enable dlp.

Description=DLPDLCR2000EVM setup

# Which I2C bus to use
# Set resolution to 640x360
ExecStartPre=/usr/sbin/i2cset -y $BUS 0x1b 0x0c 0x00 0x00 0x00 27 i
# All LEDs on
ExecStartPre=/usr/sbin/i2cset -y $BUS 0x1b 0x16 0x00 0x00 0x00 0x07 i
# Set input to parallel bus
ExecStart=/usr/sbin/i2cset -y $BUS 0x1b 0x0b 0x00 0x00 0x00 0x00 i

# Set input to test pattern
ExecStop=/usr/sbin/i2cset -y $BUS 0x1b 0x0b 0x00 0x00 0x00 0x01 i
# Set test pattern to black
ExecStopPost=/usr/sbin/i2cset -y $BUS 0x1b 0x11 0x00 0x00 0x00 0x01 i
# All LEDs off
ExecStopPost=/usr/sbin/i2cset  -y $BUS 0x1b 0x16 0x00 0x00 0x00 0x00 i
  1. Use DPI mode 6 instead of the default mode 5. This mostly only has a benefit on the Pi Zero, where moving to the alternate pins frees up GPIO 18/19 (header 12/35) that can be used as PWM0/1 in alt mode 5 to get sound out. You only need a small RC filter (as on the original Pi) or add a buffer for better sound as on newer models. This takes more work, since you need to create a device tree overlay yourself, or run other commands to set the pins to the right alt mode for both DPI and PWM. This would look a lot like the stock dpi18 overlay, with the correct pins for mode 6. You would also load the pwm-2chan overlay for sound.

  2. Use full 24-bit color. This uses all of the GPIO pins brought out to the header, but provides the best color depth. For control. you can pick up I2C on the camera (or on everything except the Zero, the DSI) port. This would require writing your own DPI settings in your /boot/config.txt and loading the dpi24 overlay. You can get access to the CSI/DSI header I2C bus as ID 0 by setting dtparam=i2c_vc=on in your /boot/config.txt.

  3. Use the DSI port. This is the most adventurous, but also has the biggest benefit. This is supposedly possible but would require a bridge between DSI and DPI, like the (unavailable in small quantity) Toshiba TC358762XBG used in the official Display, or Lattice CrossLink FPGA (that has hard MIPI DSI D-PHY blocks).