Thanks guys,
this indeed works!
The steps are:
- - add miniz.c to project, I used the latest version 9.1.15 which is the same as the rom/miniz.h header.
- - add #include "rom/miniz.h" on top of miniz.c to make use of the pre-configured header for esp32. This #define's out the standard miniz.c fake-header.
- - in miniz.c, comment out all functions contained in ESP32's ROM, namely
Code: Select all
mz_adler32
mz_crc32
mz_free
tdefl_compress
tdefl_compress_buffer
tdefl_compress_mem_to_mem
tdefl_compress_mem_to_output
tdefl_get_adler32
tdefl_get_prev_return_status
tdefl_init
tdefl_write_image_to_png_file_in_memory
tdefl_write_image_to_png_file_in_memory_ex
tinfl_decompress
tinfl_decompress_mem_to_callback
tinfl_decompress_mem_to_mem
The linking goes fine and you should be able to use miniz as expected.
For decompressing a 8,5 kb standard gzip file, miniz with ROM routines takes about 8 ms to complete decompression, while a full zlib implementation takes about 10 ms. (Well, milliseconds are quite unprecise to measure when all you have is a 1 ms tick. This was measured in "debug" configuration.)
I found miniz to be rather greedy regarding malloc'd heap. For a usual inflateInit2(), a total of 43784 bytes is allocated, which is more than I can spend on my project. Most of it (32 k) is used for miniz "LZ dictionary" (#define TINFL_LZ_DICT_SIZE 32768). I'm not an expert on compression algorithms, so I just tuned this down (needs to be a power of 2) and found my decompressed data corrupted.
Zlib works in nice little chunks of about 7 kb, which is more suitable for my and possibly any ESP32 project.
Is there any way to optimize miniz and let it work on statically allocated input/output without a huge heap buffer? I have found none at first try.
Anyway, thanks a lot Sprite & Angus for the quick response and Espressif for creating such an inspiring product. I love it!