嵌入式开发人员比桌面上的Brethrens更保守吗?

嵌入式开发人员比桌面上的Brethrens更保守吗?

是的,因为他们更关心犯错误的后果。修补嵌入式设备是一件大事。对于桌面应用程序来说没什么。

滨水开发 在嵌入式世界中是必要的,因为您通常与软件同时构建硬件。您需要尽快知道有多少内存、处理器速度、闪存有多大、如果需要任何特殊硬件怎么办等……在知道这些答案之前,硬件设计无法完成。一旦你决定了,就差不多了。重做电路板的交货期太长。如果你搞砸了,那么软件将不得不解决任何不足之处。通常不是理想的情况。

至于 工具 这在很大程度上取决于供应商提供的内容和开发人员的任何偏见。在一些项目中,我使用了xp embedded,得到了桌面开发人员几乎所有的东西。

XP、Scrum、迭代、精益/敏捷:

由于大多数设计都是预先完成的(根据需要),而且在编码时,您通常没有工作硬件,因此快速周转过程并不能真正提供很多好处。

持续集成/自动化构建 很高兴有,但不是真的必要。打开IDE并按下编译按钮大约需要15秒钟。

自动单元测试

没有理由不应该这样做,但只有部分代码可以真正地自动测试,因为另一部分依赖于硬件或具有一些其他依赖项,如计时。因此,您不能真正判断代码是否通过自动化测试工作。

重构工具支持

嵌入式处理器产品的供应商是处理器。他们提供了IDE支持,以鼓励您购买他们的处理器。他们不可能为一个Visual Studio大小的开发团队支付费用,以便将所有的钟声和哨声添加到甚至不是他们的产品的IDE中。

我们都习惯了这样一个事实:我们的台式电脑偶尔会崩溃一次(或者至少桌面上的一个应用程序突然消失)。没什么大不了的。下一个补丁将修复它。

在嵌入的空间里,你正在建造一些无法修补的东西。生活取决于你的设备(在汽车、电梯或医疗系统中)。大多数设备都已安装,然后必须在无人看管的情况下运行数年。所以嵌入式的人往往是非常保守的。TCP/IP通常“太现代”。他们坚持他们的信任串行总线与通信“栈”,大约是50行汇编代码。

更糟糕的是,你只是没有足够的空间在设备上,这意味着你不能使用最新的编程语言之一,使TDD和自动化构建一个幸福。

接下来,许多嵌入式开发环境是专有的。如果你的供应商不支持,你就得不到。在过去的几年里,Linux已经开始削弱这一点,但是很多设备的功能还不足以运行Linux。即使是这样,CPU的电源也会被用于其他用途,而不是运行一个附带源代码的高级操作系统。

所以是的,有强大的力量在后台工作,以保持嵌入空间的位置。

我可以想到以下几个原因:

• 嵌入式团队通常比桌面/Web团队小。代码基数较小。
• 系统测试比单元测试更重要。软件需要与硬件一起测试。自动化测试是不可能的,只能应用于代码库的一小部分。
• 嵌入式工程师与软件工程师有着不同的技能。他们与硬件交互,知道如何使用示波器和逻辑分析仪。通常,他们工作的困难部分是在硬件上发现故障。他们没有时间采用现代软件方法。

嵌入式程序员大多是电气工程师,而不是计算机科学家或软件工程师。

他们擅长他们的专业领域。他们带来的方法比大多数计算机程序员更慢,更有条理。当涉及到编程固件时,电气工程师知道的就足够危险了。

以下是我注意到的电气工程师在C中所做的一些事情:

• 一个文件中的所有代码
• 类似数学的变量名:x,y,z
• 无压痕或缺失压痕
• 无标准注释标题
• 完全没有评论
• 评论太多

在他们的辩护中,EE没有被训练成计算机程序员,这不是他们的工作。我想 软件 是创建嵌入式设备最困难的部分。设计pcb和选择组件需要技巧,但与10000行代码的复杂性相比就相形见绌了。

嵌入式程序员还必须处理外观和行为与90年代的IDE类似的IDE。

• MPLAB
• AVR Studio

仅仅是嵌入式环境使得实现新的实践或工具变得更加困难吗?

部分是规模问题。软件不是产品,产品是产品。然而,那里有成千上万种不同类型的微控制器和微处理器,最受欢迎的一千种有3-4种不完全兼容的编译器。

所以一个给定的工具只能被几十万个工程师使用。

然而,在Windows开发中,有数以百万计的不同层次的程序员——这些工具直接生产软件,这就是产品,因此它将获得更多的眼球和更多的资金。

工程师推出的每种新产品可能都有不同的处理器。

是嵌入式程序员的思维方式引导他们远离新的工具/概念吗?

嵌入式程序员通常是软件或固件工程师,而不是程序员。工程意味着在实现之前要进行一定数量的设计、设计分析和设计证明——换句话说,在编写第一行代码之前要做大量的工作,并且文档(理想情况下)足够具体,以至于实现仅仅是将类伪代码的文档转换为可编译的代码。

