我现在已经进入嵌入式领域一段时间了，似乎与我交谈的大多数程序员似乎都在做与15年或更久前相同的事情：Waterfall（ish）开发，命令行工具和一个小组使用lint。
将此与服务器/桌面环境进行对比，在服务器/桌面环境中，似乎有许多与编程的各种方面相关的活动：
嵌入式环境是否使实施新实践或工具变得更加困难？ 是mindset of embedded programmers使他们远离新的工具/概念吗？ 与IT专注领域相比，典型嵌入式行业的管理是否落后于曲线？
我确实认识到这是一种概括，一些嵌入式项目确实使用了Scrum，Agile，CI，Automated Builds（实际上我在一家自80年代开始实施的公司工作）。但我的印象是这个比例非常小。
答案 0 :(得分：14)
我们已经习惯了这样一个事实：我们的台式机偶尔会崩溃（或者桌面上的应用程序至少会突然消失）。这没什么大不了的。下一个补丁将修复它。
在嵌入式空间中，您正在构建无法修补的内容。生命可能取决于您的设备（在汽车，电梯或医疗系统中）。大多数设备都已安装，然后必须无人值守多年。因此，嵌入式人员往往非常保守。 TCP / IP通常“太现代”。他们坚持使用可靠的串行总线，通信“堆栈”大约有50行汇编代码。
更糟糕的是，您只是在设备上没有足够的空间，这意味着您无法使用最新的编程语言之一，这使得TDD和自动化构建了幸福。
接下来，许多嵌入式开发环境都是专有的。如果您的供应商不支持它，您将无法获得它。 Linux在过去几年开始削弱它，但是很多设备还不足以运行Linux。即使它们是这样，CPU功率也将被用于其他东西而不是运行带有源的花哨操作系统。
所以是的，有强大的力量在后台工作，以保持嵌入空间的位置。
答案 1 :(得分：13)
嵌入式开发人员是否比桌面开发人员更保守？
是的，因为他们更关心犯错误的后果。修补嵌入式设备是一件大事。与桌面应用程序无关。
瀑布式开发在嵌入式世界中是必要的，因为您通常在与软件同时构建硬件。你需要尽快知道多少内存，多少处理器速度，多大的闪存，如果需要什么特殊硬件等等......硬件设计无法完成，直到你知道这些答案。一旦你决定，那就是它。重做电路板的交付时间太长了。如果你陷入困境，那么软件将不得不解决任何缺点。通常不是理想的情况。
至于工具，这主要取决于供应商提供的内容以及开发人员的任何偏见。在某些项目中，我使用了XP Embedded，并获得了桌面开发人员所获得的所有内容。
XP，Scrum，Iterative，Lean / Agile：
由于大部分设计是预先完成的（必要时），并且在编码时通常没有工作硬件，因此快速周转过程实际上并没有带来太多好处。
持续集成/自动构建 很高兴，但不是真的有必要。什么......打开IDE并按下编译按钮大约需要15秒。
自动单元测试
没有理由不应该这样做，但只有部分代码可以真正自动测试，因为另一部分要么依赖于硬件，要么具有其他依赖性，如时序。因此，无法通过自动化测试确定代码是否正常工作。
重构工具支持
嵌入式处理器产品的供应商是处理器。它们提供IDE支持以鼓励您购买处理器。他们无法支付Visual Studio规模的开发团队的费用，以便为IDE添加所有的花里胡哨，甚至不是他们的产品。
答案 2 :(得分：6)
我能想到的一些原因：
答案 3 :(得分：4)
嵌入式程序员大多是电气工程师，而不是计算机科学家或软件工程师。
他们在专业领域表现出色。与大多数计算机程序员相比，它们带来了更慢的方法。在编程固件时，电气工程师知道这很危险。
以下是我注意到电气工程师在C中所做的一些事情：
在他们的辩护中，EE并没有培养成为计算机程序员，这不是他们的工作。我认为软件是创建嵌入式设备最难的部分。设计PCB和选择组件需要技巧，但与10,000行代码的复杂性相比相形见绌。
嵌入式程序员还必须处理外观和行为类似于90年代IDE的IDE。
答案 4 :(得分：3)
这部分是规模问题。软件不是产品，产品是产品。然而，有数千种不同类型的微控制器和微处理器，最受欢迎的千位有3-4种不完全兼容的不同编译器。
因此，一个给定的工具只会被几百或几千名工程师使用。
然而，在Windows开发中，有数百万级别的程序员 - 这些工具直接生成软件产品，因此它会获得更多的眼球和更多的钱。
工程师推出的每个新产品可能都有不同的处理器。
嵌入式程序员通常是软件或固件工程师，而不是程序员。工程意味着在实现之前需要进行一定数量的设计，设计分析和设计验证 - 换句话说，在编写第一行代码之前就完成了大量工作，理想情况下，文档的具体程度足以使实现仅仅转向伪代码就像文档一样编译成可编译的代码。
设计阶段需要新的工具和概念，而不是实施阶段。具有intellisense的IDE可能很不错，但是在编写代码时它是无用的 - 他们已经知道他们需要什么。
CAD - 计算机辅助设计 - 正在为固件工程师开发工具，这些工具在设计阶段用于开发直接转换为代码的模型和模拟。 Matlab和simulink就是很好的例子。整个系统都是设计好的。
事实上，人们可能想知道为什么软件开发人员仍在编写代码，而工程师正在制作数据/程序流程图和状态机图表。为什么UML在应用程序领域的使用速度如此之慢？听起来应用程序开发人员可以使用嵌入式系统工程师常用的一些工具......
实际上，情况恰好相反。项目启动时，工程师必须选择处理器。
处理器制造商在旧芯片上获得的资金更少，因此他们推出了最新和最好的芯片，并且它们总体上比以前设计中使用的芯片更便宜（通过缩小芯片，更多集成等）。
所以设计实际上是使用最新最好的芯片。
缺点是编译器和工具通常不成熟。它们只能在旧工具上构建如此之多，并且由于目标随每个新处理器而移动，因此它们无法专注于应用程序员可能喜欢的许多优秀功能。特别是因为其中许多功能对嵌入式工程师没有用处。
还有很多其他因素，其中一些是其他答案所列举的，但它们实际上是一个不同的领域，即使它们都涉及编程。
- 亚当
答案 5 :(得分：2)
我还想在这里补充几点：
答案 6 :(得分：2)
我同意这里写的很多内容：
没有花里胡哨的旧工具（由于C / C ++的预处理程序指令，可用的重构次数要少得多）（选择单元测试框架而不是简单地使用JUnit需要很长时间）。
瀑布确实更有效率。如果我要打开引擎盖并进入一个难以进入的地方，我会尽可能多地做我在那里的事情，而不是在每个任务刚刚打开后退出和关闭引擎盖它再次。首先创建最重要的功能的想法允许您在承诺而不是迟到时选择运输也很难掌握当您认为什么都不是可选的时，这可能是真的。但是，当最后期限出现时，IME总是变得不必要了。
对系统的可见性降低会使重新访问现有代码以重构或更改功能变得更加危险。通常存在时序问题，使用存根和模拟在主机上运行的自动化测试将无法捕获。被这些问题困扰的人可能很难采取不同的观点。
我还要再加一个;敏捷/ scrum的语言是工作站程序员的术语。对于只知道足够的C来完成工作的嵌入式开发人员来说，什么是类，对象或方法？当“用户”通常被视为物理人员点击和键入，并且产品没有人员用户界面时，很容易将该想法视为不适用。这可能会随詹姆斯格伦宁即将出版的关于TDD in C的书而改变。我一直在阅读测试版电子书，而且非常好。
答案 7 :(得分：1)
我会说它缺乏好的工具集。当您想要将C ++用于C（模板，命名空间，面向对象等）中没有的编译时功能而不是其运行时功能（例外，虚拟功能）时，这真的很令人沮丧 - 但设备制造商和放大器;第三方只给你一个C编译器，而不是C ++。这可能更多地来自市场规模（数以亿计的运行Windows的PC，数十万甚至数百万的开发人员 - 数十万的Chip X，数百或数千的开发人员）而非设备功能。 / p>
编辑：w / r / t健壮性：那里有不同的市场。汽车/电梯/航空/医疗设备市场必须严格要求摆脱虫子。其他市场（玩具，MP3播放器和其他消费电子产品）可能不那么严格，特别是如果可以在现场升级代码。 （“哎呀！我们很抱歉删除了你的音乐库！我们刚修好了这个bug，你可以在方便的时候在我们的网站上获取最新版本！”）
答案 8 :(得分：0)
我会说不同类型的问题环境。
瀑布式方法的最大问题是需求发生变化。在我所处的每个环境中，至少存在需求变化的可能性，这意味着成功的方法是尽可能保持灵活性的方法。即使客户签了血，如果他提出改变就会放弃他的左手，将来会有变化。
在嵌入式编程中，可以预先确定需求。它们来自整个系统的行为，工程师擅长确定系统要求。没有人会进入中途并说用户现在希望心脏起搏器在接收者跳舞时提供切分脉冲。
一旦要求被冻结超过解冻，这在人类使用的软件中从未发生过，瀑布是一种非常有效的方法。团队从明确的要求到整体设计，然后是详细设计，然后编码，验证阶段正确完成的方式。然后是时候调试代码了（因为它在编写时从来都不是完美的），最后的测试是为了确保代码符合要求。
答案 9 :(得分：0)
我还认为某些领域本质上是保守的。例如，运输业，火车和飞机的寿命可能超过30年。客户往往需要经过尝试的真实实践，可能来自IEEE。瀑布是客户所知道的，瀑布是客户的需求。