国庆假期，学习新技术，拒绝再做一个书呆子，从操作系统开始（三）

总结：操作系统一直被认为是计算机软件的基础。 本系列是学习操作系统的系列笔记。 操作系统就是一个例子。 其他操作系统也是如此。 设备驱动程序分为多个级别。 下表列出了各个级别的驱动程序初始化声明宏定义以及系统启动时的启动顺序。

我的老板说我需要提高我的技能，而不仅仅是一个粗鲁的男孩。 所以我精挑细选，最终决定学习操作系统。 因为操作系统一直被认为是计算机软件的基础。

这个系列是关于学习操作系统的。 操作系统以AliOS Things为例。 其他操作系统也是如此。

本文主要讨论操作系统的设备驱动模型。 稍后我们将详细讨论操作系统。

国庆假期学习新技术，拒绝再做一个笨蛋，从操作系统中的中断管理开始-

国庆假期学习新技术。 别再废话了，从操作系统 - 定时器管理开始

1. AliOS Things 设备驱动模型

系统驱动框架没有怀疑最好的开源操作系统之一。 这是一个Linux系统。 精心设计的驱动程序框架、设备树和 Linux 系统的其他功能可以将硬件制造商连接驱动程序系统的成本降低到非常低的水平。 访问VFS系统提供了Linux系统驱动程序向应用程序提供的统一接口，使应用程序更易于操作。 该系统使用驱动相关的应用程序来消除不同Linux系统之间移植的障碍。 相比之下，大多数传统RTOS系统专注于内核功能开发，缺乏驱动架构设计。 前面提到，大多数物联网操作系统都是从传统的RTOS系统发展而来，因此大多数物联网操作系统没有太多的驱动框架设计。 概括起来，这些可以分为以下几类：

根本没有设备驱动程序的定义。 只需定义硬件接口层即可完全覆盖。芯片厂实现了一个简单的设备驱动程序，提供统一的应用程序访问接口。

1 类和 2 类系统可以 不太好用。 移植到不同平台时，由于接口不一致，或者接口的格式一致但接口底层实现不同，应用程序无法跨平台移植或者未经调试就无法跨平台运行。 3 类为应用程序提供了极大的可移植性，但一个问题是许多系统实现的通用驱动程序“太简单”，无法利用某些硬件的总线特性。 物联网使得应用场景越来越复杂，其缺点也越来越明显。

AliOS Things是在梳理了IoT领域设备框架的问题后，从“易用性”的角度进行设计的，并设计了如下图的驱动框架。 。

驱动程序框架为应用程序提供两种类型的接口。

aos_gpioc_get/aos_gpioc_set等AOS API，以及open/close/read/write/ioctl/poll等其他VFS API。

AOS API 对于开发传统 RTOS 的人们来说更加友好。 应用。 对于RAM/ROM要求非常严格的应用场景，以AOS形式直接调用API可以减少对VFS驱动子系统的依赖，减小固件大小。

VFS API 对于 Linux 开发人员来说很容易使用。 它遵循POSIX接口定义，基于POSIX标准的应用程序可以在AliOS Things和其他符合POSIX接口的操作系统之间轻松移植。 这容易多了。

驱动程序框架定义了芯片制造商通常实施的 HAL API 标准。 HAL API定义流程主控有两件事需要考虑：

硬件依赖性强：HAL API 中只定义与硬件强相关的函数。 原子函数：所有HAL API函数都是高度独立的，许多API只需要操作少数硬件。 可以实现寄存器

在 HAL API 和 AOS API 之间有一个设备驱动程序子系统的实现层。 设备驱动子系统的设计有两个主要目的。

隔离性：将应用程序与HAL API分离，彻底解决应用程序与芯片工厂的耦合关系。 Unity：驱动程序仅依赖于驱动程序子系统。 提供的API和驱动子系统确保提供给应用层的API的行为在不同平台上是一致的。

除了提供定义 AOS 或 VFS API 和 HAL API 的能力外，驱动程序框架还提供以下功能： 下面对这些进行介绍。

2、驱动程序自动分层加载机制

随着现代物联网系统的应用场景越来越复杂，同一个物联网硬件需要设备。 外围设备的数量持续增加。 不同的驱动程序之间可能存在依赖关系。 驱动程序自动加载机制旨在使驱动程序开发人员更容易以模块的形式将自己的驱动程序添加到系统中，并最大限度地减少在设备驱动程序添加/删除过程中必须修改的代码。 AliOS Things将设备驱动分为九个级别。 下表列出了各个级别的驱动程序初始化声明宏定义以及系统启动时的启动顺序。

