LV01-01-AliOSThings-17-代码移植-01-移植说明

发表于 分类于 ， ， 本文字数： 5.2k 阅读时长 ≈ 19 分钟

本文主要是AliOSThings移植——移植说明的相关笔记，若笔记中有错误或者不合适的地方，欢迎批评指正😃。

点击查看使用工具及版本
Windows版本 windows11
Ubuntu版本 Ubuntu22.04的64位版本
VMware® Workstation 16 Pro 16.2.3 build-19376536
终端软件 MobaXterm(Professional Edition v23.0 Build 5042 (license))
点击查看本文参考资料
分类 网址 说明
官方网站 阿里云 阿里云官网主页
阿里生活物联平台 生活物联网平台(飞燕平台)主页
AliGenie 天猫精灵开放平台AliGenie主页
阿里物联网平台 阿里物联网平台主页
Bluetooth 技术网站 蓝牙协议规范什么的可以来这里找
Telink Telink | Chips for a Smarter IoT (telink-semi.com)
Telink中文官网
开发手册 AliOS Things开发指南 AliOS Things开发指南，这里是最新版本，可以直接从官网找到
AliOS Things开发指南 AliOS Things应用开发指南，这里应该是3.3版本的完整开发文档
AliOS Things开发指南(3.0) AliOS Things应用开发指南，这里应该是3.0版本的完整开发文档
生活物联网平台开发文档 生活物联网平台（飞燕平台）开发文档
《设备端开发指南》
Wi-Fi IoT品类定义与功能开发 天猫精灵IoT开放平台——Wi-Fi IoT品类定义与功能开发
硬件平台 mk3080 WiFi开发板 WiFi开发板使用指南-阿里云开发者社区
esp8266开发板 一个教程：ESP8266-NodeMCU开发板详解-太极创客 (taichi-maker.com)
TLSR8258 Datasheet Datasheet for Telink BLE + IEEE802.15.4 MultiStandard Wireless SoC TLSR8258
参考资料 AliOS Things 3.0 应用开发指南 这个只是一篇参考文章，里面是一些环境搭建相关的，可以参考
IP知识百科 - 华为 (huawei.com) IP的一些相关知识点
点击查看相关文件下载
分类 网址 说明
蓝牙规范相关文档 Core Specification 5.2 核心规格 5.2，该规范定义了创建可互操作的Bluetooth 设备所需的技术。
《Core_v5.2.pdf》
Mesh Model(v1.1) 本Bluetooth 规范定义了模型（以及它们所需的状态和消息），这些模型用于在mesh 网络中的节点上执行基本功能，超出了Bluetooth Mesh 配置文件 规范中定义的基础模型。
本规范包括定义跨设备类型标准功能的通用模型，以及支持关键mesh 场景的模型，如照明控制、传感器、时间和场景。
《MshMDL_v1.1.pdf》
Mesh Profile(v1.0.1) 该Bluetooth 规范定义了基本要求，以实现可互操作的mesh 网络解决方案，用于Bluetooth 低能量无线技术。
《MshPRFv1.0.1.pdf》
Mesh Device Properties 本规范包含Bluetooth Mesh 配置文件 和Bluetooth Mesh 模型规范所要求的设备属性的定义。
但是跟之前的有些区别，我主要看的之前的版本：《MMeshDeviceProperties_v1.2.pdf》
GATT Specification Supplement GATT Specification Supplement | Bluetooth® Technology Website。
好像可以在线看：《GATT Specification Supplement》
Assigned Numbers GATT的一些类型定义可以在这里找。
AliOS Things alios-things/AliOS-Things Gitee上的AliOSThings SDK源码仓库
alibaba/AliOS-Things GitHub上的AliOSThings SDK源码仓库
天猫精灵蓝牙Mesh协议栈 alibaba-archive/genie-bt-mesh-stack GitHub上的天猫精灵蓝牙Mesh协议栈源码仓库。
之前是在alibaba/genie-bt-mesh-stack这个仓库。
写笔记的时候最新提交为faf523618a6a2560090fc423222b9db80984bb7a
蓝牙Mesh设备开发指南 阿里云生活服务平台开发手册——蓝牙设备开发一节中的内容

一、移植说明

1. 谁在做移植工作？

image-20201029123649772

2. 官方移植说明

原来是有一个文档的，但是后来好像不维护，就直接没得了，那就大概了解一下好了。

