mirror of
https://gitee.com/Vancouver2017/luban-lite-t3e-pro.git
synced 2025-12-14 10:28:54 +00:00
195 lines
7.6 KiB
Markdown
195 lines
7.6 KiB
Markdown
|
|
# 1. Luban-Lite简介
|
|||
|
|
|
|||
|
|
Luban-Lite SDK 的设计目标:
|
|||
|
|
|
|||
|
|
- 兼容目前市面上最流行的几种 RTOS 内核:RT-Thread、FreeRTOS等
|
|||
|
|
- 支持baremetal模式
|
|||
|
|
- 提供完整的软件栈生态资源
|
|||
|
|
|
|||
|
|
为了满足上述目标,Luban-Lite 在原有的 RT-Thread SDK 框架基础之上进行二次开发和扩展:
|
|||
|
|
|
|||
|
|
- 对于内核部分,做成 RT-Thread、FreeRTOS、baremetal 无感切换
|
|||
|
|
- 尽可能复用 RT-Thread的 驱动框架和组件生态
|
|||
|
|
|
|||
|
|
## 1.1 Luban-Lite 框架
|
|||
|
|
|
|||
|
|
根据是否使用OS,Luban-Lite SDK 架构分为两种情况:
|
|||
|
|
|
|||
|
|
- 使用RTOS的情况:
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
其中,对FreeRTOS的适配,存在两种方案(对APP层都是透明的):
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
- 使用baremetal的情况:(虚线外框表示可能不存在)
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
## 1.2 目录结构
|
|||
|
|
|
|||
|
|
Luban-Lite SDK的目录结构如下:
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
luban-lite $ tree -L 2
|
|||
|
|
├── application // 存放APP代码
|
|||
|
|
│ ├── baremetal
|
|||
|
|
│ └── os
|
|||
|
|
├── bsp // 存放BSP代码,和RT-Thread原生的bsp目录功能相同
|
|||
|
|
│ ├── artinchip // ArtInChip SoC内部的driver、hal以及最小系统sys代码
|
|||
|
|
│ ├── common
|
|||
|
|
│ └── test // 各驱动的测试代码
|
|||
|
|
├── doc // Luban-Lite SDK的介绍文档
|
|||
|
|
│ ├── luban-lite_driver_development_guid.md // 设备驱动开发指南
|
|||
|
|
│ ├── luban-lite_sdk_design.md // SDK设计说明
|
|||
|
|
│ ├── luban-lite_user_guid_linux.md // Linux环境的用户使用说明
|
|||
|
|
│ └── luban-lite_user_guid_windows.md // Windows环境的用户使用说明
|
|||
|
|
├── win_env.bat // 启动RT-Thread的env工具,用于Windows环境的开发
|
|||
|
|
├── win_cmd.bat // 启动CMD.exe,用于Windows环境的开发
|
|||
|
|
├── kernel // 存放各种RTOS内核
|
|||
|
|
│ ├── common
|
|||
|
|
│ ├── freertos
|
|||
|
|
│ └── rt-thread
|
|||
|
|
├── output // SDK的编译输出
|
|||
|
|
├── packages // 组件包
|
|||
|
|
│ ├── artinchip // ArtInChip开发的组件包
|
|||
|
|
│ └── third-party // 第三方的组件包
|
|||
|
|
├── target // 方案(板)级的代码和配置
|
|||
|
|
│ ├── configs // 整个方案的SDK配置文件
|
|||
|
|
│ └── d21x // d21x 芯片对应的板级代码(见子目录)
|
|||
|
|
│ ├── demo100-nand
|
|||
|
|
│ ├── per2-nand
|
|||
|
|
│ └── per2-nor
|
|||
|
|
├── toolchain // 解压后的工具链存放目录
|
|||
|
|
└── tools // 一些工具
|
|||
|
|
├── onestep.sh // ArtInChip开发的OneStep命令行增强工具
|
|||
|
|
└── toolchain // 工具链的压缩包
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
# 2. Luban-Lite 设计说明
|
|||
|
|
|
|||
|
|
## 2.1 四级抽象模型
|
|||
|
|
|
|||
|
|
对于一个跨(软/硬件)平台的SDK 来说,需要支持:
|
|||
|
|
|
|||
|
|
- 多个SoC芯片,需要做好驱动和设备的分离、驱动实例化等
|
|||
|
|
- 多块单板,每块板子的外设、IO、性能配置各不相同
|
|||
|
|
- 多种应用,1块板子可能支持多个应用
|
|||
|
|
- 若干组件,驱动、组件、应用的对应存在一对多的依赖
|
|||
|
|
|
|||
|
|
总体上,以上元素形成了 `N x N x N` 的多对多组合关系。
|
|||
|
|
|
|||
|
|
在满足以上复杂映射关系的基础上,SDK 设计还需要达到:
|
|||
|
|
|
|||
|
|
- 用高内聚提供复用:减少代码冗余,减少维护工作量
|
|||
|
|
- 用低耦合应对变化:针对某个方案又能灵活配置,满足客户的多元化使用
|
|||
|
|
|
|||
|
|
为了解决上述需求,Luban-Lite SDK框架中抽象出四个层级的元素:
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
在具体的 Luban-Lite 设计中,从用户角度看,以上四级基本元素和SDK目录的对应关系如下图:
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
## 2.2 编译框架
|
|||
|
|
|
|||
|
|
Luban-Lite SDK 采用了 `scons` 作为编译框架的基础语言,相对传统的 `Makefile`会更灵活更强大。
|
|||
|
|
|
|||
|
|
`scons` 是基于 python 语言的,除了编译语法远胜于语法难记功能弱小的 `Makefile` 语法,它还有无限的扩展性可以把任意操作扩展成和编译命令并列的命令,方便用户使用。另外 `Cmake` 的编译配置也是非常方便远优于 `Makefile`,但是 `Cmake` 扩展性也是远不及 `scons` 的。
|
|||
|
|
|
|||
|
|
关于 `scons` 请参考非常经典的官方文档 [scons-user-guid](https://www.scons.org/doc/production/HTML/scons-user.html) 和 [scons-man-page](https://www.scons.org/doc/production/HTML/scons-man.html) 。
|
|||
|
|
|
|||
|
|
Luban-Lite 编译框架使用了以下树形结构进行层次化的引用:
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
有了 `scons` 框架的加持,Luban-Lite SDK 非常方便的支持 3 种场景的编译:
|
|||
|
|
|
|||
|
|
- Linux 命令行
|
|||
|
|
- Windows 命令行,含CMD、Git-bash、RT-Thread env环境
|
|||
|
|
- Windows IDE
|
|||
|
|
|
|||
|
|
## 2.3 Menuconfig 配置框架
|
|||
|
|
|
|||
|
|
Luban-Lite SDK 采用了 Menuconfig 工具来进行配置,提升用户修改配置的易用性和简洁性。
|
|||
|
|
|
|||
|
|
Luban-Lite Menuconfig 配置框架使用了以下树形结构进行层次化的引用:
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
值得特别说明的一个概念是在 Linux Kernel 下用户配置是分成两部分来保存的,它的设计思想:
|
|||
|
|
|
|||
|
|
- `.config` 文件保存 `Driver` 配置信息
|
|||
|
|
- `dts` 文件保存 `Device` 配置信息。
|
|||
|
|
|
|||
|
|
在 Luban-Lite 下,我们使用一个 `.config` 文件同时保存 `Driver` 和 `Device` 配置信息,没有 DTS 配置方式。
|
|||
|
|
|
|||
|
|
为了更好的管理这些配置信息,对于单个模块来说,我们把 `Kconfig` 细分成两个:
|
|||
|
|
|
|||
|
|
- `Kconfig.dev`,存放Device相关的配置参数,比如UART模块的波特率、停止位参数
|
|||
|
|
- `Kconfig.drv`,存放Driver的通用配置参数,比如UART模块的DMA开关
|
|||
|
|
|
|||
|
|
在命令行下,Luban-Lite SDK的Menuconfig 的配置方法:
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
$ cd luban-lite
|
|||
|
|
$ scons --menuconfig // Linux 命令行下启动 Menuconfig
|
|||
|
|
$ .... // Menuconfig 配置过程
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 2.4 驱动框架
|
|||
|
|
|
|||
|
|
如本文开头所示,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.5 驱动调试
|
|||
|
|
|
|||
|
|
在menuconfig中,特意为ArtInChip的每个驱动都设置了一个DEBUG开关,用于打开相应模块的调试信息或者调试命令。
|
|||
|
|
|
|||
|
|
并且这些DEBUG开关统一放在一个地方,方便客户查找。在menuconfig中打开测试代码的配置方法:
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
## 2.6 驱动测试
|
|||
|
|
|
|||
|
|
在 `bsp/test/` 目录中,ArtInChip实现了一些驱动的测试代码,也可以作为Sample供客户的APP设计参考。
|
|||
|
|
|
|||
|
|
这些测试代码,一般是实现了一个shell命令,在系统启动后可以通过输入shell命令的方式来触发测试代码。
|
|||
|
|
|
|||
|
|
在menuconfig中打开测试代码的配置方法:
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
# 3. BSP 适配
|
|||
|
|
|
|||
|
|
## 3.1 编译选项
|
|||
|
|
|
|||
|
|
## 3.2 startup 启动
|
|||
|
|
|
|||
|
|
## 3.3 中断和异常
|
|||
|
|
|
|||
|
|
## 3.4 任务切换
|
|||
|
|
|
|||
|
|
## 3.5 libc 调用
|
|||
|
|
|
|||
|
|
## 3.6 内存管理
|
|||
|
|
|
|||
|
|
## 3.7 IO 访问
|
|||
|
|
|
|||
|
|
# 4. AIC OSAL 适配
|