update readme
This commit is contained in:
parent
59ad9579b5
commit
dffcbc6f70
14
README.md
14
README.md
|
@ -39,12 +39,12 @@
|
|||
1. 增加SPI和I^2^C的BSP模组以便支持IST384磁力计和Oled显示屏等。
|
||||
1. 增加和module层的deteck_task配合的蜂鸣器和led闪烁配置。
|
||||
- 主要功能:实现映射功能。
|
||||
- 在本框架中,BSP层与cube高度耦合,对该层的修改往往需要使用cube重新生成工程。该层也是唯一允许直接出现stm32HAL库函数的代码层,**在非BSP层编写代码时,如需使用HAL_...函数,请思考是否有同功能的BSP_...函数**。
|
||||
- 在本框架中,BSP层与cube高度耦合,对该层的修改可能需要使用cube重新生成工程(主要是外设的配置,通信速度,时钟频率和分频数等)。该层也是唯一允许直接出现stm32HAL库函数的代码层,**在非BSP层编写代码时,如需使用HAL_...函数,请思考是否有同功能的BSP_...函数**。不过,由于ST的HAL已经对硬件进行较高的抽象(如以handle_xxx的方式描述一个硬件外设或功能引脚),因此更换开发板需要修改的内容极少。
|
||||
- 最简单的(如gpio)仅是对HAL库函数的封装。较为复杂的则会进行一定程度的处理(如can)
|
||||
- 补充与修改:某款主控对应的BSP层应保持相同,当认为该层可能缺少部分功能或有错误时,请联系组长确认后解决并更新整个框架,**请勿自行修改**。
|
||||
- 代码移植:BSP层也是在不同系列、型号的stm32间执行代码移植时主要需要关注的代码层。向功能更强系列移植一般只需要重配cube并重新组织BSP层的映射关系,而向功能较少的系列移植还需要去掉其不支持的功能。修改BSP后一般不需要对其他两层进行修改。
|
||||
- 子文件与文件夹:
|
||||
- bsp.c/h:该层核心文件,其中.h被include至main.c中,以实现整个代码层的初始化。include了该层所有模块的.h并调用各模块的初始化函数。**注意**,有些外设如串口和CAN不需要在bsp.c中进行模块层的初始化,他们会在module层生成实例(即C语言中的结构体)并注册到bsp层时自动进行初始化。
|
||||
- bsp.c/h:该层核心文件,其中.h被include至main.c中,以实现整个代码层的初始化。include了该层所有模块的.h并调用各模块的初始化函数。**注意**,有些外设如串口和CAN不需要在bsp.c中进行模块层的初始化,他们会在module层生成实例(即C语言中的结构体)并注册到bsp层时自动进行初始化。以此达到提高运行速度避免未使用的模块被加载的问题。
|
||||
- bsp_xxx.c/h:每一个成对的.c/h对应一种外设,当上面两个代码层需要使用某个外设时,这里的文件就是对应的交互接口。
|
||||
- 注册回调函数与接收:通信类外设模块有的定义了回调函数类型(函数指针类型),若调用bsp...h中的回调函数注册函数将其他位置(HAL层)定义的符合形式的函数注册为回调函数,该函数在接收到数据后或其他设定位置会被调用。在module对模块进行初始化的时候需要将对应的协议解析函数进行设置,代码中注释有对应提示。
|
||||
|
||||
|
@ -65,7 +65,7 @@
|
|||
|
||||
- 子文件与子文件夹
|
||||
|
||||
- module.c/h:该层核心文件。会对该层所有模块初始化,调用各个模块的init函数,并封装成module层的init函数放到main.c中执行。注意,一些模块会在app层构建对应实例的时候进行初始化,不需要在module.c的init函数中进行初始化。
|
||||
- 注意,module层没有也不需要进行同意初始化。app层的应用会包含一些模块,因此由app来调用各个模块的init函数,只有当一个module被app实例化,这个模块才会存在。
|
||||
- monitor文件夹:实现看门狗功能。提供回调函数和count可选(TODO)
|
||||
- algorithm:该层软件库存放位置,这些功能与硬件无关,而是提供通用的数据结构和“算子”以供该层的其他部分调用,主要是算法、控制器、底盘和位姿解算等。
|
||||
|
||||
|
@ -77,7 +77,7 @@
|
|||
|
||||
- 结构体:
|
||||
|
||||
也就是所说的“实例”,定义一个module结构体,对于app层来说就是拥有某一个功能模块的实例,比如一个特定的电机。在对电机进行操作的时候,传入该实例的结构体指针。
|
||||
也就是所说的“实例”,定义一个module结构体,对于app层来说就是拥有某一个功能模块的实例,比如一个特定的电机。在对电机进行操作的时候,传入该结构体指针。
|
||||
|
||||
- 函数:
|
||||
|
||||
|
@ -86,9 +86,9 @@
|
|||
- 封装程度:
|
||||
|
||||
应尽可能使到上层使用时不考虑下层所需的操作。如在使用电机时,这个电机的数据该和哪些电机的数据在一个数据包中发送,can的过滤器设置,均属于应该自动处理的功能;
|
||||
接收类的driver应该封装到只有初始化(`register`和发送控制命令`set_control`两个函数和一个实时更新的用于给app层提供该信息的数据结构体)。
|
||||
接收类的driver应该封装到只有初始化(用于初始化的`register`和发送控制命令`set_control`两个函数和一个实时更新的用于给app层提供该信息的数据结构体)。
|
||||
|
||||
Module层主要存放的是类型定义和实例指针数组,在该层没有进行实例化(定义或通过malloc分配空间),若在APP层没有实例化,则该模块的存在与否基本不会影响编译后的可执行文件,只会占用初始化和代码区所需的少量内存。因此,基于本框架的其他工程没有必要删除APP层未使用的module文件。
|
||||
Module层主要存放的是类型定义和实例指针数组,在该层没有进行实例化(定义或通过malloc分配空间),若在APP层没有实例化,则该模块的存在与否基本不会影响编译后的可执行文件,只会占用初始化和代码区所需的少量内存。module只会保存每个实例对象的指针,在没有初始化的时候仅仅占用一个指针数组的空间。因此,基于本框架的其他工程没有必要删除APP层未使用的module文件。
|
||||
|
||||
## APP层(application)
|
||||
|
||||
|
@ -260,4 +260,4 @@ HAL库初始化 --> BSP初始化 --> Application初始化 --> app调用其拥有
|
|||
|
||||
APP会调用其所有的模块的初始化函数(注册函数),这是因为本框架的设计思想是任何模块在被注册(构造/初始化)之前,都是不存在的,当且仅当定义了一个模块结构体(也称实例)的时候,才有一个实体的概念。
|
||||
|
||||
> 参考了哈工深南宫小樱战队的框架设计,在此鸣谢。
|
||||
> 代码参考了哈工深南宫小樱战队的框架设计,在此鸣谢。
|
Loading…
Reference in New Issue