硬件抽象层(HAL)改变项目的5种方式

更新时间: 2024-05-14 10:25:56来源: 粤嵌教育浏览量:559

嵌入式软件开发人员通常避硬件抽象层(HAL ),声称它们会降低性能并增加代码复杂性。是,当开发人员采用HAL时,供应商提供的HAL通常不抽象硬件,仍然保证与硬件的紧密耦合。毕竟,一个真正抽象的HAL将使嵌入式开发人员能够立即使用任何供应商。然而,使用或开发你自己的HAL会在很多方面影响你的软件。在本中,我们将探索5HAL可以改变你的软件项目的方式。

 

方式1–硬件独立性

开发人员通常有一个最喜欢的微控制器供应商。通常是第一次编写嵌入式软件的供应商或者熟悉的供应商。和其他人一样,我也有自己的爱好,但是依赖他们的HAL或软件库来编写软件可能是危险的。比如你突然拿不到他们的微控制器怎么办?你必须选择一个新的供应商,然后重写,测试,甚至认证你的产品。那不算快也不算便宜!

 

使用一个好的HAL将允许你编写更易移植和可重用的独立于硬件的应用程序代码。对于许多嵌入式团队来说,这是一个巨大的转变。例如,可以使用供应商A运行代码,并通过更改版本中的标志,为供应商b编译代码。硬件独立性使可以灵活地使用任何想要的硬件,并消除对微控制器供应商的依赖。

 

如果喜欢使用供应商提供的HAL,只要回顾几个基本特性,这是可以的。首先,HAL必须是一个真正的HAL。这意味着必须有一个定义好的接口来打破对硬件的依赖。接下来,HAL应该与实现分开定义。最后,应该能够快速换出接口调用的函数。如果你没有这三样特性,那么你就没有硬件独立性你有硬件依赖!

 

方式2——实现自动化单元和集成测试

释放价值和转变软件开发的关键从使用HAL开始。HAL进一步支持额外的转换,比如支持自动化单元和集成测试。嵌入式开发人员经常纠结于单元测试,因为他们编写的代码会接触到硬件。这意味着你必须在微控制器上运行你的测试。当你有了一个合适的HAL,你仍然需要在目标上测试你的驱动,但是你所有的应用程序代码突然被释放了!的应用程序代码现在可以在独立于硬件的主机上进行单元和集成测试。

 

将硬件从等式中移除并将测试转移到主机有利于开发人员。首先,它更快。不必担心器件的缓慢擦除和写入周期。其次,不需要担心的测试工具有多大或者有多少测试。只需首先在主机上测试所有应用程序代码,而不是尝试在微控制器上运行的代码和测试。接下来,转移到非目标测试使可以利用持续集成甚至持续部署。其结果将是越来越快地发现缺陷,降低成本,提高质量。

 

方式3–执行脱靶模拟的能力

使用一个好的HAL将硬件排除在等式之外时,它允许将任何实现放在它后面。这意味着可以为的目标、的测试工具和模拟环境提供一个实现!在许多情况下,嵌入式软件开发人员必须在硬件可用之前开始编写软件。因此,虽然我们可以使用开发板开始,但有了一个好的HAL,我们可以在我们的应用程序代码上运行模拟!

模拟应用程序代码对开发人员来说有很多好处。首先,它允许他们更快地在客户面前获得应用程序代码。我们都知道客户喜欢改变主意,并且在体验产品之前很难想象产品的工作方式。模拟可以帮助客户了解产品并更快地提供富有成效的反馈,从而减少开发周期后期昂贵且耗时的更改。

其次,模拟允许在没有硬件的情况下测试故障和其他异常行为,从而实现更强大的测试。例如,让传感器行为不当或在目标处理器上强制硬件异常通常具有挑战性。在模拟环境中,这不是问题。

 

方式4–更快、更高效的调试

在目标上调试时,每次进行更改时,都会有一个交叉编译、擦除闪存、编程闪存和运行应用程序的循环。根据应用程序的不同,即使使用专业工具,整个过程也可能需要相当长的时间。使用HAL来分离应用程序可以更快地调试代码!在主机上,编译和运行周期要短得多。这意味着开发人员可以更快地解决问题,然后在必要时在他们的硬件上测试最终调试版本。

如果允许HAL提供的其他转换实现,将使用单元测试来驱动开发,这意味着甚至可以花更少的时间进行调试。将只编写通过测试的代码。你的软件将会以小增量的方式编写,测试会一直验证它。如果你破坏了什么东西,回归测试会立即发现它。其结果将是更快、更有效的调试

 

方式 5–上市时间和成本降低

使用HAL开发嵌入式软件的最终转变是降低成本和缩短上市时间。HAL在嵌入式软件中创造了大多数团队做梦都没有想到的灵活性。可以很容易地看到,如果可以快速获得客户反馈,将在开发周期的后期减少返工。此外,如果可以消除调试,那将是巨大的好处!大多数团队平均花费20-40%的开发周期进行调试!也就是每人每年2.4-4.5个月!这都是因为使用了一个HAL来测试的应用程序代码并减少调试时间。

随着上市时间的缩短,成本显然会降低。为了确保开发周期顺利进行,在HAL开发、测试工具和其他工具方面肯定有投资。然而,这些成本通常比节省的成本低一个数量级。

免费预约试听课