Loading images/buttons from SD Card

[lampii]

I am loading several bmps for my background and button images but i seem to be hitting a hardfault when I use too many of them. 

Does uGFX store loaded images in internal RAM or are they dawn directly to the screen?

 

[inmarket]

Images are not stored in ram unless you call gdispImageCache(). There are still some overheads in RAM however. It is unlikely that that would be running you out of ram.

What you might be hitting however is the limit on the number of open files in GFILE. Check the config for the setting controlling the number of open files. It will be something like GFILE_MAX_FILES. Sorry for the ambiguity,  i am on not replying on my computer.

[Joel Bodenmann]

To extend/elaborate/explain what @inmarket mentioned: The GFILE module has a settings named GFILE_MAX_FILES that specifies the maximum number of files that can be opened at once. Emphasis on the at once part. You can use an unlimited number of files but only GFILE_MAX_FILES files can be opened simultaneously. Therefore, you might want to close images (and other resource files) that you don't access frequently.
Please check the documentation for more information on things like GFILE_MAX_FILES, image caching and more.

Anyway, hitting the limit of GFILE_MAX_FILES definitely doesn't cause a hardfault. The corresponding gfileOpen() function would simply return an error code but there is nothing that causes a hardfault. The system is very robust: Even if you're trying to cache or draw an image that comes from a file that couldn't be opened successfully nothing will happen. As @inmarket mentioned images are never stored in RAM. However, there are small overheads which depend on the image format. Most likely you are simply running out of memory. Note that "running out of memory" doesn't mean that your microcontroller has no more RAM left but that probably your context is out of memory. For example, when you're drawing an image in a thread, it uses the thread stack. If the thread doesn't have a sufficient stack size you'll end up causing a stack overflow which almost always results in a hard fault.
If you're running bare metal (with no underlying operating system by using the Raw32 port) you might want to adjust GFX_OS_HEAP_SIZE as discussed in the corresponding documentation.

That's what we can give you right now. If you have more questions, please don't hesitate to ask.

[lampii]

Hi @Joel Bodenmannand @inmarket,

I am using an STM32F429VIT which has plenty of flash and ram along with sdcard using the internal fatfs. My images are being loaded from the sdcard by the way. I solved my issue by changing the GFILE_MAX_FILES define and everything is working nicely now albeit loading images is a bit slower than expected. I assume loading images straight from flash would be much faster but my home brew implementation of chan's fatfs and drawing was atleast 2.5x as fast without DMA. I was wondering if there is anyway to get ugfx to stream from the sdcard via DMA? I have the 4-bit bus connected so i reckon it may speed up the drawing of elements significantly. Otherwise I can wait until all my UI is flushed out before migrating it to flash. I'm afraid I would be stressing my flash writing so much image data to it.

Thank you for pointing me to the correct point in the documentation. I will take a look as I am bound to hit the limits at some point =).

[inmarket]

Using dma is unlikely to speed up the image drawing. The problem is not cpu cycles but the io speed of the sdcard itself so dma is unlikely to make any difference to the speed at all.

What you can do to speed up images if you want to keep them on slow storage like the sdcard is to use the gdispImageCache call. This caches the image in ram to give speed as good as loading the image from ROMFS. The downside is obviously the ram usage.

The truth is nothing beats using ROMFS (flash) for images. The only downsides are flash size and you have to recompile to change the images.