<article class="&#95;2rhmJa" style="font&#45;size&#58; 16px&#59;">

硬件抽象层对下必须检验查看目前硬件配置的能力与限制，以及将来可能的扩展性，对上得倾听系统软件得需求。简单得说，HAL就是我们系统的“硬件”，而“硬件”的功能就是它所提供的API，即所有上层的程序完全不需要知道硬件与驱动程序的细节，只能通过HAL来操控硬件。按照这样的逻辑，通常我们实现HAL的流程如下：

  • 定义HAL的规模(Scope)：根据需求分析上层的系统和应用程序需要哪些硬件功能，这些需求就是HAL必须要包含的基本模块，然后再根据硬件配置，分析是否仍有目前系统没用到的硬件功能，这些功能可能会在下一代产品中实现，我们可以为其设计相应的HAL模块的API，但可以先不实现；

  • 定义HAL API：

    • 系统工程师说明系统需求，包含系统对硬件事件的处理方式。

    • 固件工程师根据硬件功能，提供第一版的HAL API定义文件；

    • 系统工程师协同固件工程师逐一review HAL API。

    • 在HAL API立项前，必须针对项目中的所有软件工程师做详细报告，收集建议，并做必要的修正。

  • 由固件工程师实现所有的HAL的功能，并执行每个模块的单元测试；

  • 固件工程师release第一版HAL库，由系统工程师负责整合测试。

所以HAL不过是驱动程序提供给上层应用的API标准而已。

1、HAL基本设计原则

HAL设计文件是以驱动来区分章节，不同的驱动由不同专长的工程师负责设计与编写。因此设计文件的第一章是HAL基本设计原则，第二章是共享数据结构与常数定义。以下是设计原则：

  • 往前兼容，新版的HAL的API可以变多，但不能减少；

  • HAL旨在对硬件做抽象化，不应与任何系统有直接关系。若OS对驱动有特殊需求(Linux有制式的驱动写法)，应由系统团队根据需求自行在HAL之上再往上包一层high level driver。

  • 驱动模块化，尽量降低驱动间的耦合度。

  • 每个驱动分别设计，但章节内的结构必须保持一致，主要包含以下信息：

    • 数据结构

    • API

    • 控制流程或状态机

    • 会产生的硬件事件，以及事件传递流程

  • 每个驱动模块应该尽量包装以下的API，以保持所有驱动模块的API风格一致：

    • Open()：执行该设备的初始化(包含硬件的初始化、取得驱动所需的buffer、数据结构或配置的设定等)

    • Enable()：驱动开始运行

    • Disable：驱动暂停运行

    • Close()：关掉硬件设备，还回buffer，reset 驱动的数据结构或配置。

    • Set_Power_mode()：设定该设备的power mode(full run、idle、sleep mode),即使该硬件不需要这种电压管理，也要设计出空的Set_Power_mode函数，以保持所有驱动接口的一致性。

  • 驱动与电源管理的配合：驱动仅提供电源管理的机制，而电源管理的策略由系统的power manager 统一管控，即HAL中的每一个驱动模块都必须配合power manager 的需求，例如都必须实现Set_Power_mode() 这样的API。

  • HAL的每个驱动模块都必须遵守共同的命名规则与API风格。

  • 统一定义HAL的系统配置：这些配置必须开放给系统使用，是的本项目不需要的驱动模块或功能不会被连接进来。例如：

<pre mdtype="fences" cid="n249" lang="c" class="md-fences md-end-block md-fences-with-lineno ty-contain-cm modeLoaded" spellcheck="false" style="box-sizing: border-box; overflow: visible; font-family: Monaco, Consolas, "Andale Mono", "DejaVu Sans Mono", monospace; margin-top: 0px; margin-bottom: 20px; font-size: 0.9rem; display: block; break-inside: avoid; text-align: left; white-space: normal; background: rgb(51, 51, 51); position: relative !important; padding: 10px 10px 10px 0px; width: inherit; color: rgb(184, 191, 198); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;"> #include <hal.h>

ifdef HAL_WITH_GPS //HAL_WITH_GPS为HAL配置之一，定义在hal.h中

...

endif</pre>

2、驱动程序与系统的沟通机制

系统与HAL的沟通方式有3种：

  • HAL API：系统可以直接调用HAL开放的API。

  • ISR 与 硬件事件：当硬件产生中断时，相应的ISR会执行；当ISR处理完后，可将硬件事件抽象化，包装成硬件事件，往上层系统传递，传递的方式有：

    • 全局变量flag：当上层程序发现flag的值变化了，即表示发生了某硬件事件。但这种方法的时效性差，且还要注意Critical section的保护；

    • 在ISR内调用系统功能，如send_message()、wakeup_task()等，这是普遍的做法，但破坏了HAL必须与上层系统无关的规范。

    • 好的做法是，HAL不决定传递硬件事件的机制，改为提供API，让系统可“注册”用以传递硬件事件的函数(回调函数callback function)，ISR会在适当时机调用这些函数，至于系统如何处理硬件事件，ISR并不知道。

  • Callback：HAL 提供注册callback function的API，并明确说明调用此callback function的时机。系统只要传入function pointer，HAL即会在上述时机调用这些callback function。例如当HAL准备关机时，会去调用系统预线注册的callback function，让系统有机会做一些处理。

3、驱动接口

我们以HAL里重要的驱动——Audio为例，看一下该驱动的接口。按照设计文件风格规范，必须先描述这个模块中所有的API的关系：

HAL设计文件中的流程图范例
HalAudEn
HalAudDis
HalAudSetSampleRate

获取更多知识，请点击关注：嵌入式Linux&ARMCSDN博客 简书博客知乎专栏

</article>