是时候改变一下嵌入式软件开发思维方式了！

作者  Stuart Cording (Elektor)

译者  禾沐

国内嵌入式软件开发一直比较传统，除涉及关键系统外的多数项目，都是在“编程”优先的开发方式驱动下实施的。这背后的原因有很多，除了产品上市压力大、建模和仿真工具价格不菲之外，还有一个重要因素——嵌入式软件开发的思维方式转变需要漫长时间和教育过程才能完成。本篇译文详细阐述了如何改变嵌入式软件开发思维方式，并结合几款很实用的工具和汽车电子实例进行了具体分析。

嵌入式软件开发者们总是喜欢躲开关于软件架构、抽象化、建模和模拟的讨论，直接开始进行编程，而嵌入式软件代码往往一旦发布就不能进行改动了，出错的余地非常小。既然我们都知道测试对嵌入式软件非常重要，也有很多进行建模/仿真的工具，那么，为什么还会先编程，然后等待很久才开始测试呢？

啄木鸟带来的危险

那是一次“原来是这样！”的顿悟。当时正在为了一个培训课程进行准备，我在想，为什么嵌入式软件工程师如此不愿意使用在其他软件开发过程中常见的概念和方法呢？在微控制器相关的工程中，我时常会遇到这样的工程师：他们既不定义代码风格标准（尽管软件开发有多个工程师参与），也不会定义任何帮助提高代码可移植性和可用性的设计准则，更不会关心面向对象设计、建模和仿真。

我的脑海中浮现出了下面这句话：“如果木匠用程序员编程的方法建造建筑，只需要一只啄木鸟就可以摧毁整个人类文明。”这句话从温伯格法则稍微修改而来，它着实引起了我的共鸣。为什么嵌入式软件开发者们不借鉴计算机科学研究成果，使用正确的方式构建代码，或者借力建模/仿真技术呢？

编程太快了吗？

一个原因可能是来自这一代程序员的经历。他们的生涯从资源受限的8位微控制器开始，用汇编语言最高程度地利用硬件的性能是王道，抽象化和工具自动生成的代码只能意味着代码冗余和失去对代码的完全控制。转移到C语言对于一些人来说都有难度，尽管C语言已经非常贴近硬件了。

另一个角度是C语言的教学方式往往注重语法，而不是如何最佳地使用这门语言。但是，就像自然语言一样，精通语法并不能让你成为一位演说家。

物联网（IoT）应用出现以前，升级微控制器的固件基本意味着亲自前往设备的所在地，代码出错的余地非常小。即便如此，许多嵌入式程序员的开发方式也始终没有改变。

推广新的开发方式？

过去，运行在微控制器上的代码往往可以用一个简单的状态机表示，如今微控制器需要解决多维的问题。今天的微控制器可以通过磁场导向控制（FOC）技术对电动机进行换向操作，并同时运行其他任务。虽然相关的代码已经存在，但是，实时确定电动机的角度和计算下次换向的时机就已经非常复杂了。

这样的微控制器如果出现在家用洗衣机中的话，我们还需要考虑IEC 60730标准（自动电子控制 – 第1部分：一般要求）。大多数微控制器厂商会提供能够执行CPU寄存器、程序计数器、内存完整性和时钟测试的“B类”库，库代码应该在运行实时电动机控制的同时执行。系统中一般还会有能快速响应的通讯接口和人机交互界面，嵌入式开发者也许可以保证每个部分都能单独运行，但是整合在一起后系统是否依然可靠呢？

一个选项是用统一建模语言（UML）针对应用进行建模并运行仿真。嵌入式软件开发者往往非常不喜欢这种方式，他们认为这样做是浪费时间：如果有时间建模和运行仿真，还不如直接把代码写出来。一些人还在系统设计中滥用UML，导致UML染上了不好的名声。抽象的设计方式还意味着不同的开发过程，说服一个开发团队转变开发过程并不是一件容易的事情。

对于在设计和实现中各编程一次的担心，我们称为过程的不连续性（phase discontinuity）。理想状况下，建模过程应该解决这一问题，比如实时面向对象建模（ROOM）领域特定语言（DSL）。ROOM专门针对事件驱动的实时系统，它支持建模和模拟，还能够生成针对目标硬件的代码。

ROOM从三个维度描述软件：结构、行为和继承。结构可以用角色（actor）通过端口（p