固件工程师可以从软件工程师那里学到什么？

我很惊讶今天如何实践类似的固件开发，就像 25 年前我们第一次开始使用 C 进行嵌入式开发一样。C 是汇编程序的一大进步，但是固件工程师可以并且应该学习更多的经验教训。是的，有些工具更好，但是许多实践都停留在 70 年代和 80 年代。

嵌入式软件开发确实在非嵌入式开发人员面临的挑战之上增加了一些额外的挑战。但是熟练的软件开发人员使用的所有原则和实践都适用于嵌入式开发。顺便说一句:不仅仅是嵌入式软件开发人员没有掌握这些最先进的实践，还有许多非嵌入式软件开发人员。

我认识并遇到过做固件的人，总的来说是一个非常熟练的团队，致力于解决困难的问题。不幸的是，无论出于何种原因，许多人都没有跟上软件世界的发展。我认为这与固件工程师竖起的假想障碍有关。

嵌入式和非嵌入式开发人员使用不同的语言，但解决类似的问题。保持嵌入式代码于硬件设备与保持应用程序代码于 UI 或数据库基本相同。基本原理是相同的。

以下是我认为嵌入式开发人员应该更加注意的一些事情。其中一些原则和实践可以直接使用，而其他原则和实践可能需要一些调整来应对嵌入式挑战。如果您想在下面用固件一词代替软件，请继续，我并不真正区分两者。

依赖关系管理

必须管理模块之间的依赖关系。从软件到硬件的依赖关系是一种特殊情况，必须由嵌入式软件开发人员主动管理。如果您不管理依赖关系，它将管理您。

实际上，这意味着只有软件模块的有限子集应该了解底层硬件（和操作系统）。随着硬件的发展，而且总是如此，可以保留对硬件代码的投资。请参阅我的ah ha!时刻。

Robert Martin 撰写了大量关于 SOLID 设计原则的文章。嵌入式开发人员应该了解它们并将它们应用到他们的设计中。

单一责任原则

O-Open 封闭原则

L-Liskov 替代原理

I-接口隔离原理

D 依赖倒置原理

这些原则导致设计更好地经受住时间的考验。SOLID 原则鼓励创建内聚和的模块。它们建立在面向对象的思想之上，但可以应用于 C。我们必须停止在嵌入式 C 代码中非常普遍的函数调用数据结构。

C++ 和 OO 语言

为什么你不能使用 C++ 和 OO？因为它们太慢，或者太大了。事实是什么？C++ 是一种巨大而神秘的语言，但你不必全部使用。看看Why are you still using C?

C ++ 弥补了一些 C 没有帮助的问题，例如：

封装和信息隐藏

编程到接口

可替换对象

临时初始化

C ++ 可以有效地用于嵌入式开发。好吧，您确实需要一个 C ++ 编译器和净空。也许这在您的世界中是不可能的，或者可能是开展业务的成本。从学习开始：

类-这些是具有成员函数和成员数据的结构。

构造函数-这些使得有可能得到初始化的权利，所有的时间。

析构函数-如果你学习构造函数，你也必须学习析构函数来保持宇宙的平衡。

继承-主要用于定义仅包含纯虚函数的接口。接口提供重要的依赖关系中断和灵活性点。这些通常在嵌入式中不受欢迎。这里不应该有任何神秘或偏见；虚函数是引擎盖下的函数指针。有效使用接口的替代方法是复杂的条件逻辑，嵌入式 C 程序通常有太多的东西。

如果嵌入式开发人员使用 C ++ 的这些部分，他们可以构建更灵活的设计，而不会产生高成本。

测试驱动开发

这可能是最大的游戏规则改变者。我很高兴看到其他帖子也提到了它。TDD 可以帮助防止现在和将来的缺陷。要了解为什么 TDD 可能会有所帮助，请查看The Physics of TDD。

嵌入式确实给 TDD 带来了一些独特的挑战。例如，TDD 需要极快的增量编辑 / 编译 / 链接 / 运行周期。对于许多嵌入式开发人员来说，这意味着要小心依赖关系管理，并首先在目标上运行单元测试。请参阅有关adapting TDD for Embedded的更多信息。

使用 TDD，您将创建经过全面测试的代码。全面的自动化测试覆盖充当安全网，允许在需求更改时安全地更改代码。立即发现意外后果。

此外，具有you get almost for free的测试，允许您无畏地重构您的代码...

连续重构

代码只写了一次，但读了很多次。然后它被改变和调整，导致设计随着时间的推移而退化。如果开发人员不不断重构以保持代码干净，它就会变成一团糟。也许你们中的一些人正在处理这种混乱。TDD 的自动测试实现了低成本和低风险的重构。

持续集成

