Best way to load large images into RAM?

[Chris Rice]

Posted on July 09, 2018 at 02:16

Hi there, we are using MDK-ARM to develop an application on our STM32F7 which drives a display, and we would like to present a relatively sophisticated UI, which will included some compile-time static images.  We are learning as we go here, and I tried to be clever and created a desktop tool into which we can drop a picture, and it would generate a C function to set a range of RAM to hard-coded pixel data to represent the picture, which I'd call on initialization.  When I wanted to show this image I would just direct the LTDC layer to the address this picture was written.  This was going well until I got to the first of several 400x400 images, which generated a 160,000 line function and crashed the compiler.

So, I'm done being clever and thought I'd ask the pros: what's the Right way to do this?  What's the best way to weave a large chunk of binary data to be pre-loaded into a known memory location when your application initializes?

(This must be well-traveled territory, but I did some googling and didn't turn up much... or maybe the keywords I was using are too overloaded.)

Thanks for any thoughts!

#image-processing #ltdc #lcd-driver #stm32f7

[Tesla DeLorean]

Posted on July 09, 2018 at 02:54

There are an infinite array of correct answers, it can be as simple or complex as you want.

Have a tool that generates a .HEX from the binary resource data.

Drive it with a script.

If the device has external memory, or QSPI, you could make it with a suitable base address, like 0x60000000 or 0x90000000.

You can have a simple file system, or indexed table (describing location, and size).

You could create a FAT file system type image.

If the data is compressible, you could make a .ZIP file, or use something like ZLIB.

Look at things like FSDATA (LWIP), and MAKEFSDATA

[Chris Rice]

Posted on July 09, 2018 at 03:52

Thanks so much, I see that (

http://www.keil.com/download/docs/113.asp

 ) and am pulling the thread.

Dumb question...

I'm looking at the HEX file I'm generating, and from the memory addresses I think I see that it's loaded into a region called IROM1, defined in my compiler options as 0x8000000, length 0x20000.  If I edit this HEX file post-build, am i effectively preloading data into this ROM portion of my program?

And this is probably too good to be true, but can my LTDC peripheral then be configured to pull data from this ROM section of memory?  

If yes and yes (I'm probably not that lucky) I think that's what I'll try.

Thanks again.

[Chris Rice]

Posted on July 09, 2018 at 03:14

Hi Clive, thanks very much.  I think the .HEX tool is the first thread I want to pull.  Do you happen to have the name of or a link to such a tool?  I'm googling 'binary resource hex tool' and variants and not turning up much.  

[Tesla DeLorean · Accepted solution]

Posted on July 09, 2018 at 03:22

BIN2HEX ?

The Intel and Motorola HEX formats aren't particularly complex. I've written packaging and output tools. Basic mastery of C file functions like fopen, fclose, fread, fwrite, fseek, ftell should suffice.

Source code, perhaps look at SRECORDS project