2.1. 设计框架¶
2.1.1. 设计目标¶
Luban-Lite 的设计规划是既要简单易用又要支持客户的大众化需求，同时要兼顾对最新的实时系统的支持，因此其设计目标归纳为：
兼容目前市面上最流行的几种 RTOS 内核：RT-Thread、FreeRTOS等
支持baremetal模式
提供完整的软件栈生态资源
2.1.3. 四级抽象模型¶
Luban-Lite 是一个跨（软/硬件）平台的 SDK， 它支持多种应用场景：
多个SoC芯片，需要做好驱动和设备的分离、驱动实例化等
多块单板，每块板子的外设、IO、性能配置各不相同
多种应用，1块板子可能支持多个应用
若干组件，驱动、组件、应用的对应存在一对多的依赖
总体上，以上元素形成了 N x N x N 的多对多组合关系。
SDK 在满足以上复杂映射关系的基础上，设计中还坚持了易用性的主旨：
用高内聚提供复用：减少代码冗余，减少维护工作量
用低耦合应对变化：针对某个方案又能灵活配置，满足客户的多元化使用
因此 Luban-Lite SDK 框架中抽象出四个层级的元素：
在具体的 Luban-Lite 设计中，从用户角度看，以上四级基本元素和SDK目录的对应关系如下图：
2.1.4. 编译框架¶
Luban-Lite SDK 采用了 scons 作为编译框架的基础语言，关于 scons 详细使用请参考 SConstruct
Luban-Lite 编译框架使用了以下树形结构进行层次化的引用：
有了 scons 框架的加持，Luban-Lite SDK 非常方便的支持 3 种场景的编译：
Linux 命令行
Windows 命令行，含CMD、Git-bash、RT-Thread env环境
Windows IDE
2.1.5. 配置框架¶
Luban-Lite SDK 采用了 menuconfig 工具来进行配置，提升用户修改配置的易用性和简洁性。
Luban-Lite menuconfig 配置框架使用了以下树形结构进行层次化的引用：
在 Luban-Lite 下，使用一个 .config 文件同时保存 Driver 和 Device 配置信息
为了更好的管理这些配置信息，对于单个模块来说， Kconfig 被细分成两个：
Kconfig.dev，存放Device相关的配置参数，比如UART模块的波特率、停止位参数
Kconfig.drv，存放Driver的通用配置参数，比如UART模块的DMA开关
在命令行下，Luban-Lite SDK的 Menuconfig 的配置方法：
$ scons --menuconfig // Linux 命令行下启动 Menuconfig
$ .... // Menuconfig 配置过程
2.1.6. 驱动框架¶
AIC Driver 需要支持多种形态下的复用。为了达到这个目的，整个驱动框架会分成 3 个层次：
RT-Thread Driver Framework：由RT-Thread 提供的驱动模型，我们只需要实现驱动模型中现有的功能即可。
AIC Driver Layer：对接RT-Thread Driver Framework的具体实现。
AIC HAL Layer：对底层硬件操作的封装，一般是寄存器级别的功能接口。也用于baremetal模式的APP调用。
对于移植一个新的设备驱动来说，要开发 Driver 和 HAL 两层。
为了保证开发的驱动在多种形态下的复用，需要遵循以下的原则：
在 AIC Driver Layer 和 AIC HAL Layer 尽可能的使用 AIC OSAL 接口，避免直接调用具体 Kernel 接口。
为了保证可移植性，在 AIC Driver Layer 中除了驱动注册不可避免的需要调用 RT-Thread 接口，在其他地方避免直接调用 RT-Thread 系统接口和 RT-Thread 的相关类型定义。
对于中断注册和互斥锁、信号量的操作，尽可能放在 AIC Driver Layer 中，避免放在 AIC HAL Layer 中。
2.1.7. 驱动调试¶
在 menuconfig 中，特意为 ArtInChip 的每个驱动都设置了一个 DEBUG 开关，用于打开相应模块的调试信息或者调试命令。
并且这些 DEBUG 开关统一放在一个地方，方便客户查找。在 menuconfig 中打开测试代码的配置方法：
2.1.8. 驱动测试¶
在 bsp/test/ 目录中，ArtInChip 实现了一些驱动的测试代码，也可以作为 Sample 供客户的APP设计参考。
这些测试代码，一般是实现了一个 shell 命令，在系统启动后可以通过输入 shell 命令的方式来触发测试代码。
在 menuconfig 中打开测试代码的配置方法：
