I'm using both STM32F103 and STM32F407 with a SEPS525 SPI driven OLED display (160x128). I want to store images to display in internal flash, but BMP uncompressed images with 16bit colors are huge (about 40kB each). Is it possible to transfer jpeg images in the internal flash and use them with TJpegDec http://elm-chan.org/fsw/tjpgd/00index.html to save some flash space? (I'm using IAR Ide and ST-Link v2)

Many thanks

  • \$\begingroup\$ Generally you'll use an SD card to store the images, like many of the LCD screens have \$\endgroup\$ – Funkyguy Jul 15 '14 at 15:17
  • \$\begingroup\$ It might be easier to just implement some lossless compression, like RLE or perhaps bzip2 to compress the raw bitmaps. Given you have sufficient memory to decompress images in one chunk, you should be able to get a decent amount of flash savings this way without compromising on quality. \$\endgroup\$ – Tristan Seifert Jul 15 '14 at 17:09
  • \$\begingroup\$ @TristanSeifert thanks, are there embedded sized libraries for them or some detailed instructions to implement them? It would be good if I can save half of the space compared to uncompressed BMPs. \$\endgroup\$ – user3162481 Jul 16 '14 at 7:09

are there embedded sized libraries for them or some detailed instructions to implement [lossless decompression]?

Yes, it is possible to put compressed photographs (or drawings or fonts) in flash and then decode them with a variety of libraries.

Two popular techniques for storing arbitrary binary data in flash are: are:

  • Store the (possibly compressed) drawings (or photographs or fonts) in a SD card or some other external flash media, and use library functions in your application to pull those images from the card
  • Use a bin2hex utility such as xxd(a)(b)(c)(d)(e)(f)(g)(h)(i) to convert (possibly compressed) binary files into ".c" C language source code files as named arrays. (Typically using "const" or "PROGMEM" or whatever magic keyword your compiler uses to keep that data in flash, without using up any RAM). Then compile those source files into your application; and use normal array access [] to pull the bytes of the drawings or photographs from program memory.

There are a variety of tradeoffs in how to store stuff in flash, between

  • drop drawings in PNG, photographs in JPEG, or both on the SD card in FAT format, and use a lot of code space on your microcontroller to implement FAT libraries, decompression from PNG or JPEG or both to RGB pixels, and reformat to push to your screen.
  • Use software on your development computer to convert photographs or drawings or both into some other format that takes less code space (or less RAM) on your microcontroller -- in the extreme case, simply copy bytes from the SD card to the display.

There are a variety of lossy and lossless data compression libraries available; often the "decompression-only" section is relatively small and would probably fit on your microcontroller:

Libraries more-or-less specifically designed for photographs and drawings:

"Small" libraries that apparently work well in embedded systems:


Sure, it should be possible to adapt that library to your platform; it already lists Cortex-M0 so running it on an M3 or M4 should be fairly straightforward.

You'll have to weigh the tradeoff between an external storage device and using up on-chip flash - but if you have it available (the commonly encountered '407 variants have a lot) you can simplify your design by using it. If you do a board you might want to place a footprint for an external flash device and not populate it if find you can squeeze everything on-chip.

Especially with the '407 if you are deploying test builds every few minutes during development you may find it worth the time to figure out how to configure your programmer tool to only erase and overwrite your program, and keep your data in a separate area of flash which you rewrite only when needed.

  • \$\begingroup\$ I have already tailored the TjpegDec on the MCU I'm looking for the way to put jpeg on the internal Flash (linker instructions, compiler settings and so on...). I will integrate an external FLASH in a bigger project when I have a lot of images, but in this case I would like to fit in the MCU flash. In both cases I would like to know what to say to IAR to put an image .jpeg file in flash. \$\endgroup\$ – user3162481 Jul 16 '14 at 7:15
  • \$\begingroup\$ Not sure how you'd do that under IAR (there are much better toolchains) but generally you can explore things like instructing the linker to include a binary, turning your binary into a hex file and flashing that separately or merging it with the one containing your code, or if all else fails translating your binary data to an array of hex bytes to initialize a constant array in C syntax, and feeding it through the compiler \$\endgroup\$ – Chris Stratton Jul 16 '14 at 15:13
  • \$\begingroup\$ @ChrisStratton "translating your binary data to an array of hex bytes to initialize a constant array in C syntax" -- that's what I have done in the past, using simple RLE compression, and it worked out well. \$\endgroup\$ – tcrosley Oct 14 '14 at 16:37
  • \$\begingroup\$ @Chris What's wrong with IAR? \$\endgroup\$ – m.Alin Mar 14 '15 at 9:09

Have you considered an external SPI flash device? 8MB (204 full screens) can be had in SOIC-8 for a couple of dollars and it's soldered down so won't have contact-reliability issues like an SD card.

If you can put the flash and OLED on separate SPI ports, you should be able to DMA between them at SPI bus-speed (1MB/sec = 25fps) via a tiny memory buffer. I think the 407 would allow you to directly DMA from external flash via the FSMC to the OLED's SPI port (I've only used the F103 so haven't tried the FSMC, personally).

Much easier and probably better-performing than writing (de)compression code IMHO.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.