which memory for image cache

[Alba800]

hello everybody and thanks to the uGFX team for the great job.

I'm analyzing this library for my next job, so this is the question:

suppose I have all my variables and stacks in the processor's internal RAM (STM32F429) and the display RAM (8 mega SDRAM) is on the external bus.

If I want to cache an image from the SDcard (a big one, say 800x600), I need to use the external RAM, but I see that there only one allocation mechanism and that one is used for any kind of data. But I don't want to put my variables and stacks in the external RAM.

So, how could I do this? Am I missing something?

thank You in advance

[Joel Bodenmann]

Hello Alba800 and welcome to the community!

Right now we do not provide high level API for this. However, you are already the second user/customer who requests this feature. It is now on our ToDo list and we try to get it done within the next few weeks.

The only thing that would be easy to do right now is to use the image caching feature and re-routing the gdispImageAlloc() function so this uses your external RAM. You can find that function in /src/gdisp/gdisp_image.c:197

Maybe inmarket hat another smart solution

~ Tectu

[inmarket]

The easiest way is to cache this manually. Copy the file contents to the external ram you want to use. When you open the image use the api calls that allow you open an image from a memory buffer.

Note there is no advantage in doing this with images in flash as flash (ROMFS) tends to be as fast or faster than external ram. It is definitely a good idea for images coming from something like an sdcard though.

[Alba800]

Thank you for the solution, it works.

But let's go a bit further.

With this technique what is loaded in ram is a copy of the .bmp file and the actual conversion to pixel format is done later, while drawing the display.I think that this could slow down the drawing speed, also a bitblt is not possible.

Any suggestion? Diversified memory allocation?

Thank you again

[inmarket]

You will notice in our image api that we have calls that enable caching. These calls cache the image in a format that is most appropriate for each image decoder. For bmp images that happens to be similar to the internal native image format but for gif images it is an easy fast decode byte format. In both cases we don't support blitting from those internal image structures.

The reason we don't have tagged memory support is simply due to complexity. Some operating systems support it and some don't. Additionally that support would need to be rippled through all the image code. Unfortunately that would be a significant increase in code complexity for little gain for most people.

In reality you probably don't really need it especially with bmp images as they decode very quickly.

If you really want the ability to use tagged memory with a blittable image format, there are two possibilities.

1. Instead of using bmp image format, use a native image format. Once you get past the header it can be blitted directly to the display. Creating the images in native format is a bit of a pain but once past creating the image you can you the existing ram loading mechanism.

2. Create a pseudo framebuffer display that uses your external ram for its frame buffer. You can then draw onto that display, including decoding images onto it and because you know the address of the framebuffer you can then bit blit from it as needed. This is effectively what pixmaps do except that with pixmaps you can't currently control the address of the framebuffer.

[Alba800]

Hi,

I had to make a change to get the gdisp_lld_blit_area working in gdisp_lld_STM32LTDC.c

// Foreground memory address register

// DMA2D->FGMAR = g->p.y1 * g->p.x2 * LTDC_PIXELBYTES + g->p.x1 * LTDC_PIXELBYTES + (uint32_t)g->p.ptr;

DMA2D->FGMAR = g->p.y1 * g->g.Width * LTDC_PIXELBYTES + g->p.x1 * LTDC_PIXELBYTES + (uint32_t)g->p.ptr;

// Foreground offset register (expressed in pixels)

// DMA2D->FGOR = g->p.x2 - g->p.cx;

DMA2D->FGOR = g->g.Width - g->p.x2;

basically I had to change the DMA start address and offset to get it working

I still have some problems with the clipping function in gdispGBlitArea where I had to comment this line

// if (srcx+cx > srccx) cx = srccx - srcx;

but I'm investigating

thank you

[Joel Bodenmann]

Sorry for the late reply.

What uGFX revision are you on? We changed the LTDC code a few weeks/months ago as we introduced support for the F7 and back then the DMA2D seemed to work just fine. Is this only related to your other changes or is the DMA2D driver not working for you in general?

~ Tectu

[Alba800]

Hi Tectu, I'm using the latest version from the master branch.

I think the difference is in the meaning we give to "area". My intention was to copy part of the screen to another location, so something that has an x,y starting point and xsize,ysize; in my case It is a block of 150x200 pixels. Looking at your use of the blit routine i see that your dma2d initialization is for a small buffer (32 pixels) so the starting point is always the same and not related to xy coordinates and also never involves more than one line. Thats why I had to modify the dma2d initialization of the start address and the offset. (Which now works both with block coordinates and a buffer)

P.S.

actually,now I see that my offset initialization could not work for multi lined pixmaps...