Memory usage

ROM

The amount of ROM that emCompress uses for decompression, varies with the codec selected. The table below measures the total ROM required for a single decoder, including all supporting functions and excluding integrity checks on the target device.

The amount of RAM that emCompress uses is under complete control as it is specified at compression time. Typically, 2KB of temporary RAM for decompression is already enough for  good compression ratios, but even without temporary RAM, good compression ratios can be achieved in many cases. No static RAM is required and stack usage remains well below 512 bytes.

Use cases

With emCompress-Embed data is compressed on the host. As a result the compressed data can be included as a byte array in a firmware image, along with the algorithm to decompress the data on demand.

Reduce firmware size

Software never shrinks in size. . During the lifecycle of embedded systems, customers expect firmware updates. Typically, firmware images  grow with each update, new features are added, existing features cannot be taken away., and at some point,new firmware risks exceeding available flash size.

Compressing static data, anything which is stored in flash and copied into RAM, e.g. used to configure peripherals or sent to external systems, can free up some memory to make another firmware update possible.

The decompression algorithms of emCompress-Embed are developed for a small ROM footprint. Thus emCompress-Embed can almost always reduce the overall firmware image size.

The emCompress-Embed Tools test all available compression codecs and select the best fit. With knowledge of the available RAM for decompression, the codecs can be tuned to match the resources of the embedded system.

Reduce storage requirements for configuration bitstreams

When an embedded system includes an FPGA(SoC) or CPLD, the firmware needs to load a configuration bitstream into the device. In small systems without external memory the bitstream data is usually included in the firmware.

emCompress-Embed can compress bitstreams to reduce storage requirements. On startup of the system, the firmware can decompress the bitstream. With decompression on the fly, the device can be immediately configured with decompressed chunks without having to  decompress the overall bitstream into RAM first.

Minimize size of interface assets

Embedded Systems with a user interface, such as a display or a web server, need to include assets to be displayed, such as web pages, images, or language files. If these assets are not stored in external memory, but are statically linked into the firmware, the impact to the firmware size can be huge. Sometimes firmware includes more data than code.

emCompress-Embed can reduce the size of assets quite significantly. To minimize the overhead, the emCompress-Embed tools can be configured to select one compression codec which achieves the best results for all assets, instead of choosing the best codec for each individual one.

When multiple assets need to be compressed, emCompress-Embed's group mode can achieve an even better result. By using group mode, all input data is linked together and compressed as a whole, enabling the compressor to compress the linked data much more effectively. This proves particularly effective when compressing small, static HTML files for embedded web servers. Decompression in group mode works essentially the same as ­single-file compression.