设计阶段需要新的工具和概念,而不是实现阶段。一个带有智能感知的IDE可能很好,但是当代码被编写时,它已经是无用的了——他们已经知道他们需要什么了。

CAD-计算机辅助设计-正在为固件工程师开发工具,在设计阶段用于开发直接转化为代码的模型和模拟。Matlab和Simulink就是很好的例子。系统总体设计。

事实上,有人可能想知道为什么软件开发人员仍然在编写代码,而工程师们正在制作数据/程序流程图和状态机图表。为什么UML在应用程序领域的应用如此缓慢?听起来应用程序开发人员可以在嵌入式系统工程师中使用一些常用的工具…

与以IT为中心的领域相比,曲线背后的典型嵌入式行业中的管理层是否存在?

事实上,这很可能是相反的。当一个项目开始时,工程师必须选择处理器。

处理器制造商在旧的芯片上得到的钱更少,所以他们推销最新和最好的芯片,而且总体上比以前设计中使用的芯片更便宜(要么是通过模切、更多集成等)。

所以设计实际上使用了最新和最棒的芯片。

缺点是编译器和工具往往不成熟。他们只能在旧的工具上构建这么多,而且由于目标随每个新处理器一起移动,所以他们不能专注于应用程序程序员可能喜欢的许多好的特性。尤其是因为这些特性中的许多对于嵌入式工程师来说都是无用的。

还有许多其他因素,其中一些因素是由其他答案枚举的,但这确实是一个不同的领域,即使它们都涉及编程。

-亚当

我还将在这里添加几点:

• 一般来说,嵌入式项目往往比桌面项目小。这减少了对非常详细的软件过程的需求。
• 嵌入式项目的需求通常是精确的,并且定义得更好。因此,Scrum和敏捷不是那么重要
• 最后,嵌入式项目通常是软件和硬件的混合。软件只是项目的一部分嵌入式开发人员在软件过程中投入的时间更少。

我同意这里写的很多内容:

• 没有铃铛和哨子的旧工具(由于C/C++的预处理器指令(如果有的话),可用的重构更少)(选择单元测试框架与简单使用JUnit的耗时)。

• 瀑布确实感觉更有效。如果我要打开引擎盖,进入一个难以接近的地方,我会尽我所能在那里做,而不是退出和关闭引擎盖后,每项任务只是再次打开它。当你认为没有什么是可选的(这可能是真的)时,首先创建最重要的特性可以让你在承诺的时候选择发货而不是迟到的想法也很难理解。然而,当最后期限迫近时,时间总是变得不必要。

• 对系统的可见性越低,重新访问现有代码以重构或更改功能的风险就越大。通常存在定时问题,使用存根和模拟在主机上运行的自动测试无法捕获。对于那些被这些问题折磨的人来说,采取不同的观点是很困难的。

• 我再加一个;敏捷/scrum的语言是工作站程序员的术语。对于一个只知道足够C来完成工作的嵌入式开发人员来说,什么是类、对象或方法?当“用户”通常被视为一个物理的人点击和输入,并且产品没有人用户界面时,很容易忽略这个想法,因为它不适用。这可能会随着詹姆斯·格雷宁即将出版的关于 TDD in C . 我一直在看贝塔电子书,它很好。

我会说它更缺乏好的工具集。当你想使用C++的编译时特性,而不是C(模板、命名空间、对象定向等)而不是它的运行时特性(异常、虚拟函数)时,这是非常令人沮丧的,但是设备制造商和第三方只给你一个C编译器,而不是C++。这可能更多地是由于市场规模(运行Windows的电脑有数亿台,有数十万甚至数百万开发人员,而X芯片有数十万或数十万开发人员)而不是设备功能。

编辑:w/r/t稳健性:存在不同的市场。汽车/电梯/航空/医疗设备市场将不得不严苛处理这些问题。其他市场(玩具、MP3播放器和其他消费类电子产品)可能不那么严格,尤其是在有可能升级该领域的代码的情况下。(哎哟!很抱歉,我们删除了您的音乐库!我们刚刚修复了这个bug,您可以在方便时在我们的网站上获取最新版本!”)

我会说不同的问题环境。

瀑布方法的最大问题是需求的变化。在我所处的每一个环境中,至少存在需求变更的可能性,这意味着成功的方法论是那些尽可能长时间保持灵活性的方法论。即使客户已经签了血,如果他建议改变,他将失去他的左手,将来也会有改变。

在嵌入式编程中,可以预先确定需求。它们来自于整个系统的行为,工程师擅长确定系统需求。没有人会说用户现在想让起搏器在接受者跳舞时传递切分脉冲。

一旦需求冻结在解冻之外,这在为人类设计的软件中是永远不会发生的,那么瀑布是一种非常有效的方法。团队从明确规定的需求开始到总体设计,再到详细设计,再到编码,一路验证各个阶段是否正确完成。然后是时候调试代码(因为它在编写时永远不会完美),并进行最终测试以确保代码符合要求。

我还假设有些领域天生是保守的。例如,运输业,火车和飞机的使用寿命可能为30年左右。客户往往需要经过实践检验的真实做法,这可能来自于IEEE。瀑布是顾客所知道的,瀑布是顾客所要求的。