自动化您的构建过程。让它在每个工作区签入时运行。这是一个挑战，通常需要异构工具集才能将编译后的代码放入目标，但这仍然是正确的目标。

嵌入式开发人员越早知道更改与其他一些工作不兼容，修复的速度就越快，花费在痛苦的合并上的时间就越少。

增量交付

找到拆分工作的方法，这样就可以避免大量痛苦的集成，并且可以尽早尝试设计思想。避免沿着架构线拆分，专注于交付可见功能的切片。

协作

嵌入式开发人员！离开那里的立方体，一起工作。当你只看到自己的代码时，你怎么能变得更好？当你是技术专家 XXX，已经掌握了它，没有机会在不同领域工作时，你怎么能改进。

那里有很多东西要学。你有责任尽力而为吗

我既是嵌入式软件工程师，也是软件开发人员。在这两个世界中，我都了解到，无论您的系统拥有多少资源以及您正在编程哪种语言，都有许多事情可以使您的生活更轻松。

首先是您正在使用的工具。在嵌入式软件中，您大多数时间只处理编译器 / 链接器。不止这些。Diff 工具，正则表达式脚本语言，文档工具为您节省了大量时间。

另一件事是代码质量。人们需要遵循风格惯例，经历定期的重构周期，并且通常要记住，代码读取比代码编写更频繁，并且拥有更可读的代码确实是值得的。

在嵌入式软件中，有时我们会完全错过设计阶段。嵌入式项目通常不像桌面 / 服务器项目那么大，但这并不是没有进行正确设计的借口。

软件需要自己测试，而不仅仅是作为设备的一部分。它真的节省了大量的时间来构建你的系统的软件模拟器，只是为了测试软件符合要求的规格。当整个事情、硬件和软件都准备好的时候，这样做要贵得多。

源控制

单元测试 (TDD)

持续集成（或夜间构建）

Bug 跟踪

与我一起工作的固件工程师不做任何这些。

单元测试可能不适用于所有类型的固件。当它在物理硬件上运行时,我想象它更难进行单元测试。我想这取决于你是否有可用的模拟器。

假设“固件工程师”的意思是“嵌入式软件工程师”，那么我的答案是：他们是软件工程师，所以他们应该-在可能的情况下-做与任何其他软件工程师相同的事情。

显然，为嵌入式系统编写软件需要一些不同的技能，例如对目标处理器的详细了解，以及能够处理有限的资源（与 PC 或类似设备相比）。

正如其他人提到的，单元测试是复杂的，因为这可能必须在 PC 上运行的模拟器上完成，这虽然非常有用，但永远不能替代对真实系统的彻底测试-特别是考虑到嵌入式系统所受事件的异步性质。

关于为什么嵌入式软件似乎“落后于曲线”，我担心的一个问题是，因为软件工程 — — 以及作为其中一部分的嵌入式软件 — — 通常没有深入地教授电子工程学位。考虑到现在电子工程师的职业生涯中有多少可能花在编码上，这似乎是一个巨大的疏忽。

幸运的是，有些人试图弥补这一点。我强烈建议您阅读 Jack Ganssle 的文章（关于his website，以及他在embedded.com上的常规专栏）。

此外，MISRA-C是在不久前创建的，旨在避免汽车行业 C 软件中常见的错误来源，此后，嵌入式软件世界中的许多人都采用了它。添加像PC-Lint这样的静态分析检查器，您已经在某种程度上改进了代码。

工具供应商也没有帮助，在许多情况下，通过创建自己的 IDE，也许最好专注于编译器和调试器，并将 IDE 留给其他人，例如 Eclipse。

顺便说一句，有关在嵌入式系统中不使用 C ++ 的更多信息，请参见this question。

最后：因为固件工程师是软件工程师，我们面临许多相同的问题，挑战和担忧，所以我们应该使用相同的资源;毕竟，有很多，你正在阅读其中之一！

我经常访问的其他一些网站包括：

Stack Overflow blog和播客

一个不同的Stack Overflow blog;这是一个专用于嵌入式系统。

编辑：为了回应 Gabe 的评论，“我们应该寻找哪些工具来适应？”，我想到了几个例子：

于编译器的 IDE：C 有plenty of IDEs，但据我所知，没有兼容的编译器，它们中很少有可以发挥其潜力的。

在没有兼容的编译器的情况下，我希望能够使用 PC-Lint（或等效）作为我选择的 IDE 的“”编译器。

仿真和建模：像Simulink这样的仿真工具可以对 PC 和一些高端嵌入式处理器的软件进行仿真，建模和测试。这样的工具对于较小的芯片同样有用，因此很高兴看到它们扩展到该市场领域。

PS：Jack Ganssle 本周的专栏标题为“What makes embedded different?”，因此（大致）与上述问题有关。