Introduce RGB/DPI driver

[Dominaezzz]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• I have added necessary changes to user code to the Migration Guide.
• My changes are in accordance to the esp-rs API guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Description

Add a driver for the RGB mode of the LCD_CAM peripheral. Closes #2081.
I've called it Dpi since Rgb is a generic name (though I don't mind renaming it if anyone insists). The I8080 driver has similar opinionated name.

I still need to write some more docs (which may involve diagrams if I can be bothered), which is why this is still draft.

I've opened this early as a formal request for one of the maintainers to acquire a devkit that can run the example.
Makerfabs MaTouch_ESP32-S3 Parallel TFT with Touch 4.3"

(I tried using the espressif devkit linked in the issue but the initialization code is buried deep in esp-bsp and it would complicate the example with bitbanging SPI over an I2C gpio expander)

Testing

HIL test and example

[Georges760]

Great to see this PR, I was considering working on this need.

[Georges760]

shouldn't that be "lcd_cam_dpi" to match the format of "lcd_cam_i8080" below?

[Dominaezzz]

I choose to skip the suffix as I'm testing both the camera and the DPI drivers in the same test.

[jgtaylor]

I've tested this on a 7" with an EK9716 display controller, and it appears to be working. Board used: https://www.aliexpress.com/item/1005005560920555.html

I've not done any kind of exhaustive tests - just run the lcd_dpi.rs from the example directories (with pins modified for the above board).

The example code results in the screen going through various colors. On my device, it appears to flicker fairly intensely. Changing the clock to 40 & 50 Mhz seems to help with the flicker a bit. Using 33 Mhz results in interesting artifacts on 2/3 of the display.

In any case, this MR has my vote! Getting this into main would be a tremendous step forward!

[Dominaezzz]

The example code results in the screen going through various colors. On my device, it appears to flicker fairly intensely. Changing the clock to 40 & 50 Mhz seems to help with the flicker a bit. Using 33 Mhz results in interesting artifacts on 2/3 of the display.

Curious, in addition to the pins, did you also update the frame timings?
Also maybe try making the loop buffer bugger.
I'd also appreciate a video recording of the flickering if you can share one.

[jgtaylor]

please forgive the horrible video and my silly commentary (also, apologies for using YouTube) - https://www.youtube.com/shorts/tHPwoWvb11o

Also, I had to turn on the backlight to actually see the screen. The flicker could be from the backlight, or not using ledc to dim it... or, or or ... I confess, I'm so new to rust, I'm still fighting with the borrow checker, but I am excited as can be to get this working!

[jgtaylor]

quick update - i've played with the timings, however they're pretty spot on for the EK9716. I increased the dma_loop_buf to 16 * 16 which helped. It removed the artifacts at 33.MHz(). I think my flicker is more a result of the back-light.

somewhat random question: do the "back porch" timings need to be defined? Pic from datasheet for posterity, or in-case it helps anything (pls ignore if its useless)

[Dominaezzz]

please forgive the horrible video

I suppose it can't be helped for this example since every single frame is a different color. Trying to see it on video was a lost cause to begin with haha. Would need a different example, one that alternates between two colors once a second.

somewhat random question: do the "back porch" timings need to be defined? Pic from datasheet for posterity, or in-case it helps anything (pls ignore if its useless)

This is where I need to write some documentation.
The short answer is no, the hardware can calculate it based on the other params.

I increased the dma_loop_buf to 16 * 16 which helped. It removed the artifacts at 33.MHz()

I'm glad this helped!

Just to be sure about the flickering, try changing the example to only draw on color and see if it still flickers.
You can do that by changing.

dpi.send(false, dma_buf).map_err(|e| e.0).unwrap();

to this

dpi.send(true, dma_buf).map_err(|e| e.0).unwrap();

[jgtaylor]

I can add to the review that I've tried this on the 4.3" cheap yellow board, at 800x480, and it looks wonderful. The 4.3" uses a ST7262.

The "flicker" i'd reported is definitely not flicker, but the backlight being a bit over-powered.