mirror of
https://gitee.com/dlmu-cone/bf_original_balance_chassis
synced 2026-07-24 11:37:45 +08:00
修复PID堵转检测错误,修复LK电机位置环计算错误,更新文档,修改了消息中心的命名(不影响app层)
This commit is contained in:
14
README.md
14
README.md
@@ -112,19 +112,18 @@
|
||||
|
||||
## BSP层(Board Sopport Package)
|
||||
|
||||
- TODO:
|
||||
- 主要功能:实现映射功能。
|
||||
- 主要功能:实现对STM HAL的封装功能,进一步抽象硬件。
|
||||
- 在本框架中,BSP层与cubeMX初始化有一定程度的耦合,若没有在CUBEMX中开启某个外设,则在application不能初始化使用了对应外设的module。对该层的修改可能需要使用cube重新生成工程(主要是外设的配置,通信速度,时钟频率和分频数等)。该层也是唯一允许直接出现stm32HAL库函数的代码层,**在非BSP层编写代码时,如需使用HAL_...函数,请思考是否有同功能的BSP_...函数**。不过,由于ST的HAL已经对硬件进行较高的抽象(如以handle_xxx的方式描述一个硬件外设或功能引脚),因此即使需要更换开发板,必须修改的内容也极少。
|
||||
- 最简单的(如gpio)仅是对HAL库函数的封装。较为复杂的则会进行一定程度的处理(如can)
|
||||
|
||||
**编写和使用指南**
|
||||
|
||||
- 补充与修改:某款主控对应的BSP层应保持相同,当认为该层可能缺少部分功能或有错误时,请联系组长确认后解决并更新整个框架,**请勿自行修改提交**。 请在你修改/增加的bsp_XXX.md中提供测试用例和使用示范以及任何其他需要注意的事项,并在代码必要的地方添加注释。
|
||||
- 代码移植:BSP层也是在不同系列、型号的stm32间执行代码移植时主要需要关注的代码层。向功能更强系列移植一般只需要重配cube并重新组织BSP层的映射关系,而向功能较少的系列移植还需要去掉其不支持的功能。如果仅是对同一型号的开发板进行HAL初始化配置的修改,则BSP层**不需要**变动。
|
||||
- 代码移植:BSP层也是在不同系列、型号的stm32间执行代码移植时主要需要关注的代码层。向功能更强系列移植一般只需要重配cube,而向功能较少的系列移植还需要去掉其不支持的功能。如果仅是对同一型号的开发板进行HAL初始化配置的修改,一般只需要给app层的应用重新分配外设和引脚,或修改波特率和通信频率等。
|
||||
- 子文件与文件夹:
|
||||
- bsp.c/h:该层用于bsp基础功能初始化的文件,其中.h被include至main.c中,以实现整个代码层的初始化。include了该层所有模块的.h并调用各模块的初始化函数。**注意**,有些外设如串口和CAN不需要在bsp.c中进行模块层的初始化,他们会在module层生成实例(即C语言中的结构体)并注册到bsp层时自动进行初始化。以此达到提高运行速度避免未使用的模块被加载的问题。
|
||||
- bsp.c/h:该层用于bsp基础功能初始化的文件,其中.h被include至main.c中,以实现整个代码层的初始化。include了该层所有模块的.h并调用各模块的初始化函数。目前需要初始化的bsp只有log和dwt,**不同主频的MCU需要修改dwt初始化的参数**。**注意**,有些外设如串口和CAN不需要在bsp.c中进行模块层的初始化,他们会在module层生成实例(即C语言中的结构体)并注册到bsp层时自动进行初始化。以此达到提高运行速度避免未使用的模块被加载的问题。
|
||||
- bsp_xxx.c/h:每一个成对的.c/h对应一种外设,当上面两个代码层需要使用某个外设时,这里的文件就是对应的交互接口。
|
||||
- 注册回调函数与接收:通信类外设模块有的定义了回调函数类型(函数指针类型),若调用bsp...h中的回调函数注册函数将其他位置(HAL层)定义的符合形式的函数注册为回调函数,该函数在接收到数据后或其他设定位置会被调用。在module对模块进行初始化的时候需要将对应的协议解析函数进行设置,代码中注释有对应提示。
|
||||
- 注册回调函数与接收:通信类外设模块有的定义了回调函数(函数指针类型),module层的模块需要自行处理接收回调函数,在注册bsp的时候应传入对应参数格式的回调函数指针,使得接收中断发生的时候bsp层可以自行找到对应的上层回调函数进行调用。这也是回调函数设计的初衷:为底层代码调用上层代码提供接口,当特定事件发生的时候完成触发(自行搜索hook函数)。
|
||||
|
||||
## Module层
|
||||
|
||||
@@ -156,10 +155,9 @@
|
||||
|
||||
- 封装程度:
|
||||
|
||||
应尽可能使到上层使用时不考虑下层所需的操作。如在使用电机时,这个电机的数据该和哪些电机的数据在一个数据包中发送,can的过滤器设置,均属于应该自动处理的功能;
|
||||
接收类的driver应该封装到只有初始化(用于初始化的`register`和发送控制命令`set_control`两个函数和一个实时更新的用于给app层提供该信息的数据结构体)。
|
||||
应尽可能使到上层使用时不考虑下层所需的操作。如在使用电机时,这个电机的数据该和哪些电机的数据在一个数据包中发送,can的过滤器设置,均属于应该自动处理的功能;接收类的driver应该封装到只有初始化(用于初始化的`register`和发送控制命令`set_control`两个函数和一个实时更新的用于给app层提供该信息的数据结构体)。
|
||||
|
||||
Module层主要存放的是类型定义和实例指针数组,在该层没有进行实例化(定义或通过malloc分配空间),若在APP层没有实例化,则该模块的存在与否基本不会影响编译后的可执行文件,只会占用初始化和代码区所需的少量内存。module只会保存每个实例对象的指针,在没有初始化的时候仅仅占用一个指针数组的空间。因此,基于本框架的其他工程没有必要删除APP层未使用的module文件。
|
||||
Module层主要存放的是类型定义和实例指针数组,在该层没有进行实例化(定义或通过malloc分配空间),若在APP层没有实例化,则该模块的存在与否不会影响编译后的可执行文件,只会占用初始化和代码区所需的少量内存。module只会保存每个实例对象的指针,在没有初始化的时候仅仅占用一个指针数组的空间。因此,基于本框架的其他工程没有必要删除APP层未使用的module文件。
|
||||
|
||||
务必为模块添加说明文档和使用范例,以及其他需要注意的事项(如果有)。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user