MSP430 上的 Zlib 压缩

发布于 2024-12-27 07:17:02 字数 93 浏览 2 评论 0原文

有人尝试过在 MSP430 上使用 zlib 压缩吗?您对如何编译到 MSP430 项目中使用的库有什么建议吗(我正在使用 IAR Embedded Workbench)?

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)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

空心↖ 2025-01-03 07:17:03

我已经为许多目标(不是专门针对 MSP430)构建了它,但这应该不重要。它全部是 ISO C 并且仅依赖于标准库调用。它使用动态内存分配,因此您需要一个堆。

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.

年华零落成诗 2025-01-03 07:17:02

根据 MSP430 数据表维基百科文章,即使只是滑动窗口(32 KiB),您也没有足够的 RAM(最多 16 KiB)。因此,您不能对 MSP430 使用任何放气算法。考虑到 ZLIB 是一个简单的 deflate 实现,这对于 ZLIB 来说也是如此。即使您尝试编写自己的 deflate 实现,也无法成功。因为,deflate 需要 32 KiB 用于滑动字典和一些额外的内存用于它的霍夫曼树。这仅适用于减压部分。对于压缩,哈希链匹配查找器需要额外的内存,即 7.5 * 字典大小 = 240 KiB(根据 7zip 的 deflate 实现)。如果您确实需要对该小型架构进行压缩,我建议您查看自定义字节编码 LZSS 压缩算法。它们速度快且重量轻。但是,由于熵编码差异特别大,不足以与 deflate 竞争。

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.

你的他你的她 2025-01-03 07:17:02

我曾经构建 zlib 作为处理器开发的测试,但随着世界开始过渡到 64 位,他们随意使用 unsigned long 和 unsigned int 以及在没有仔细类型转换的情况下进行混合等会对编译器造成严重破坏。现在它可能已经安定下来了,但我不再使用它了。

它确实需要/想要大量内存,与某些竞争对手相比,msp430 在 RAM 方面特别小。

我有一个 msp430 模拟器,您可以使用 http://github.com/dwelch67/msp430sim。它很容易配置为拥有大量内存,比芯片中的内存还要多。尽管 zlib 可能仍然想要完整的 64k 并且不会给你留下任何东西。只需看看会发生什么。也许我会亲自尝试一下,作为对我的模拟器的测试。在上面的模拟器或者我的其他模拟器上,我使用了一种不同的压缩工具,它的内存占用非常(相对)小。不确定您是否特别需要 zlib,或者您是否只需要某种一般的解压。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文