嵌入式代码验证很棘手，尤其是在处理 PIC 等资源有限的部分时。由于部件的内存限制以及在这类设备上进行的通常“实时”编程，您通常无法在测试用例中进行编码。

以下是我的一些指导方针：

1. 如果没有，请编写规范：如果您没有根据规范进行编码，请记录您的代码应该做什么，什么是有效输入，什么是预期输出，每个例程应该花费多长时间，什么可以得到什么不能得到重创等 - 操作理论，流程图，任何东西总比没有好。

2. 评论你的代码：仅仅因为某些东西对你来说是显而易见的并不意味着它对其他人来说是显而易见的（或正确的）。对于审查和代码的可维护性，简单的语言注释是必要的。

3. 防御性代码：不要只包含正常输入的代码。处理丢失的输入、超出范围的输入、数学溢出等 - 您的代码设计覆盖的角落越多，部署时代码的自由度就越少。

4. 使用静态分析工具： PC-lint 之类的工具可以在你的代码中找到多少错误，这可能会让你感到羞愧。将干净的静态分析运行视为认真测试的良好起点。

5. 同行评审是必不可少的：您的代码应该干净且有足够的文档记录，以便独立方可以有效地对其进行评审。在门口检查你的自我，认真考虑提出的任何批评或建议。

6. 测试是必不可少的：您应该进行自己的验证，并对代码进行独立验证。其他人可以以您无法想象的方式破坏您的代码。测试你能想到的每一个有效条件和每一个无效条件。使用 PRNG 并输入垃圾数据。尽你所能破坏事物，然后修复并重试。如果幸运的话，您将能够在调试模式下运行代码并查看寄存器和变量 - 如果没有，您需要巧妙地切换 LED / 数字信号以了解您的状态设备。做任何必要的事情来获得你需要的反馈。

7. 深入了解：不要害怕查看 C 编译器生成的机器代码。你可能（会？）找到你漂亮的 C 代码已经被炸成几十个甚至几百个操作的地方，其中一些应该是安全的（因为它只是一行代码，对吗？）需要很长时间才能执行多个中断已解雇并使条件无效。如果某些东西变得非常低效，请重构它并重试。

大多数用于在 PC 上创建可靠软件的相同技术也适用于嵌入式开发。将您的算法与特定于硬件的代码分开，并使用单元测试、模拟、静态分析和 Valgrind 等工具单独测试它们会很有帮助。这样一来，只在硬件上测试的代码就会少得多。

我不会放弃 C。虽然像 Ada 这样的语言可以提供一些小的保证，但很容易陷入认为该语言的承诺比它实际做的更多的陷阱。

MISRA-C 对于提高一般代码质量和最小化错误确实非常有用。只要确保您阅读并理解每条规则，它们中的大多数都很好，但其中一些没有任何意义。

这里有一个警告。MISRA 文档假定读者是具有广泛 C 语言知识的人。如果您的团队中没有这样的 C 经验老手，但决定使用静态分析器，然后盲目地遵循给出的每个警告，则很可能会导致代码质量下降，因为您可能会降低可读性并意外引入错误。我已经多次看到这种情况发生，将代码转换为 MISRA 合规性并非易事。

有两个版本的 MISRA-C 文档可能适用。要么是 MISRA-C:2004，它仍然是当前嵌入式行业事实上的标准。或者支持 C99 标准的新 MISRA-C:2012。如果您以前从未使用过 MISRA-C，我建议您实施后者。

但是请注意，工具供应商在说他们进行 MISRA 检查时通常会提到 MISRA-C:2004（有时他们甚至会提到过时的 MISRA-C:1998 版本）。据我所知，对 MISRA-C:2012 的工具支持仍然有限。我认为到目前为止只有一些静态分析器实现了它：Klocwork、LDRA、PRQA 和 Polyspace。可能更多，但您肯定需要检查它支持的 MISRA 版本。

在决定之前，您当然可以先阅读 MISRA 文档并了解它的含义。它可以从misra.org以 10 英镑的价格购买，与 ISO 标准的价格相比相当实惠。

Mathworks（MATLAB 人员）有一个名为Polyspace的静态代码分析工具。

除了静态代码分析、lint 等，我建议仔细定义和设计接口（带有正式的审查过程）和代码覆盖率分析。

您可能还想查看安全关键代码设计指南，包括 MISRA、UL1998 和 IEC 61508 标准。