姓名：李萌怡  学号：19020100103  学院：电子工程学院

转自：https://blog.csdn.net/liangzc1124/article/details/110382038

【嵌牛导读】：在了解了硬件抽象层的概念后，需要对它的设计实现也有一定了解。本文对硬件抽象层的设计实现做了简要介绍。

【嵌牛鼻子】：HAL 

【嵌牛提问】：实现HAL的流程是怎样的？

【嵌牛正文】

硬件抽象层对下必须检验查看目前硬件配置的能力与限制，以及将来可能的扩展性，对上得倾听系统软件得需求。简单得说，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，让系统有机会做一些处理。

————————————————

版权声明：本文为CSDN博主「Leon_George」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/liangzc1124/article/details/110382038