嵌入式系统开发技术指南

在过去的几年中，我注意到嵌入式系统开发人员和团队之间的趋势非常令人不安。趋势包括开发功能（最好）但不是为生产环境构建或测试的嵌入式系统。这种趋势导致灾难。

这种“简单功能”趋势的主要原因似乎是由于三个因素：利用示例代码，匆忙的开发周期，以及缺乏理解它需要什么构建生产嵌入式系统。利用示例代码的第一个因素实际上是启动嵌入式软件开发的关键一步。示例代码有助于启动和运行嵌入式系统，以及获得对目标硬件的重要见解。许多微控制器供应商为开发人员提供了有关如何设置外设和与微控制器交互的急需的示例代码。

但是，许多开发人员通常不会考虑这个示例代码。首先，示例代码只是一个例子;它不适合生产。它只是如何设置和与各种外围设备交互的指南。然而开发人员将采用代码，一旦将示例代码引入系统，它通常会保留在系统中。

仔细检查来自不同微控制器供应商的示例代码，经常会发现免责声明所提供的代码不能保证适用于任何目的。它甚至不能用于任何目的，而只是“原样”提供。只要阅读免责声明，就应该让嵌入式软件开发人员在考虑采用该代码时感到不安。该软件的制作人没有足够的信心支持他们的榜样，那么是什么让人们认为示例代码产品已经准备就绪？

检查硬件寄存器标志时，通常可以看到功能示例代码的一个很好的例子。图1显示了类似于人们通常会发现的内容。

图1 - 示例代码硬件寄存器标记检查

一个问题使用图1中的代码是 while 循环假设操作最终会成功完成。在理想条件下，这可能是真的，但如果硬件出现故障会怎样？也许振荡器正在漂移，因此无法实现同步。也许写入闪存失败了。当流氓出现故障的外部传感器导致总线停机时，硬件检查可能在通信总线标志上，从而无法完成传输。在这些情况下，使用图1中的代码的结果将是无限循环，需要外部力量（例如看门狗定时器）的干预。即使这样，看门狗定时器也会重置系统，但不能保证系统不会在循环中结束，进入永久复位的永久循环。

为生产环境编写的软件应该适应失败的可能性。某些场景的解决方案（如图1中的 while 循环）可能是基于系统节拍向循环添加超时，或者可能建立最大数字标志检查。这些将阻止系统进入无限循环或永久复位循环。

图2中的示例演示了如何将附加条件添加到 while 循环中，以便系统退出发生故障时的循环。这些添加不是使系统挂起等待救援的无限循环，而是生成错误代码，该错误代码警告调用例程感兴趣的硬件标志已超时。然后，系统可以在不调用最后一个监视器的情况下采取纠正措施。

图2 - 生产代码硬件寄存器标记检查

导致构建功能性而非生产意图嵌入式系统趋势的第二个因素是匆忙的开发周期。开发嵌入式系统会给企业带来巨大的管理成本，这使得企业希望昨天进入市场。此外，初创企业，小型企业和销售团队因乐观地设定生产日期而不考虑开发强大的生产就绪系统所需的实际工作而臭名昭着。许多工程师要么在这种情况下拒绝接受管理，要么他们确实发现他们的担忧被置若罔闻。最终结果是角落被切割以试图满足不切实际的最后期限，这导致设计仅包含仅在一系列非常受控的条件下工作的功能代码。

有助于发布功能性而非生产意图的嵌入式系统的最终因素是缺乏对如何构建生产意图嵌入式系统的理解。嵌入式软件和系统工程师需求量大，供不应求。这种情况导致公司在校外或从不同学科的工程师（如网络或应用程序开发）中担任重要角色。结果是如何正确地构建和实现健壮的嵌入式系统的知识差距，这些嵌入式系统不需要每天更新修补程序错误并修复安全问题。

但是，绿色和跨学科的工程师并非完整的故事，导致人们对生产嵌入式系统的真正缺乏了解。经常会要求训练有素且经验丰富的工程师开发原型或概念证明。为了向管理人员演示，工程师们提供了一个基于功能性示例代码的漂亮功能原型。演示很顺利，但该系统只能在受控条件下工作。但由于演示进展顺利，管理层希望立即运送系统，而不是理解仍需要做很多工作才能使系统生产准备就绪。

嵌入式系统正在进入我们生活的每一个角落。对于在受控条件下操作的一些设备，仅使用功能代码可能是好的。但随着物联网和自主智能社会的快速发展，运输功能而非生产代码的危险趋势是等待发生的事故。