怎么在PIC18上计算32位CRC？

CRC32似乎有点过分了。我记得在AN1229http://ww1.micro..com/downloads/en/AppNotes/90003128A.pdf中看到过CRC例程。

由于数据块大小为135KB，CRC32可能被认为不够强和足够好。这取决于需求。回到最初的问题，是的，在PIC18上是完全可能的。由于计算时间不是很关键，你可以看一下多重乘法算法。它是最简单和最小的一种。

对于CRC32，非表方法将是慢的，但将工作。表方法将更大。

谢谢你的回复。前面省略的另一条信息是，我将以64字节的组接收所有新数据（EEPROM的页面大小，然后在接收下一组64之前将其写入EEPROM）。基于这些响应，我认为应该能够在接收数据的整个过程中保持滚动CRC计算，然后在最后进行比较。另一个选择是将所有的数据输入EEPROM，然后执行CRC计算。所以我想知道在数据进入时进行滚动计算是否更好，或者等到所有数据都加载到EEPROM之后再读取并执行CRC计算？一种方式比另一种方式好得多，或者它们是相同的，只是一种偏好的问题？

你正在询问你的程序的时间安排。如果你在等待某件事情的同时做计算，那会加速这个过程。否则，这无关紧要。

好的，谢谢。

还有一点是检查一个所谓的CRC残值。对于一个给定的发电机多项式，它总是一个固定的值。使用什么CRC计算算法取决于可用的资源和性能要求。它们都是等效的检测误差。注意到最近的研究发现CRC表现不太好。我不完全知道你的目标，但是对于你的数据块大小，我建议使用MD或SHAHASH。

“注意到，最近的研究发现CRC的表现不如什么？”用什么数据？什么样的交通工具？什么数据大小？什么多项式？”我建议使用MD或SHAHASH。“但是对于您的数据块大小”64字节的CRC-32？在PIC18上？你知道那些更大更慢。它们可能不适合。

@NKurzman，看看这个articleusers.ece.cmu.edu/~koopman/./dsn02/dsn02_koopman.pdf这里有更多关于CRC研究的文章，hereusers.ece.cmu.edu/~koopman/pubs.htmlOne more-google forschrodinger crc.在这里张贴链接是一种痛苦。

对不起，您的链接没有张贴。离开HT T PI知道哈希是优越的。对于一个32位CPU可能是合理的，但是记住你的十六进制文件有一个16位校验和。十六进制文件行是8位校验和。

我强烈反对以上观点。这取决于对错误检测率的要求。CRC可能无法在大数据块上提供足够高的错误检测率，并且数据完整性可能无法用给定的错误检测率来保证。

此外，还没有发现CRC多项式能满足12K位消息的HD=6和64K位以上的消息长度的HD=4的新需求。大数据块是否为0.5比特？这是所有的数学和概率。这就是为什么存在这么多不同的CRC多项式。即使是哈希也有其局限性。TCP/IP使用的是16位校验和。英特尔十六进制是8位校验和。SMBus是8位CRC。“给定错误检测率可能无法保证数据的完整性。”没有错误是不存在的。包括数据总线，用于从PIC向EEPROM获取数据。如果数据总线如此重要，则需要对其进行评估。如果需要散列，则使用PIC32。他可以尝试发送数据，然后反转数据。然后将数据返回给主机以确保数据是空的。在PIC18上执行SHA将驱动项目，假设它完全适合。然而，到PIC的代码传输将通过16位校验和来检查。为什么是的，我与一些想要在PIC16上执行SHA的人进行了这个对话。您建议的问题是，您永远不能将数据传输到8位CPU。但是它每天每毫秒都完成。校验和CRCs并没有过时。

什么是时间要求和PIC18的时钟速度是什么？我在一个PIC16F1XXX上做了4K字节的CRC-32 K（K为Koopman），在不到一秒钟的情况下，FoSC＝8 MHz。它足够快，所以我从来没有精确地计时，但我猜32k字节大约需要2秒钟，所以可能是1/4秒。我开发了三个版本：无表（位）、16条目表（Nibble）和256条目表（字节）。这些版本可以称为小、中、大（或最慢、慢、中等）。我最终使用的是没有表版本，因为我可以适应~600节点项目中的所有不同的MCU，而且我有宽松的时间要求。这是相当严格的汇编语言。不幸的是，我不能自由地发布代码，但这是一个存在的证明。我用CRC捕获了FLAKEY闪存。正如其他人所说，要真正评估什么是适当的错误检查代码，除了块大小之外，还需要知道BER和HD要求。Koopman的工作（我认为这是好的）表明，（对于CRC）特定大小（#位）和多项式对于给定大小是最佳的取决于块长度以及BER和HD。您还必须考虑可用的循环和字节。

所有：我在P16F1XXX上测量了CRC代码的小版本和大版本的性能。这包括用于lt＝256字节的循环控制。来自模拟器的周期/字节是（包括分支/调用/返回开销周期）：小（慢速）：223个周期/字节。大（中速）：50个周期/字节。在我的casethat中，不包括将Flash读入文件存储器。代码大小（包括大版本的表）是：.:60Code。总共60个指令。大：34代码+（0x404=）1028个表。总共有1062条指令。对于“大型”版本，表是在PC上预先计算的，因此多项式是固定的，表是闪存的。一些“调整”可以节省时间，但它会使代码更“可读”（它已经是汇编程序了），可能更大一些，所以我不打算做任何修改。我没有测试媒体（慢速或半字节）版本（4×16字节表，使用NbBLE作为表索引）。我猜想这个尺寸大约是150个指令，时间大约是160个周期/字节。我稍后可以测试一下，但是其他的鱼现在在煎锅上。这是PIC16LF1527，但是我希望所有16(L)F1xx家族成员具有相同的时间和大小。

