最大的嵌入式软件问题是…

嵌入式软件开发人员如今面临许多不同的问题和挑战。关于我所遇到的问题,最大,最鲜为人知的问题之一是开发人员正在编写其软件以取得成功。为成功而写听起来不错,只是我的意思是开发人员在假设没有任何错误的情况下编写软件。他们正在编写的是功能性的原型代码,它们可以在受控的实验室环境中执行而不会出现问题。不相信我吗?在讨论开发人员应该采用的失败观念之前,让我们看看我最近遇到的一个公开示例。

编写成功软件

我想到的例子是,我一次又一次地看到,是我在一个I2C驱动程序中遇到的一些代码,该驱动程序是由一个应为安全关键型应用程序设计的工具链生成的。 I2C驱动程序由“安全”工具生成,并已准备好投入生产。开发人员只需要用必要的地址,读/写位和数据调用驱动程序,一切就可以了。当然有问题。如果要写入的设备无法确认,而无法应答,则代码陷入无限循环,如下所示:

/*SAFETYMCUSW 28 D MR:NA <APPROVED> "Potentially infinite loop found - 硬件 Status check for exeuction sequence*/ 
while ((i2c->STR & (uint32)I2C_TX_INT) == 0U)
{
    
}/* Wait */

设备可能会导致NAK,原因如下:

  • 收到无效的命令
  • 设备尚未准备就绪
  • 设备错误
  • 地址不正确
  • 等等

但是,这个据说安全的驱动程序不允许设备意外崩溃!相反,驱动程序将在此while循环中挂起,陷入无限循环。如果从属设备发生故障或总线出现故障,则整个微控制器应用程序都将挂起,因为驱动程序期望得到永远不会出现的响应!

(顺便说一句,我认为此代码更糟糕的是,已将其识别为潜在问题,并且有人认可可以这样发送)!

编写失败软件

编写软件来处理故障需要开发人员改变他们对软件的看法。开发人员无需专注于“使其成功”,而需要采用“使其失败”或“可能失败的方法”。在这种思维方式下,开发人员不断地在每行代码中问自己:“哪里会出问题?”。这可能导致识别问题,例如:

  • 潜在的无限循环
  • 硬件错误
  • 通信协议响应问题
  • 错误的代码分支
  • 等等

发现潜在问题后,开发人员便可以在软件中采取措施以发现问题,然后进行有效处理。

结论

太多的开发人员正在编写成功软件,却没有考虑到可能出什么问题。他们假设在现场一切正常,就像在实验室工作台一样。结果不仅是质量等级较低的软件,而且当考虑到返工来处理后来在现场发现的故障时,这种软件的开发成本可能更高,而且可能会推迟上市。

2 thoughts 上 “最大的嵌入式软件问题是…”

  1. It’检查每个函数的返回值,检查传递给函数的每个指针是否为null,检查每个参数的范围/合法性等都是非常繁琐的工作,但是如果我们不严格执行这些操作,则我们将自己承担风险(和很多其他的)。

    编码标准和代码审查是实施此问题的好方法…

  2. 我必须同意这是一个主要问题。我最近遇到了类似的问题,但情况稍差一些。由于类似的ACK / NAK问题,代码不仅陷入了无限循环,而且还通过将状态盲目地写入6字节缓冲区并在每次循环中增加指向该缓冲区的指针而使问题更加复杂。结果是它不仅阻塞了RAM,而且破坏了RAM。

发表评论

您的电子邮件地址不会被公开。 必需的地方已做标记 *

该网站使用Akismet减少垃圾邮件。 了解如何处理您的评论数据.