Embedded WinZip

Anybody know of freely available source code suitable for embedded system which will allow WinZip-type compression/decompression ?

Reply to
Adrian Morgan
Loading thread data ...

Do you need actually PKZip/WinZip compression or will any sort of good compression do?

Check out

formatting link
either way -- they say "check out one of the source directories for a possibe way to do PKZip-type files", and its the free-for-everything (not-GPLed) standard compression library anyway.

--
Alex Pavloff - remove BLAH to email
Software Engineer, ESA Technology
Reply to
Alex Pavloff

Adrian Morgan wrote: : Anybody know of freely available source code suitable for embedded system : which will allow : WinZip-type compression/decompression ? :

I suppose you've never heard of "google" as in

formatting link

I'll be nice though, and show you this:

formatting link

Perhaps in the future, you could try using a search engine first.

(this one could be tricky though, if you search for 'winzip' instead of 'pkzip' or 'zip')

--buddy

--
Remove '.spaminator' and '.invalid' from email address
when replying.
Reply to
buddy.spaminator.smith

Look at the infozip project.

--
Regards,
Andras Tantos
Reply to
Andras Tantos

Hi Adrian ;). Fancy meeting you here...

Steve

formatting link
formatting link

Reply to
Steve at fivetrees

My target micro is a H8/510.

Preferably PKZip/WinZip for ease of compatability but if there's no libraries for this target and no source then a "proprietary" method will do as long as it achieves good compression results.

Reply to
Adrian Morgan

What are you being compatible with? Are you writing to a disk or something that will be take out of your embedded device and stuffed into a PC? That's the only way I can see that PKZip/WinZip compatibility would be an issue.

zib runs on many platforms is the basis for PNG, and is far from proprietary.

--
Alex Pavloff - remove BLAH to email
Software Engineer, ESA Technology
Reply to
Alex Pavloff

Now that you have some answers bear in mind that all those compressors require hefty local storage for compression. Decompression generally requires about 4k extra bytes or so.

If this is a problem, look into other methods, such as simple repetition coding and adaptive Huffman. Adaptive arithmetic compression will probably be far too slow.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

I think for the "shifting window" class of algorithms (WinZip type), more local storage you use, better compression ratio you get. You can adjust that window size to fit the local memory, and experiment to see if the compression ratio is acceptable.

Another issue is FLASH memory reliability, a bad bit in a compressed block will ruin rest of the block. We run embedded application with compression (experimentally) in high temperature environment, and FLASH memory reliability is a major concern.

CW

Reply to
QBA Technologies

Have a look here

formatting link

Maybe you'll find something that meets your needs.

Regards,

Maciek.

Reply to
Maciej Sawicki

You have something that the authors of general-purpose compression routines don't have: knowledge of the format of your data and of your storage and performance constraints. Something using packed-BCD for numerics, pre-assigned tokens for text elements, and run-length encoding for repeated characters would be microcontroller-friendly (small code footprint and no (relatively) huge tables) and might provide "enough" compression.

--
Rich Webb   Norfolk, VA
Reply to
Rich Webb

You're very likely confusing things here, in several ways.

1) The compression is in no way tied to WinZip --- WinZip just happens to be the most widely known (and illegally copied) program using that file format or compression method on the most widely used platform. 2) That format has two things: archival of many files into a single one (the ".zip" file format), and compression of a file (the "deflate" algorithm), which are quite independent of each other. Are you sure you even need .zip files? Otherwise, what you need isn't a workalike of winzip, but just the zlib --- others already posted URLs of it. 3) You give no rationale why deflate should be the compression method of choice for your particular usage. Depending on your hardware platform and memory availability, "deflate" may be impossible to implement, or almost so. Or horribly inefficient on your particular data. M.F.X. Oberhumer's compression methods, or other, much simpler ones than deflate, may be a lot better for your application, which you failed to even mention so far.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

system

It might be worth reading "The Data Compression Handbook". It explains the concepts of compression (lossy and lossless) and comes with example sources, you could adopt to your system. Some time ago I have modified the LZSS algorithm described in the book to efficiently work on a Hitachi H8/534 (an old 8 bit CPU).

- Rene

Reply to
Rene

system

It's worth noting that infozip make all their code available using very liberal licences, allowing its code to be freely embedded in other applications. And you can be sure of compatibility with WinZip - WinZip uses InfoZip as its engine.

Reply to
David Brown

that

That makes no sense whatsoever - Flash memory performance and reliability at high temperature is always a concern, and compression makes no difference in that, at least for code. A few bits error in reading a compressed stream is a disaster - but so is a few bits error reading uncompressed code. It's a different matter if the stored data is a picture, or some text, but if you have reliability concerns about using the flash for code then you have two choices - implement some sort of error correction system, or change storage technology.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.