options for driving 800x480 rgb lcd
Posted: Fri Jun 21, 2024 4:07 pm
I have hooked up a display using the lcd_rgb_panel interface. The initial demo uses 16bpp with framebuffers stored in psram.
I had a problem because my display wants to be clocked at 25mhz, but this does not work using quad spi ram. I was able to get it working at 16mhz but it is out of spec for the lcd, and I am concerned I will have issues doing other operations. I want a good framerate (10-20fps) but dont care about color count, and 16 colors is enough, so I tried with 4bpp and all ram buffers:
The palette is a 256 array of uint32_t looking up 2 pixels at a time. This seems to actually work, but I get tearing, and I cannot fit more than one framebuffer in ram. I am also concerned using bounce buffers will use a lot of cpu. Using 16bpp doesnt work, and cutting memory bandwidth in half isnt good enough (in case other processes need to access ram) I think I need a factor of 4 or better.
1) double buffered 4bpp in psram.. I tried and the result is much slower and probably lots of data transfer. It does seem to work. Is there a way to put one buffer in ram and the other in psram? I am not sure
2) use rle compression on the framebuffer... is this even practical? cpu?
3) switch to 8bpp data bus and an esp32 with octal ram? Would this be stable/reliable? I am leaning toward this as it would cut bandwidth in half while doubling access speed.
Are there other options? What is the best way to minimize overhead and still drive such a high resolution with fewer colors? Is 4bpp always going to be impractical because of cpu use? Is there some way to clock out 4bpp directly without cpu intervention and perform a palette lookup?
I had a problem because my display wants to be clocked at 25mhz, but this does not work using quad spi ram. I was able to get it working at 16mhz but it is out of spec for the lcd, and I am concerned I will have issues doing other operations. I want a good framerate (10-20fps) but dont care about color count, and 16 colors is enough, so I tried with 4bpp and all ram buffers:
Code: Select all
static bool example_on_bounce_empty_event(esp_lcd_panel_handle_t panel, void *bounce_buf, int pos_px, int len_bytes, void *user_ctx)
{
uint32_t *pcx = (uint32_t*)bounce_buf;
int pos = pos_px / 2;
uint32_t len = len_bytes/4;
for(int i=0;i<len; i++)
pcx[i] = palette[framebuffer[pos++]];
return true;
}
1) double buffered 4bpp in psram.. I tried and the result is much slower and probably lots of data transfer. It does seem to work. Is there a way to put one buffer in ram and the other in psram? I am not sure
2) use rle compression on the framebuffer... is this even practical? cpu?
3) switch to 8bpp data bus and an esp32 with octal ram? Would this be stable/reliable? I am leaning toward this as it would cut bandwidth in half while doubling access speed.
Are there other options? What is the best way to minimize overhead and still drive such a high resolution with fewer colors? Is 4bpp always going to be impractical because of cpu use? Is there some way to clock out 4bpp directly without cpu intervention and perform a palette lookup?