启动顺序

宏定义

节名定义

1

CORE_DRIVER_ENTRY(driver_entry_api_name)

core_driver_entry

2

BUS_DRIVER_ENTRY(driver_entry_api_name)

bus_driver_entry

3

EARLY_DRIVER_ENTRY(driver_entry_api_name)

early_driver_entry

4

VFS_ DRIVER_ENTRY(driver_entry_api_name)

vfs_driver_entry

5

LEVEL0_DRIVER_ENTRY(driver_entry_api_name)

>

level0_driver_entry

6

LEVEL1_DRIVER_ENTRY(driver_entry_api_name)

level1_driver_entry

7

LEVEL2_DRIVER_ENTRY（driver_entry_api_name）

level2_driver_entry

8

LEVEL3_DRIVER_ENTRY(driver_entry_api_name)

level3_driver_entry

9

POST_DRIVER_ENTRY(driver_entry_api_name)

post_driver_entry

上述初始化函数的声明使用宏定义 使用相同宏定义声明的函数指针随后被分组在一起，并且在链接阶段将同一组放置在固件特定的代码段中。 当系统启动时，驱动框架依次从这些特定的代码段中读取函数指针，并调用这些函数指针所指向的函数。 分组到每个段中的段名称如上表所示。 这种机制可以保证不同宏定义中声明的多个驱动初始化函数严格按照表中1到9的顺序调用，但同一个宏定义中声明的多个驱动初始化函数是随机调用的。

此外，驱动框架还提供了设备后台初始化方法的宏定义（VFS_DRIVER_BG_ENTRY(driver_entry_api_name)）。 这可用于声明低优先级驱动程序初始化函数。 声明为低优先级驱动程序的初始化函数在低优先级线程的后台运行。 从而可以提高整个系统的启动速度。 假设蓝牙驱动初始化流程声明为后台初始化（VFS_DRIVER_BG_ENTRY(bluetooth_drv_init, NULL, 4096)），则正常加载流程与驱动层次加载流程的软件流程差异如图所示流程图可以参考到 如下图。

3. 驱动线程/消息/事件模型

AliOS Things 3.3 版本支持的弹性内核是一个驱动比较框架。 一个很高的要求是驱动框架必须能够在宏内核架构和微内核架构下运行，甚至可以同时在内核模式和用户模式下运行。 针对这一需求，AliOS Things设计了适合弹性内核架构的线程/消息/事件模型。

当设备驱动程序运行在内核模式时，内核函数可以通过直接函数调用来调用驱动程序提供的服务。 用户模式应用程序可以使用 VFS 接口或此接口。 通过系统调用访问AOS接口。

但是，当驾驶员正在驾驶时用户模式 ​​如果其他应用程序想要访问驱动程序提供的服务，则必须使用RPC（Remote Procure Call）。 此时AliOS Things仅提供VFS服务访问，如上图所示。 这样，同一套硬件的驱动程序无需修改就可以运行在用户态或内核态。 所有与RPC和VFS相关的逻辑都由驱动框架完成，简化了硬件驱动设计。 下图展示了微内核架构中驱动程序线程/消息模型的流程图。 详细代码可以看aos_device_register函数的实现，这里不再赘述。

4. 设备驱动子系统

下表显示了设备驱动程序表示。 子系统源码、接口定义头文件、用例描述、芯片厂对接接口头文件位置。 读者可以根据自己的需要进行详细解读。

各个设备驱动子系统有对应的AOS API模块和VFS API模块。 VFS API 模块依赖于 AOS API。 用户可以根据自己的需求选择想要使用的API类型。

项目

描述

源代码位置

组件/驱动/外设

接口头文件说明

组件/驱动/外设//include/aos/driver

用例描述

组件/驱动程序/外设//示例

芯片工厂对接接口标头file

components/csi/csi2/include/drv/.h

各个驱动子系统的设计和实现均能满足以下要求： 流程表场景要求。

驱动子系统类型

适用场景

I2C

使用不同的时钟频率与多个I2C从设备同时进行数据通信

SPI

多个I2C从设备同时进行，SPI从设备使用不同的参数设置进行数据通信（时钟频率、CS的存在、CS极性的有效性）。

MTD

支持多分区、Nand flash 和 Nor flash

UART

POSIX兼容的UART操作