Question about uzlib on microcontrollers on bare metal

pfalcon / uzlib

Radically unbloated DEFLATE/zlib/gzip compression/decompression library. Can decompress any gzip/zlib data, and offers simplified compressor which produces gzip-compatible output, while requiring much less resources (and providing less compression ratio of course).

Other

303 stars 82 forks source link

I want to use uzlib for an arm cortex-m4 mcu, so when I saw your readme had an example size output for a cortex-m4 mcu using the arm toolchain, I got pretty excited. However, I've never actually used the heap on any of my [embedded] projects for anything not running an rtos or gpos. So I've never used malloc, alloc, etc due to memory fragmentation concerns. I saw that you use realloc and I got a little worried.

My question is: When you used this library for your cortex-m4 project, did you notice any issues with memory fragmentation and hard faults as a result? Is there a way for me to get around using the heap entirely?

If using dynamic allocation is required, I think I'm relatively safe because after any compression/decompression is done on the mcu, I'll end up software restarting the device anyways (and hopefully this somewhat resets the heap so there are no more holes maybe??)

I guess this is less of a question about uzlib and more a question about using it on embedded devices. Any advice would be greatly appreciated.

Here is the line I'm talking about: https://github.com/pfalcon/uzlib/blob/6d60d651a4499a64f2e5b21b4cc08d98cb84b5c1/src/defl_static.c#L72

Thanks for your submission. However there was no (further) activity on it for some time. Below are possible reasons and/or means to proceed further:

Please make sure that your submission contains clear and complete description of the issue and information required to understand and reproduce it (exact version of all components involved, etc.). Please refer to numerous guides on submitting helpful bugreports, e.g. https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Please make sure that your feature request/suggestion/change aligns well with the project purpose, goals, and process.
If you face the issue you report while working on a community-oriented open-source project, feel free to provide additional context and information - that may help to prioritize the issue better.
As many open-source projects, this project is severely under-staffed and under-resourced. If you don't run a community-oriented open-source project, and would like to get additional support/maintenance, feel free to request a support contract.

Thanks for your understanding!

pfalcon / uzlib

Question about uzlib on microcontrollers on bare metal #42