image-20201029124236366

二、移植相关

1. 新增CPU架构

首先是要新增CPU的架构代码，涉及的目录为 AOS_SDK_PATH/platform/arch 目录。但是AliOSThings原本就支持了很多的CPU架构，这就看情况需不需要添加了。

1.1 已经支持的CPU架构

image-20231210204640874

其实我们可以直接去源码的AOS_SDK_PATH/platform/arch目录下，一样可以看到目前支持哪些CPU架构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
hk@vm:~/AliOS-Things-SDK/platform/arch$ tree -L 2
.
├── arm
│   ├── armv5
│   ├── armv6m
│   ├── armv6m-mk
│   ├── armv7a
│   ├── armv7a-mk
│   ├── armv7m
│   └── armv7m-mk
├── csky
│   └── cskyv2-l
├── linux
│   ├── aos.mk
│   ├── Config.in
│   ├── cpu_impl.c
│   ├── include
│   ├── README.md
│   ├── swap.h
│   └── swap.S
├── mips
│   ├── mips32
│   └── mips-I
├── README.md
├── risc-v
│   └── risc_v32I
├── rx600
│   └── rx65n
└── xtensa
    ├── lx106
    └── lx6

22 directories, 7 files

1.2 新增CPU适配点

对于系统中已经支持的CPU架构，可以直接使用对应的 platform/arch 模块，如果需要新增CPU架构支持，需要适配下面的接口，其对所有的CPU架构通用：

image-20201029124611328

这里的接口实际会在port_c.c或者port_s.S中实现，其他CPU架构相关的文件需要放在arch目录下，也可以按照实际需要放。

1.3 CPU arch目录规范

这里是从之前的官方文档截取的一部分，这里大概了解一下，其实也可以直接去读源码就可以的：

image-20231210205407555

三级和四级目录说明如下：

image-20231210205632095

1.4 arch mk文件编写

规范：没有例外情况，统一在二级Process arch目录添加对应的编译mk文件。arch mk添加规范如下(以armv7m为例):

1
2
3
4
5
6
7
8
NAME := arch_armv7m                   #arch_+架构名
$(NAME)_MBINS_TYPE := kernel          #多bin情况下，归属kernel还是app
$(NAME)_VERSION    :=1.0.2            #menuconfig版本号
$(NAME)_SUMMARY    := arch for armv7m #描述
$(NAME)_SOURCES    +=                 #组件包含.c文件
GLOBAL_INCLUDES    +=                 #包含头文件
ifeq ($(COMPILER) , armcc)            #区分编译器
ifeq ($(HOST_ARCH) , Cortex-M4)       #区分Processseries

1.5 config.in文件编写

arch Config.in添加规范如下(以armv7m为例)：

1
2
3
4
5
6
7
config AOS_ARCH_ARMV7M           #定义组件配置选项
	bool                         #配置选项类型
	help
		arch for armv7m          #配置选项帮助
if AOS_ARCH_ARMV7M
# Configurations for arch armv7m #如有必要，定义更多组件内配置选项
endif

Arch组件配置选项命名规范：使用前缀“AOS_ARCH_”+组件NAME。原则上在3.1版本中，mk只用来增加定义的组件components，其他配置和宏定义统一在Config.in定义。

2. 新增mcu

涉及目录: AOS_SDK_PATH/platform/mcu。mcu目录存放其原始SDK驱动文件（厂商原有的软件包），以及hal驱动对接层（aos hal层适配的代码）。外设驱动以及用户对于单板的配置代码不放入此目录，以便该SDK能支持该MCU下所有系列单板。

image-20201029124838405

2.1 mcu目录规范

主要目录结构：

1
2
3
4
5
6
7
Dir\File           Description                           Necessary for kernel run
|-- drivers   # board peripheral driver,或者是BSP                    Y
|-- hal       # hal API layer,hal uart is necessary                 Y
|-- aos.mk    # mcu makefile                                        Y
|-- Config.in # menuconfig component config                         Y
|-- ucube.py  # aos build system file(for scons)                    N
|--README.md                                                        Y

例如 platform/mcu/esp8266 目录：

image-20201029125210335

2.2 mcu mk文件编写

