separating bitmaps from code

[mark2399]

Posted on March 10, 2015 at 11:21

Hi All,

I'm on the tail end of a large development for an stm32 using gcc and openocd. As I add more code and bitmaps (for the LCD) I'm finding the load times getting rather long, mainly due to the bitmaps.I'd therefore like to split them up, so that the bitmaps reside somewhere in a fixed location in flash, seldom downloaded. while the code is stored elsewhere to be reloaded regularlyDoes anyone have any ideas on how this could be achieved simply and elegantly? I think it would be possible to effectively have two projects, one converted to binary format rather than elf, then loaded to a specific address. Just wondered if there was a better way of doing it. So far google hasn't thrown up anything obviousthanks in advance...

[Tesla DeLorean]

Posted on March 10, 2015 at 13:00

I guess the real problem is communicating between the two where specific bit maps are placed.

At the moment you use the linker to do the placement work, and to generate an ELF file. You could use the linker to deal with just the bit maps too, but you'd need to build some sort of index/table referencing them, or use a script to process the .MAP file to generate linkage information the application could use.In these kinds of cases people often use a ''file system'' to associate names with images. This is also quite common with web server/http examples where they want to enumerate .HTML and .JPG, etc. and you have a file like FSDATA.C, built with FSMAKE/FSBUILD.EXE type constructs. These things have properties of a light weight file system, with meta data (name, size, address) and linked lists, etc to allow for mechanical processing either by name or index.Binary in difficult to work at with a debugger, something that infers address like .HEX or .ELF works better. The hex files being over a very simple format, and easy to create in a small application. The ELF file would require more thought, but isn't unduly complicated as object files go.

[waclawek.jan]

Posted on March 10, 2015 at 19:31

I do exactly this, although my big data are not bitmaps and I use a custom

http://www.comsytec.eu/en/online-store/detail/34-software-development-tools/flypage%7ceps/101-eps-debugger-for-stm32?sef=hcfp&vmcchk=1

into CodeBlocks IDE which serves also as the ''downloader''; but neither of these matters as the underlying principle is the same. Have the linker to locate the big data to an explicitly named output section, other than the standard .text nor .rodata, placed at a suitable flash page boundary - you are familiar with the linker script I presume. Then after .elf has been built (containing everything), use objcopy to generate two .hex - one for everything except the big data; other containing the big data - the -j and -R options are your friends. Then load the big-data-hex once, and after each recompilation load both the everything-except-big-data-hex, and the .elf - the latter as symbols only. I believe you would use exec-file and symbol-file under gdb, but as I said above I don't use gdb currently. JW

[waclawek.jan]

Posted on March 10, 2015 at 19:49

The file-system as Clive said above is a very nice idea, too. You don't even need to go as far as filenames and linked lists; as you'll probably have a fixed number of bitmaps once the application is finished (so it's not like a web-server or like, where files can point to other files through their names). Simply create a table (array) of bitmap sizes and stick the bitmaps in the same order after that, and load that bundle to a fixed address. The application then only needs to know that address to be able to calculate where the required bitmap nr. N is located... Dead easy... 😉

JW

[mark2399]

Posted on March 11, 2015 at 09:20

JW and Clive1,

Thanks for your informative replies. These methods are exactly the sort of thing I'm looking for.The linker/build process tweaking seems like a good quick and simple solution and that was initially the direction I was thinking of going in. The file system method looks like a good elaborate system which I'd never really considered.I will investigate both.thank again,Mark