DMA for framebuffers in DPI (LCD_CAM RGB Display)

[jgtaylor]

First, a huge thank you to @Dominaezzz for the DPI driver.

I've been poking around at it and I've encountered some issues that are likely a function of waiting on other features to be implemented/supported, as well as my own limited experience with RGB panel displays.

I'm using a "CYB" - that is, "Cheap yellow board" that provides no SPI interface or useful graphics acceleration, instead relying on the VSYNC, HSYNC, DE, PCLK and the LCD_CAM::LCD peripheral.

I was trying to interface it quickly with embedded-graphics, and it kind-of works. That is, I can get solid colors (not always the correct one), but I can also get all kinds of other things - like vertical stripes, hounds-tooth patterns, etc., all not intentional.

Of course, playing with the timings, as well as the frequency in Dpi::new(lcd, dma.tx, freq, config) produces the various results above. I have, however, tracked it down to DMA and the buffer sizes (in conjunction with the frequency).

Unfortunately, I have been banging the keyboard for so long that I have likely confused myself about all sorts of things. So, I hope someone might be able to help me understand my DMA buffer issues.

I have been able to allocate buffers to PSRAM, via the HEAP. However, anything larger than 4k (within the chunk bounds, etc.) just never seems to get the data out (feels like a hang). However, switching to a dma_loop_buffer!(xxxx) generally gets some data to the screen (not always the correct data). For example, allocating a 768K frame-buffer as a DmaTxBuff works. Getting data from it to the dpi peripheral appears to hang or never finish (I let it run over night to see if it was a slow clock thing). I've tried using large chunks, tiny chunks, and medium chunks. I've tried max CPU clock (240Mhz) - it does, in fact, speed things up, but still no "accurate" data out.

For the life of me, I can't figure this out. The code base is very simple (perhaps even silly) - https://gitlab.com/jgtaylor/phils-audio-player/-/tree/mipidsi-integration?ref_type=heads .

I don't think I'm using the "flash" feature that could interfere with the PSRAM DMA. I've tried sync/async LCD as well as DMA (had to change the signatures for the DPI::new() to get this), with little difference.

[Dominaezzz]

Of course, playing with the timings, as well as the frequency in Dpi::new(lcd, dma.tx, freq, config) produces the various results above. I have, however, tracked it down to DMA and the buffer sizes (in conjunction with the frequency).

If you've got a datasheet for the display I can double check your config if you like.

For the life of me, I can't figure this out. The code base is very simple (perhaps even silly) -

Good thing you shared the code, I can see what's going wrong.

You have misunderstood how the DPI driver works and how DmaLoopBuf works. I've been very lazy with documenting both so I can understand why you wrote the code the way you did.

The DPI driver doesn't support chunking and this is a hardware/protocol limitation. The driver can either send a full frame once or multiple full frames indefinitely. Nothing in between.
Any chunking will need to be done on the DMA side but there aren't any DmaTxBuffer implementations that do this for you yet. You can implement one yourself for now.

DmaLoopBuf can only handle up to 4095 bytes, and then this buffer is transmitted over and over again indefinitely. It's primarily used for filling the entire frame with a single colour.
DmaTxBuf is more appropriate for what you're doing.

To summarise, your flush code which is trying to draw a whole framebuffer in chunks, is actually sending multiple frames where the each frame only gets 3200 bytes worth of data, which is repeated several times until the end of the frame.

I hope that makes some sense.

[jgtaylor]

