我正在寻找一种在微控制器上编码相对容易/快速的前向纠错码；解码将在 PC 上完成，因此可能会更复杂。
我对纠错码了解不多，除了简单的汉明码之外，它们似乎都比我能处理的更复杂。
有什么建议吗？
编辑：我会缩短事情并接受卡尔的回答......我想有两件事我没有提到：
(1) 我并不严格需要纠错，这对我来说只是有利的，而且我认为可能有一些纠错算法可以以最小的成本获得合理的收益。汉明码可能非常合适，即使它们看起来对我的编码应用程序来说成本太高。
(2) 比纠错本身更大的优势是能够正确地重新同步到跟随错误的数据包。（如果我长时间不同步，那很糟糕）所以我认为保持简单会更好。
我还没有完全弄清楚你能负担得起多少开销。在您的评论中，您说 16 位错误检测/纠正代码是正确的，但您没有指定您正在考虑将其附加到多大的块。为了有意义，您可能应该将允许的开销表示为百分比。64 位数据的 16 位纠错与一千字节数据的 16 位纠错有很大不同。
如果你能负担得起 15-20% 左右的开销，你可以使用带有 Viterbi 解码器的卷积码。这是高度不对称的——卷积编码器非常简单（基本上是一个移位寄存器，输出抽头通向异或）。一个非常大的寄存器可能会使用一个 16 位寄存器和六个左右的 XOR。
幸运的是，您有一台重型计算机来处理解码，因为 Viterbi 解码器可能是可怕的野兽。特别是当您使用更大的编码器来减少开销时，解码器的大小会爆炸式增长。解码器的大小与代码组的大小成指数关系。
提到了 Turbo 代码。与带有维特比解码器的卷积码相比，它们可以更好地利用可用带宽——但它们使用的编码器要复杂得多——至少需要两个特定类型的卷积编码器（递归系统卷积编码器）。因此，它们似乎也不符合您的规范。
纠错码的问题在于，它们可以让您从单个或 2 位错误中恢复，但通常无法检测或修补重大损坏。
因此，我的建议是将您的数据流分成块（最多 1 KB、10 KB、... 1 MB）并计算每个块的校验和。然后，当数据到达另一个 CPU 时，您可以确定它是否正确，如果不正确，则请求重新传输该块。所以接收计算机要么确认并等待下一个块，要么否定确认并期待重新发送。
是的，我们在这里实现了 TCP/IP 的一个子集。但是这个协议如此成功是有原因的：它有效！
对于校验和，我建议使用 CRC-32。它需要一个（我认为）256 个 32 位数字的表和一些相当简单的计算（主要是数组索引、OR 和 XOR），因此对于“愚蠢”的 CPU 来说计算相当容易。
我建议使用基于数据包的前向纠错形式。如果您必须发送六个等长的数据包，请为每个数据包发送足够的信息以将其识别为“6 个数据包 1”、“6 个数据包 1”等，以及另一个数据包，其第一个有效负载字节是 xor数据包 1-6 的第一个有效负载字节，其第二个有效负载字节是数据包 1-6 的第二个字节的异或，以此类推。接收到总共七个数据包中的任何六个数据包的代码将能够重建丢失的数据包。作为一个轻微的改进，对“偶数”数据包使用一个“奇偶校验”数据包，对“奇数”数据包使用另一个。如果你这样做，系统将能够从任何不超过一个数据包的突发错误中恢复。