设计框架

设计目标

Baremetal 的设计规划旨在提供一个简单易用，且能够满足广泛用户需求的解决方案，同时要确保对主流实时系统的支持。Baremetal 具有以下设计优势和特点：

根据是否使用 OS，Baremetal SDK 架构分为两种情况：

RTOS

在使用操作系统的情况下，Baremetal SDK 则能够在 RTOS 环境下运行。通过在 RT-Thread Kernel 的基础上进行封装，Baremetal 能够兼容 RT-Thread 和 Free-RTOS 两种实时操作系统的 API：

Baremetal

在不使用操作系统的情况下，Baremetal SDK 支持 baremetal 模式，允许开发者在没有操作系统的环境中运行应用程序。

Baremetal 是一个多维抽象模型的跨平台 SDK，包括软、硬件平台，支持多种应用场景，并能处理以下多种复杂映射关系：

总体上，以上元素交织在一起，形成了复杂的 N x N x N 的多对多组合关系。

在满足以上复杂映射关系的基础上，Baremetal SDK 的设计具有以下易用性特点：

Baremetal SDK 框架可抽象为以下四个层级的元素，各层级与配置文件的对应关系如下图所示：

在具体的 Baremetal 设计中，从用户角度看，以上四级基本元素和 SDK 目录的对应关系如下图：

Baremetal SDK 采用了 SCons 作为编译框架的底层语言，提供了灵活的编译支持，覆盖以下三种主要场景：

注：关于 SCons 的详细使用说明，可参考 SConstruct

Linux 命令行：开发者可以在 Linux 环境中通过命令行执行 SCons 脚本来配置和编译项目。
Windows 命令行：在 Windows 操作系统下，通过 CMD 或 Git-bash，以及 RT-Thread env 环境，使用 SCons 命令进行项目的构建和编译。
Windows IDE：对于习惯在集成开发环境 (IDE) 中工作的开发者，可在 Windows IDE 中集成 SCons，以实现可视化的编译流程。

Baremetal 编译框架使用了以下树形结构的层次化引用：

Baremetal SDK 采用 menuconfig 工具来进行配置，提升用户修改配置的易用性和简洁性。

Menuconfig 工具具有以下特点：

Menuconfig 配置框架使用树形结构进行层次化引用。配置选项清晰、逻辑分明，并且易于用户理解和操作。
在 Baremetal 下，一个 .config 文件可同时保存 Driver 和 Device 配置信息，简化了配置文件的管理，并使得维护更为集中和方便。
在 Kconfig的分区设计中，每个模块的 Kconfig 被细分成两个部分：
- Kconfig.dev，存放 Device 相关的配置参数，比如 UART 模块的波特率、停止位参数。
- Kconfig.drv，存放 Driver 的通用配置参数，比如 UART 模块的 DMA 开关。
在命令行界面下，用户可以通过简单的命令scons --menuconfig来启动 menuconfig 配置工具：
```
$ scons --menuconfig                // Linux 命令行下启动 Menuconfig
$ ....                              // Menuconfig 配置过程
```
启动 menuconfig 配置工具后，用户将进入一个交互式的配置界面，可以按照需要选择和调整各项参数。

为了简化开发流程并提高代码复用性，AIC Driver 驱动框架分成三个层次，以适应不同的硬件和应用场景：

RT-Thread Driver Framework：实现由 RT-Thread 提供的驱动模型的功能。
AIC Driver Layer： RT-Thread Driver Framework 的具体实现层，负责将 RT-Thread 的标准接口转换为 AIC HAL Layer 可以理解的接口。通过转换，确保了上层应用和底层硬件之间的独立性，使得开发者在不修改硬件相关代码的情况下，可以通过修改这一层的实现来适配不同的硬件。
AIC HAL Layer：对底层硬件操作的封装，一般是寄存器级别的功能接口，为上层提供了统一的硬件访问接口。除了用于正常的设备驱动之外，这一层还被用于 baremetal 模式的 APP 调用，即在没有操作系统的情况下直接运行应用程序。

驱动复用和移植注意事项

在移植一个新的设备驱动时，开发工作涉及两个主要层次：AIC Driver Layer 和 AIC HAL Layer。

为了确保驱动可以在多种形态下复用并最大程度地提高可移植性与维护性，需要遵循以下关键原则和建议：

使用 AIC OSAL 接口

在 AIC Driver Layer 和 AIC HAL Layer 中，应尽可能使用 AIC OSAL 接口，避免直接调用特定的 Kernel 接口。这有助于减少对特定操作系统的依赖，从而提高代码的泛用性和可移植性。
避免直接调用 RT-Thread 系统接口

除了驱动注册不可避免的需要调用 RT-Thread 接口外，AIC Driver Layer 中应避免直接调用 RT-Thread 系统接口和 RT-Thread 的相关类型定义。这种操作可以保持驱动与操作系统之间的独立性，使得驱动更容易在其他操作系统上重用。
集中管理中断和同步机制

对于中断注册和互斥锁、信号量的操作，应尽可能放在 AIC Driver Layer 中处理，避免放在 AIC HAL Layer 中。这种处理方式有利于上层统一管理资源的同步和并发控制，同时也更加符合分层设计的原则，提高了代码的模块化和可读性。

在 menuconfig 中，ArtInChip 的每个驱动都设置了 DEBUG 开关，用于打开相应模块的调试信息或者调试命令。

DEBUG 开关统一放置在同一个区域，便于用户查找和使用。如需在 menuconfig 中启用测试代码，可遵循以下配置步骤：

ArtInChip 在 bsp/examples/ 目录中实现了部分驱动的示例代码，可以作为模块的测试代码和应用开P 设计参考样本。

ArtInChip 预设的示例代码，通常封装为特定的 Shell 命令，可在系统启动后通过输入 Shell 命令的方式来触发预定的代码。如需在 menuconfig 中启用测试代码，可遵循以下配置步骤：