6

Has anyone attempted using zlib compression on an MSP430? Do you have any advice on how to compile to library for use in an MSP430 project (I am using IAR Embedded Workbench)?

user1148476
  • 81
  • 3
  • 1
    Do you absolutely need zlib ? or just a compression algorithm ? – Cyan Jan 14 '12 at 10:54
  • http://stackoverflow.com/questions/3203321/lzw-compression-decompression-under-low-memory-conditions – old_timer Jan 15 '12 at 02:08
  • http://stackoverflow.com/questions/3767640/compact-decompression-library-for-embedded-use – old_timer Jan 15 '12 at 02:09
  • I don't actually need zlib, just a compression algorithm that can be used on a embedded platform with somewhat limited memory, and also decoded on a Windows platform with a tool like 7-zip or WinZip. – user1148476 Jan 17 '12 at 16:42

3 Answers3

9

According to MSP430 datasheets and Wikipedia article, you don't have enough RAM (it has at most 16 KiB) even for just sliding window (32 KiB). So, you cannot use any deflate algorithm for MSP430. Considering ZLIB is a just deflate implementation that's true for ZLIB too. Even you try to write your own deflate implementation you cannot succeeded. Because, deflate needs 32 KiB for sliding dictionary and some extra memory for it's huffman trees. That's only for decompression part. For compression, you need extra memory for hash chain match finder which is 7.5 * dictionary size = 240 KiB (according to 7zip's deflate implementation). If you really need compression for that small architecture, I advice to look at custom byte coded LZSS compression algorithms. They're fast and light-weight. But, not strong enough to compete with deflate due to especially entropy coding differences.

Osman Turan
  • 1,361
  • 9
  • 12
  • Good catch on that, saved me some time experimenting. – old_timer Jan 15 '12 at 02:08
  • Keep in mind, most of compression algorithms are resource hungry. Some of them have some trade-off between CPU-power vs. memory (i.e. some uses lots of memory with small amount of CPU power or vice versa). You can even find some algorithms which use up to 13 GiB memory. [Here](http://mattmahoney.net/dc/text.html) is reference benchmark which lists both processing time and memory usage for popular compressors. – Osman Turan Jan 15 '12 at 09:55
  • Right, I know that, it was a case of not knowing how much it was going to want and my approach was to experiment instead of research. Thanks for the link that will be quite useful. – old_timer Jan 15 '12 at 15:16
2

I used to build zlib as a test for processor development but as the world started to transition to 64 bit their haphazard use of unsigned long and unsigned int and mixing without carefully typecasting, etc would wreak havoc on the compilers. It may have settled down now but I walked away from using it.

it does need/want a ton of memory, the msp430 is particularly small on the ram side compared to some of the competition.

I have an msp430 simulator you can use http://github.com/dwelch67/msp430sim. which is easy to configure to have lots of ram, more than you will find in a chip. Althogh zlib may still want the full 64k and not leave you with any. Just need to see what happens. Maybe i will take this on and try it myself as a test for my simulator. On the above simulator or maybe one of my others I have a different compression tool used that has a very (relatively) small memory footprint. Not sure if you need zlib specifically or if you just need some sort of decompression in general.

old_timer
  • 69,149
  • 8
  • 89
  • 168
1

I have built it for a number of targets, not specifically MSP430, but that should not matter. It is all ISO C and dependent only on standard library calls. It uses dynamic memory allocation, so you'll need a heap.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Thanks for your answer. I was able to build a small test program for the msp430 using the deflate algorithm, but ran our of stack space. I'm assuming this has to do with the heap you mentioned. Can you elaborate more on that? – user1148476 Jan 13 '12 at 22:14
  • Stack requirement is a different issue. Normally you will allocate an amount of stack somewhere in your C runtime start-up. If you are using any sort of IDE and project-configuration tool, the is likley an option for that. In some cases the project will allocate all remaining memory after stack and static allocation to the heap, in others you may have to explicitly specify the heap size. Either way, my point about having a heap is merely that you need one. The success of zlib on your target will depend in having sufficient memory in general and supporting dynamic memory allocation. – Clifford Jan 14 '12 at 15:40