mcu的mk文件，其描述了当前mcu组件需要的编译文件和编译选项。如果该系列MCU能实现一个通用mk文件则使用一个即可；如果该MCU体系下存在多种MCU子系列，那么需要添加子mcu的mk文件，在其中放置不同的属性定义。aos.mk作为主mk，主要放置公共的属性配置，并使用HOST_MCU_NAME来分别引用对应的子mcu。不同的mcu子系列主要是由于其链接的驱动文件或者编译选项等不同，需要通过不同的mk来区分实现。示例如下：

1
2
3
4
5
aamcu_demo             # mcu主目录
	|-- aos.mk         # 该mcu主mk
	|-- aamcu1_demo.mk # aamcu1_demo
	|-- aamcu2_demo.mk # aamcu2_demo

在对应board如aaboard_demo的aos.mk文件引用此mcu模块名时，使用格式如下：

1
2
HOST_MCU_FAMILY := mcu_aamcu_demo
HOST_MCU_NAME   := aamcu1_demo

在mcu的主aos.mk中需要分别对子mcu进行引用，使用格式：

1
include $($(NAME)_LOCATION)/$(HOST_MCU_NAME). mk

aos.mk其他必须包含项：

1
2
3
4
5
6
7
8
9
10
11
12
NAMET:= mcu_aamcu_demo                   #主MCU名，一般是mcu_+当前mcu目录名
$(NAME)_MBINS_TYPE := kernel             #多bin情况下，归属kernel还是app
$(NAME)_VERSION    :=1.0.2               #menuconfig组件版本号
$(NAME)_SUMMARY    := driver & sdk       #描述
$(NAME)_SOURCES    +=                    #MCU组件包含.c文件
$(NAME)_COMPONENTS +=                    #依赖其他组件名
GLOBAL_INCLUDES    +=                    #头文件
GLOBAL_CFLAGS      +=                    #c文件编译选项
GLOBAL_ASMFLAGS    +=                    #汇编编译选项
GLOBAL_LDFLAGS     +=                    #链接选项
GLOBAL_DEFINES     +=                    #用户自定义宏

2.3 关联对应CPU

image-20201029125404506

2.4 config.in文件编写

mcu Config.in添加规范如下(以aamcu_demo为例)：

1
2
3
4
5
6
7
8
9
config AOS_MCU_AAMCU_DEMO          #定义组件配置选项
	bool                           #配置选项类型
	select AOS_ARCH_ARMV7M         #依赖特定arch
	select ...                     #依赖其他组件
	help
		driver & sdk for platform/mcu aamcu_demo #配置选项帮助
if AOS_MCU_AAMCU_DEMO
# Configurations for mcu aamcu_demo #如有必要，定义更多组件内配置选项
endif

mcu组件配置选项命名规范:使用前缀“AOS_MCU_”+组件NAME。同样，原则上在3.1版本中，mk只用来增加定义的组件components，其他配置和宏定义统一在Config.in定义。

3. 新增board

image-20201029125734118

我们来看一下 platform/board/esp8266目录：

image-20201029125911716

我们来 platform/board/esp8266/drivers 目录看一下：

image-20201029130026772

3.1 board目录规范

board取名需要使用官方通用名，能方便检索到相关信息。board目录下文件结构部署和命名需要遵循下面布局规则，以aaboard_demo单板为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Dir\File                        Description                                          Necessary for kernel run
|-- drivers            # board peripheral driver                                               N
|-- config
|	|-- board.h        # board config file,define for user,such as uart port num               Y
|	|-- k_config. c    # user's kernel hook and mm memory region define                        Y
|	|-- k_config.h     # kernel config file .h                                                 Y
|	|-- partition_conf. c # board flash config file                                            N
|-- startup
|	|-- board. c       # board_init implement                                                  Y
|	|-- startup. c     # main entry file                                                       Y
|	|-- startup_gcc.s  # board startup assember for gcc                                        Y
|	|-- startup_iar.s  # board startup assember for iar                                        Y
|	|-- startup_keil.s # board startup assember for keil                                       Y
|-- aaboard_demo.icf   # linkscript file for iar                                               Y
|-- aaboard_demo.ld    # linkscript file for gcc                                               Y
|-- aaboard_demo.sct   # linkscript file for sct                                               Y
|-- aos.mk             # board makefile                                                        Y
|-- Config.in          # menuconfig component config                                           Y
|-- ucube. py          # aos build system file(for scons)                                      N
|-- README.md          #                                                                       Y

board相关初始化使用的函数名需规范统一，参照如下：

