嵌入式硬件抽象层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,让系统有机会做一些处理。

3、驱动接口

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

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

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

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 黑客帝国 设计师:白松林 返回首页