Regarding the datasheet: Its an ST7282 - a kind of aliexpress 4.3 inch display. (https://focuslcds.com/wp-content/uploads/Drivers/ST7262.pdf).

This definitely makes sense. I'd tried using a full 768k DmaTxBuff, with varying chunk sizes (64..40xx[i forgot to document]), but it never actually displayed anything. I guessed / assumed this was based on a PSRAM vs internal dram speed issue, but the timing seemed comparable to the dma_loop_buffer. I ran into issues allocating tx_desc at very low chunk sizes (e.g below ~256) which, if i remember correctly, was based on simply too many pointers to fit in internal dram. Changing the PSRAM to internal, using the sequence of init_heap; followed by init_psram_heap allowed for smaller chunk sizes, but sadly it made no difference on the display.

I even did this horrible implementation experimenting with unsafe and made a kind of "double pointer" in the flush function which did a DmaTxBuff::new_with_blocksize() that was equal, in so far as assert_eq!(buff_tx, dpi.framebuffer);. Still, blank. It felt like a timing issue, but I couldn't figure out how to verify that.

Regarding:

Any chunking will need to be done on the DMA side but there aren't any DmaTxBuffer implementations that do this for you yet. You can implement one yourself for now.

I confess I looked into the dma stuff, specifically buffer.rs, and the various implementations, and while I understand them - conceptually, I'm not sure what would be needed - that is, I generally understand the requirements, but I'm not sure what's missing - e.g. would it make sense to just extend the dma_loop_buffer, or replicate it in so far as the wait() implementation? Or something like a framebuffer that implements the traits similar to: https://docs.esp-rs.org/esp-hal/esp-hal/0.22.0/esp32s3/src/esp_hal/dma/buffers.rs.html#312 (e.g the prepare, into_view, from_view)? My concept is, dma writes from frame_start, in 2 byte (16 bit) iterations, 384k times (or, FRAMEBUFFER / 2) where src changes, but dst is always the lcd_peripheral channel bit/thing, somehow in sync with PCLK and HSYNC and/or DE.

I know i'm missing something, just not sure what it is :-/

[Dominaezzz]

Regarding the datasheet: Its an ST7282 - a kind of aliexpress 4.3 inch display. (https://focuslcds.com/wp-content/uploads/Drivers/ST7262.pdf).

The timings look correct to me. My only note is you should probably set hs_blank_en to true, and increase the frequency from 6 to 25 (or at least 16). Dropping the frequency to 6 means you have to drop decrease the timings accordingly, otherwise you'll get weird artefacts on the screen. The LCD pixels need to be written to often, otherwise they lose "charge" and flicker.

with varying chunk sizes

Bigger is better for this peripheral in particular. Try to keep it at 4092 and enable bursting.

I guessed / assumed this was based on a PSRAM vs internal dram speed issue

Yes, PSRAM can fall behind, we'll need #2083 .
Without that the frequency needs to be dropped real low, or we need to implement bounce buffers.

I don't think I'm using the "flash" feature that could interfere with the PSRAM DMA. I've tried sync/async LCD as well as DMA (had to change the signatures for the DPI::new() to get this), with little difference.

Your firmware lives in flash, so the fact that code is executing means flash is being accessed.

Or something like a framebuffer that implements the traits similar to: https://docs.esp-rs.org/esp-hal/esp-hal/0.22.0/esp32s3/src/esp_hal/dma/buffers.rs.html#312 (e.g the prepare, into_view, from_view)?

This yes. Have a look at DmaRxStreamBuf to get an idea. It's slightly more complex/powerful than what you want but the general idea of streaming/chunking is there. You just need to add new descriptors (with buffer data) to the end of the linked list and reclaim consumed descriptors from the start.

Don't extend the hal, just make yer own DmaTxBuffer implementation in your repo.

I'll try and setup a PSRAM example myself and see how it goes. Maybe if I can drop the frequency enough, or halt the CPU perhaps.

It felt like a timing issue, but I couldn't figure out how to verify that.

Just to confirm, are you able to fill the screen with a solid color (with DmaLoopBuf like the hal example does) using the timings and frequency in your current code?

[jgtaylor]

Just to confirm, are you able to fill the screen with a solid color (with DmaLoopBuf like the hal example does) using the timings and frequency in your current code?

Confirmed - at the current 6Mhz, it goes red, then green, then blue, then black and back to red. At 25 Mhz, it just stays red. Above 40Mhz, it creates vertical bars.

I'm going to tackle an implementation of DmaTxStreamBuf. My confidence isn't high, but ... I'll update here with either frustration or success :-)