GlennP，我很高兴看到其他人知道Koopman对CRC的研究。你知道其他类似的研究吗？MD和沙怎么样？我似乎没有找到任何关于使用MD/SHA进行数据完整性检查的良好而可靠的信息，但是人们普遍认为MD/SHA更好。多少钱？细节是什么？你知道其他方法吗？其他有用的散列等？谢谢！

Bambur：我不是纠错码的专家。我在维基百科的CRC文章中找到了库普曼的参考文献，这是一个很好的起点。在与Phil进行了非常短的电子邮件交换之后，我在我的一些消息软件中使用了一个依赖于长度的多项式选择：一个8位多项式用于1-3字节，另一个多项式用于4-9字节。这是由于他（以及他的学生）在嵌入式系统的短消息中穷尽地搜索多项式。OP的扫描是不同的。他就像“验证你的闪光”问题-数千字节。我不认为有人做了详尽的搜索，尽管有一些分析（我并不真正理解）。我只是使用CRC-32 K来进行闪存检查。我相信MD和SHA都比CRCs长。但它们计算起来更昂贵，尤其是在没有乘法或除法H/W的单片机上。在具有密码硬件的单片机上，您可能会认为威廉希尔官方网站 比CRC更先进。截至2004年，MD5的使用已被贬值，请参阅MD5维基百科页面。类似地，SHA-1家族现在被认为是弱的，SHA-2，特别是SHA512，现在被认为是对数字签名的良好保护。根据记录，SHA-2是由美国国家安全局（NSA）开发的，取之不尽。验证文件没有被破坏或替换与验证通信或存储有些不同，因为后者的攻击是随机的，不是针对性的。看看SHA-2Wikip。edia条目：https://en.wikipedia.org/wiki/SHA-2。最后，正如线程的另一个分支中所说的那样，您必须使错误检查威廉希尔官方网站 与问题的特征以及解决方案可用的资源相匹配。我用Koopman的两个CRC-8多项式作为我的短信，用CRC-32K作为闪存检查。--[在某个话题上]几年前（就在MD5的缺陷被揭露之前）我的任务是在非常庞大的文件集合（想想云存储）中找到重复的文件（相同的内容）。在没有那么多的研究之后，我决定了一个非常小的假阳性的可能性，如果我做了512位的散列和比较。最后我做了两个，一个是MD5（128位），另一个是Sa512（512位），都来自微软.NET库。[这是一个Windoz项目。]由于库类可用，我没研究如何编写代码，尽管我确实理解了几分钟的威廉希尔官方网站 。搜索按长度分组文件的副本，然后组合散列匹配长度的任何文件。如果它们仍然匹配，则将文件逐一进行比较。最后，我们删除了逐位的比较，因为我们从来没有发现非相同文件的匹配散列。我计算使用80字节（640位）的散列进行错误散列匹配的概率足够小，大约是1/（2^640）或大约1/（4.56x 10^192）。[宇宙中大约有10个80个原子——可能多达10 ^ 82个]。

GlennP，非常感谢你的回复！我也通过维基百科找到了Koopman：在我看来，验证传输或存储的数据本质上是相同的。我们被告知CRC简单而健壮，这种情况持续了很长一段时间，直到最近的研究通过大量搜索。我很惊讶，我们对这个问题关注得如此之少，同时每辆车都有几十个微控制器和计数，而我们在计算能力和资源受限的嵌入式系统方面却没有得到很大的发展。OP，将存储在EEPROM中的数据划分成更小的块，计算并存储多个CRC（每个小块）可能是个好主意。这样，您可以显著增加捕捉错误的机会，同时保持代码复杂性基本相同。

这不是刚刚发现的新问题。如果有人告诉你CRC捕捉到了一切，他们总是被误导。每个CRC多项式都是为在系统中工作而设计的。不同的硬件有不同的故障模式。你指出的论文并没有说CRC32是不好的。它说一个特定的多项式在那个应用中更好一些。“验证发送或存储的数据本质上是相同的。”“不发送数据的故障将不同于故障闪存的故障模式。这意味着嵌入式程序员应该知道接收的数据可以。偶尔是坏的。应该检查接收的数据是否会发生错误、破坏性或将导致测试无法检测到的故障。SHA1散列可能被破坏的事实不会影响坏数据意外地为不同数据提供相同散列的可能性。计算机现在更强大这一事实并没有改变数学。

Koopman指出的一点是，许多嵌入式系统中提出的CRC多项式对于特定的应用不是很好，因为它们最初是为长消息设计的。IIRC他指出了一些例子，例如用于梯队的LonTalk的代码。他还指出了其他几种情况，其中CRC与较长数据块一起工作良好，在短消息系统中使用，它们绝对是次要的。我把两者混为一谈，只是因为我喜欢用于签名和错误检查的一种实现。虽然CPU速度是旧代码变得更加脆弱的一种方式，但更重要的问题是更好的攻击已经被开发。