软件中的硬件问题怎样解决比较好

硬件和软件的开发过程似乎有些相似：发布了需求规范；精心设计；结果使用一种特殊的语言进行编码（用于硬件的HDL和用于软件的编程语言）。但是相似之处到此为止。

启动硬件生产时，硬件设计会在某些时候冻结。在此之后进行更改通常会很麻烦且昂贵。另一方面，软件永远不会完成。调整和完善将持续到最后一刻。调整代码并进行重建非常容易。这既是优点也是缺点。

由于软件可以延展性强，因此有机会进行广泛的测试并修复仍然存在的错误。灵活性的不利之处在于，人们倾向于在最后时刻进行增强和完善。“蠕动的优雅”是真正的危险。这些挑战都是与软件相关的，但情况越来越糟……

如果在冻结设计后检测到硬件错误怎么办？

硬件问题通常昂贵且处理不便。一个非常常见的解决方案是“将其修复在软件中”。这样的修复可能是微不足道的，软件工程师应该很高兴能够为他们的硬件同行提供帮助。但是，在其他情况下，对代码的调整可能会完全损害软件设计。

设计中的错误与“怪异”之间存在一定程度的模糊性，“怪异”对于硬件开发人员来说并不奇怪，但需要包含在软件中。我们可以用一些示例来说明软件需要在哪些地方容纳硬件的怪异之处。

翻转位

嵌入式系统中最简单的输入设备是开关或按钮。凭直觉，可以预期处于“关闭”位置的开关（或未按下的按钮）将显示为0值，并在打开（或按下按钮）时转换为1。但是，在几乎所有情况下，情况都是相反的：关闭开关显示为1并转换为0。这是因为它简化了硬件设计，可以将输入引脚“上拉”为逻辑1并将其接地（下拉为0）。 ）表示输入。当然，一旦开发人员对此有所了解，在软件中的容纳就变得微不足道了。

弹跳

关于开关或按钮的另一个自然期望是，它将仅在两种逻辑状态之间转换。但是，机械开关的行为通常不是很理想-触点闭合，然后弹跳开一次或多次，然后降落到闭合位置。此行为的结果是，预期的从1到0的过渡可能会快速连续地重复几次，未经检查，可能会被错误地解释。想象一下按下一个按钮会增加一个设置，但通常会将其增加2或3而不是1！

这可以固定在硬件中，但这要付出复杂性和材料清单的代价。多年来，“修复软件”是最佳的选择，并且已经设计了许多“反跳”算法。

一切都与时机有关

一些复杂的外围硬件可能会响应软件写入寄存器的命令。硬件通过执行一系列动作来响应命令的情况并不少见，在此期间它不会响应其他命令。这不是故障，因为硬件设计人员希望设备以此方式运行。但是，从软件开发人员的角度来看，这似乎是不合逻辑的。

这给软件带来了挑战。需要包括安全措施，以便在发出命令时，必须经过一段适当的时间才能编写另一条命令。在简单的应用中，某种延迟循环可能就足够了。在更复杂的软件中，可能无法在空闲循环中占用CPU，因为还有其他处理要做。在这种情况下，需要更复杂的计时机制。

大端或小端

有多种方式可以表示一个单词（甚至一个字节）内的数据。一个简单的例子是单词中字节的顺序。他们可能是最不重要的第一或最重要的。两种方法都不对，而且不同的CPU历来都是小端或大端的。因此，几乎不可避免的是，链接在一起的两个子系统可能对数据表示有不同的想法。

这是在软件中修复的另一种候选方法，仅字节交换或循环。挑战在于将接口的使用本地化到执行转换的软件的一小部分。

增加功能

除了规避硬件中的错误和怪异之外，以节省成本为名，或者因为该功能在开发过程的后期就被梦想了，可以在硬件中有效实施的功能可以卸载到软件中并不少见。

这是微处理器控制的替代品，用于伺服液压系统上的大型硬接线控制面板。当时，在微处理器中拥有如此巨大的计算能力的想法令人鼓舞，当然，开发人员对此感到迷恋。硬件设计已经完成，并在非常好的时间内冻结，使生产能够按计划进行。在新功能的想法泛滥之前，软件开发一直进展顺利。该软件被迫屈服（即，其实时行为受到损害），因此必须进行重大设计审查。

隐藏硬件问题：驱动程序

长期以来，人们已经认识到，访问和控制硬件对于没有经验的或缺乏经验的嵌入式软件开发人员可能是一个特殊的挑战。结果，出现了设备驱动程序的概念。驱动程序只是一个很小的软件，它封装了使用某些硬件的笨拙并提供了与应用程序代码的合理接口。

它是在驱动程序中容纳了硬件设计的怪癖，理想情况下，应该在其中进行调整以解决意外的功能或非功能。

责任编辑：Ct