Electronic – Writing Flash on STM32

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:

• libpng and zlib source code, and more PNG documentation
• LodePNG
• TJpegDec

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

• miniLZO -- "one C source file and three header files. It compiles to less than 6 kB (on x86)"
• Snappy in ANSI C
• LibLZF consists of only two .c and two .h files in portable C.
• LZW compression in 500 lines of C
• more open-source data compression example code

I searched the datasheet, there is nothing about endian-ness. The issue might just be how you write to the flash memory. It seems to write to flash memory the 'words' are two bytes long, but the address itself is per byte. The original programmer was obviously a good kid, and read this part of the AVR-libc reference: "Note The address is a byte address. The data is a word. The AVR writes data to the buffer a word at a time, but addresses the buffer per byte! So, increment your address by 2 between calls, and send 2 data bytes in a word format! The LSB of the data is written to the lower address; the MSB of the data is written to the higher address."

source

The first half (byte) of 'w' is the byte pointed at by the dereferenced pointer 'buf' which is then incremented by 1 (by the ++). The second half of the word 'w' is done by this line " w += (*buf++) << 8" and what this does is adds the upper half (which is the contents of the address pointed to by 'buf' at the next byte) by shifting the byte left 8 bits. This puts it in the upper half, as I said.

You now have 'w' which contains two bytes of data, as a 'word' ready to be written with boot_page_fill function, a function from the AVR-Libc library.

If you ever do not understand the inputs to functions you should always try to look up the reference and see the comments that I found and showed above.