我正在研究带宽非常宝贵的 radio 到 radio 通信。这一切都是用金属 C 代码完成的(没有操作系统，小型 atmel 8 位微处理器)。因此，压缩的想法对一些大型但罕见的传输很有吸引力。
我不是压缩专家。我使用命令行工具来缩小文件并查看我得到了多少。多年来与一两个图书馆建立了联系。但从来没有这么低的水平。
在一个示例中，我想在处理器之间无线传输大约 28K。如果我只是对代表性文件执行简单的 bzip2 -9，我得到原始大小的大约 65%。
但我很好奇我是否可以做得更好。我(天真地？)的印象是大多数基本压缩格式必须是一些预先声明的元数据，它描述了如何膨胀随后的比特流。我不知道元数据本身占用了多少空间。我对同一个文件和其他一些文件进行了直方图分析，发现由于所传输内容的性质，直方图几乎总是相同的。所以我很好奇我是否可以在我的代码中对这些频率进行硬编码，以便它不再是动态的，但也不会作为数据包的一部分进行传输。
例如，我对霍夫曼编码的理解是通常前面有一个“字典”，后面是一个比特流。而且如果压缩器按 block 执行，每个 block 都会有自己的字典。
除此之外，它是一个小型处理器，占地面积小，我希望我所做的一切都保持小巧、简单和直接。
所以我想基本的问题是，如果有的话，你会在这种环境/场景中实现什么基本压缩算法。特别要考虑到，您基本上可以预编译每次传输的字节数的代表性直方图。
最佳答案
您所建议的提供预设频率数据的帮助不大。或者更有可能它会受到伤害，因为您会因不使用最佳代码而受到打击。例如，在 deflate block 的开头只需要大约 80 个字节来表示文字/长度和距离霍夫曼代码。稍微增加一点，比如说，压缩数据的 18 KB 就可以很容易地取消它。
与 zlib ，您可以使用 28K 消息中的代表性消息作为字典，在其中搜索匹配的字符串。如果您的消息中有许多公共(public)字符串，这可能对压缩有很大帮助。请参阅 deflateSetDictionary() 和 inflateSetDictionary()。
关于c - 在嵌入式处理器之间使用哪种压缩(已知字节分布)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22207945/