从我对固件工程工具，实践等历史的了解来看，它一直落后于软件工程领域几年。例如，据我所知，在固件世界中，关于C ++是否真的值得用于我们的应用程序仍然存在相当多的争论，并且一些C ++编译器显然不存在（微芯片？！？）。我想在很大程度上这是由于固件和软件之间的要求不同。再次，从历史来看，经过适当审查的工具和技术进入固件世界似乎只是时间问题。
现代软件工程师经常使用哪些方法，工具，最佳实践等，固件工程师是否也可以利用它们来改进他们的工艺？
具体来说，我正在考虑以下几个方面（但不要让他们限制你）：
我也很乐意看到嵌入式商店回答或评论答案，以提供有关理论可行性或更好的个人体验的反馈。
更新
我特别感兴趣的是稍微跳过曲线。所以相对较新的东西已经过相当好的审查（适用于大多数人），比如C ++，TDD等。你一直用什么来爱？
更新2
到目前为止，我在答案中得到了很多很好的通用编程建议，这很好，但我真的在寻找更多非传统方法，这些方法已经证明对人们来说是成功的。我正在试图挑逗敏捷实践者，TDDers以及那些尝试过东西的人，看到它在黑桃中得到回报或者失败可怕。作为一名软件工程师，您在过去几年中采用的工具或实践产生了非常积极或消极的影响吗？
答案 0 :(得分：22)
答案 1 :(得分：15)
我曾兼任嵌入式软件工程师和软件开发人员。在这两个世界中，我已经了解到，无论你的系统拥有多少资源以及你编程的语言，都有很多东西可以让你的生活更轻松。
首先是你正在使用的工具。在嵌入式软件中，您大多数时间只处理编译器/链接器。还有不止这些。差异工具，正则表达式，脚本语言，文档工具为您节省了大量时间。
另一件事是代码质量。一个人需要遵循样式约定，经历定期的重构周期，并且一般都要记住，代码阅读比代码编写更频繁地完成，并且拥有更易读的代码确实是值得的。
有些时候，我们完全错过了嵌入式软件的设计阶段。嵌入式项目通常没有桌面/服务器项目那么大，但这并不是没有做好设计的借口。
软件需要自行测试，而不仅仅是设备的一部分。它确实为构建系统的软件模拟器节省了大量时间，仅用于测试软件是否符合所需规格。当整个事物，硬件和软件准备就绪时，这样做要昂贵得多。
答案 2 :(得分：7)
我曾与之合作的固件工程师不做这些。
单元测试可能不适用于所有类型的固件。当它在物理硬件上运行时，我更难以对其进行单元测试。取决于你是否有可用的仿真器。
答案 3 :(得分：5)
假设“固件工程师”是指“嵌入式软件工程师”，那么我的答案是：他们 软件工程师，所以他们应该 - 尽可能 - 做与其他任何事情相同的事情软件工程师。
显然，为嵌入式系统编写软件需要一些不同的技能，例如目标处理器的详细知识，以及能够处理有限的资源（与PC或类似的相比）。
正如其他人所提到的，单元测试很复杂，因为这可能必须在PC上运行的模拟器上完成，虽然非常有用，但它永远无法替代真实系统的全面测试 - 特别是考虑到嵌入式系统所受事件的异步性。
我对嵌入式软件看起来“落后于曲线”的原因之一是因为软件工程 - 以及嵌入式软件的一部分 - 通常不会深入讲授电子工程学位。考虑到现在电子工程师的职业生涯中有多少可能用于编码，这似乎是一次大规模的疏忽。
幸运的是，有些人正在努力弥补这一点。我强烈建议阅读Jack Ganssle的文章（在his website上，以及embedded.com上的常规专栏）。
此外，MISRA-C是在不久前创建的，旨在避免汽车行业C软件中常见的漏洞来源，并且他自从被嵌入式软件世界的许多人采用。添加像PC-Lint这样的静态分析检查器，您已经在某种程度上改进了代码。
工具供应商在很多情况下也没有帮助创建自己的IDE，或许最好集中精力于编译器和调试器，并将IDE留给其他人，例如蚀。
顺便提一下，有关嵌入式系统中不使用C ++的更多信息，请参阅this question。
最后：因为固件工程师是软件工程师，我们面临许多相同的问题，挑战和顾虑，所以我们应该使用相同的资源;毕竟，周围有很多，你正在阅读其中一个！
我经常使用的其他一些网站包括：
编辑：为了回应Gabe的评论，“我们应该寻找哪些工具来适应？”，我想到了几个例子：
独立于编译器的IDE： C语言有plenty of IDEs，但据我所知，如果没有兼容的编译器，很少有人可以使用它们。我希望看到编译器开发人员和IDE开发人员融合，理想情况下，任何编译器都可以与任何IDE一起使用。
如果没有兼容的编译器，我希望能够使用PC-Lint（或等效的）作为我的“官方”编译器和我选择的IDE。
仿真和建模：Simulink等仿真工具允许对PC和一些高端嵌入式处理器进行软件仿真，建模和测试。像这样的工具对于较小的芯片同样有用，所以很高兴看到它们延伸到市场的这个区域。
PS：Jack Ganssle本周的专栏名为“What makes embedded different?”，与上述问题（松散地）相关。答案 4 :(得分：3)
不确定什么程度的软件被视为固件（BIOS，驱动程序或实用程序），但我听到的标准投诉是UI是非标准的。认识到UI很重要并且它应该遵循一些标准或传统将是件好事。
就C ++而言，犹豫不得进入它是可以理解的，因为与C相比，它有很多开销.C几乎就像是一个带有libc的汇编语言，而在C ++中，即使是一个简单的函数调用也可以是虚拟的。鉴于语言的复杂性，实现完整的C ++运行时并不容易。
在软件开发“最佳实践”方面列出的内容太多了（我讨厌这些话）。为什么不从The Joel Test: 12 Steps to Better Code.
开始乔尔测试
- 您使用源代码管理吗？
- 你能一步完成构建吗？
- 你做日常制作吗？
- 您有错误数据库吗？
- 你在编写新代码之前修复了错误吗？
- 你有最新的时间表吗？
- 你有规格吗？
- 程序员是否有安静的工作条件？
- 你使用钱可以买的最好的工具吗？
- 你有测试人员吗？
- 新候选人在面试时是否会编写代码？
- 您是否进行走廊可用性测试？
答案 5 :(得分：2)
固件工程非常广泛。从PIC到DSP，它们都具有不同程度的物理资源。这些天DSP非常强大（与CPU相差5年左右），可以支持大量的内存等。但是你再次拥有可以运行几千字节的PICS。程序员的资源越来越少，必须使用巧妙的黑客技术来充分利用设备。而重点是“让它工作”，而不是“写出优雅的代码”。
我希望看到的是包含代码和文档的优秀项目管理工具，因为您需要参考大量数据表，分散在网络中的设计文档以及电子邮件blob等。
我还希望看到更好的用于DSP的开发工具（TI：请将CCS交给一些善于制作IDE的人），还有更多的库制造商使用C ++（我正在看你的ATEME）来构建更好的库。
而且硬件工程师也可以更好地理解面向对象而不是脱口而出，“如果它是C ++就会变慢”。
答案 6 :(得分：2)
首先让我在你的问题中解决一个假设。假设嵌入式软件工程师（ESE）不了解或不了解现代软件工程实践，需要学习新的实践。应立即抛弃这一假设。我相信你会发现ESE的统计分布相同，他们将技能和技术作为非嵌入式SE保持最新。
所以，也许你的问题变成了一系列问题，如：
以下段落回答了这些问题。
ESE通常使用特定的代码编辑器，因为它是个人偏好，或者是他/她公司使用的代码编辑器。 IDE并不常见，因为ESE与硅密切配合，并非所有芯片制造商都为其芯片系列开发IDE。只有实现最高市场渗透率的芯片（如ARM）才有足够的动力来保证基于IDE的工具的开发。此外，IDE不会像对桌面开发人员那样为ESE提供尽可能多的帮助。 IDE为GUI提供粘合或为大型API提供代码完成提供帮助;这些都不是嵌入式世界中常见的或标准的。
我确信有更好的文章说明为什么C在嵌入式系统中优于C ++，而不是现场弥补。缺点是你使用的是有效的。 C工作并且更常见（更多的程序员知道C而不是C ++）。另一个原因可能是OO方法被设计为通过将解决方案抽象为可管理的概念对象来帮助程序员解决大问题。在嵌入式领域，问题通常被解决为尽可能小的问题（和解决方案），以便通过使用更小的代码库使嵌入式系统变得更可靠。
ESE的实验较少，因为嵌入式产品通常必须比桌面程序更不容易出错并具有更高的可靠性。这意味着严格应用经过充分验证的实践，并将更多时间用于测试。为什么？因为通常没有可行的路径来升级嵌入式设备的固件;由于更新数百万台设备的成本，由于系统部署无法实现或难以置信，因此要么不可能。
总之， ESE使用最适合其需求的工具和实践，就像非嵌入式SE一样。作为一个实践ESE，我相信嵌入式软件学科与我的非常相似ESE的朋友相信它是。因此，编程实践的明显差异不是ESE需要学习现代实践的问题，而是非ESE需要了解嵌入式编程的不同之处。
答案 7 :(得分：2)
自动化测试
不要直观地扫描您的模拟输出以检查一切正常。您需要全面的自动化测试，因为您总会错过大量波形中的某些内容。
版本控制
你不会记得什么是工作版本。使用版本控制软件，以便您知道如何使用该板编程。
错误跟踪
你迟早会忘记。错误日志应包含首次检测到问题的版本（请参阅版本控制）以及修复该版本的版本。
哎呀我认为你的固件与FPGA相同，但嵌入式软件也是如此。如果你已经有了这些流程，那么在完成基础知识之前，别忘了unconventional approaches。
答案 8 :(得分：0)
这可能有点脱离背景 对Embedded，
的固件列的简短引用我总是在Embedded上找到关于固件工程的好文章 也许很多人对这个问题感兴趣...