文件 函数名
k_config.c 实现样例单板aaboard demo该文件内所有对接接口
partition_conf.c 统一分区初始化接口: flash_partition_init
board.c 统一单板初始化接口: board_init
startup.c 无特殊情况统一C程序主入口为main;内部调用单板初始化board_init;内部调用krhino接口初始化内核;内部创建主任务入口sys_init

3.2 board mk文件编写

如下是一些关键点：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
NAME := board_aaboard_demo                #board_+单板名
$(NAME)_MBINS_TYPE := kernel              #在多bin情况下，归属kernel还是app
$(NAME)_VERSION    := 1.0.1               #组件版本号
$(NAME)_SUMMARY    :=                     #描述
MODULE             := 1062                #固定
HOST_ARCH          := Cortex-M4           #CPU arch
HOST_MCU_FAMILY    := mcu_aamcu_demo      #归属MCU系列，需要对应platform/mcu下aos.mk组件
SUPPORT_MBINS      :=no                   #是否支持app\kernel的bin分离
HOST_MCU_NAME      := aamcul_demo         #MCU子系列类型
ENABLE_VFP         := 1                   #是否支持浮点数
$(NAME)_SOURCES    +=                     #board组件包含.c文件
$(NAME)_COMPONENTS +=                     #依赖其他组件名
GLOBAL_INCLUDES    +=                     #头文件
GLOBAL_CFLAGS      +=                     #c文件编译选项
GLOBAL_ASMFLAGS    +=                     #汇编编译选项
GLOBAL_LDFLAGS     +=                     #链接选项
GLOBAL_DEFINES     +=                     #用户自定义宏

注意:
(1)、其中HOST_MCU_FAMILY的定义需要对应platform/mcu某子目录下aos.mk中的组件名NAME，一般是mcu_+“mcu名”。

(2)、用户可以通过GLOBAL_DEFINES定义宏，如GLOBAL_DEFINES += CONFIG_AOS_CLI_BOARD。

(3)、原则上在3.1版本中，mk只用来增加定义的组件components，其他配置和宏定义统一在Config. in定义。

3.3 关联对应的MCU

每个board需要关联其从属的MCU，通过在其mk中添加HOST_MCU_FAMILY定义来指定。同时，如果存在子MCU，则还需要设置具体的HOST_MCU_NAME。例如对于aaboard_demo单板，其要关联MCU是aamcu_demo系列下的aamcu1_demo，在aaboard_demo目录下的aos.mk设置如下:

1
2
HOST_MCU_FAMILY := mcu_aamcu_demo
HOST_MCU_NAME   := aamcul_demo

3.4 config.in文件编写

board Config.in添加规范如下(以aaboard_demo为例)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
config AOS_BOARD_AABOARD_DEMO                #定义组件配置选项
	bool "AABOARD_DEMO"                      #配置选项类型，双引号定义该选项显示名称
	select AOS_MCU_AAMCU_DEMO                #依赖特定mcu
	select ...                               #依赖其他组件
	help                                    
    	...                                  #配置选项帮助
	
if AOS_BOARD_AABOARD_DEMO
# Configurations for board aaboard_demo
# "BSP SUPPORT FEATURE"                       #硬件支持的能力
config BSP_SUPPORT_UART
	bool
	default y
	...
endif

board组件配置选项命名规范：使用前缀“AOS_BOARD_”＋组件NAME

4. 新增example

涉及目录: applexample

example目录主要存放用户实际需要运行的程序，包括主任务入口aos_maintask，以及用户app统一入口application_start。原则上不建议新增example，除非目前的example不能满足功能需求。app/example下为通用运行实例，如果新增example，需要具有通用性,而不是为了某个特殊，或者临时性的修改。

其中app/example/example_legacy下为3.1版本之前规范的app示例，其不包括maintask.c主任务实现，其相关主任务的板级实现统一在跳转app前做全初始化，即不同的app，底层初始化的模块是一样的;

app/example目录非example_legacy下为3.1版本要求的规范app示例，其包括maintask.c主任务实现，对板级初始化做了模块区分，以期望实现不同app按照具体需求来初始化不同的board模块。

其中，app/example/example_legacy对应platform/board/board_legacy目录的单板;其他app/example对应platform/board下非board_legacy实现。

另，platform/board/board_legacy原有单板只能支持老的example_legacy实现；新的platform/board单板，兼容app/example所有app。