|
|
|
|
# 新代码架构使用指南
|
|
|
|
|
|
|
|
|
|
## 写在前面
|
|
|
|
|
|
|
|
|
|
新代码架构使用cmake配合cubeide编译，使用cubemx修改ioc配置的方式进行维护。需要将cubeide升级至v2版本，由于v2起cubeide与cubemx分成了两个独立软件，因此如果要修改ioc配置的话还需要额外安装cubemx。安装包在部门共享文件夹内的`/vol1/@team/SW_Group/STM32相关文件及安装包等`有安装包。
|
|
|
|
|
|
|
|
|
|
### 使用cubeide导入工程
|
|
|
|
|
|
|
|
|
|
1. 打开cubeidev2版本
|
|
|
|
|
2. 依次点击顶部面板的File-->Import打开导入界面
|
|
|
|
|
3. 在导入界面选择**STM32 CMake Project**
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4. 弹出的界面选择有CMakeLists.txt文件的那个文件夹的名字。我一般习惯项目名称与文件夹名一致，这样cubeide会自动找到那个文件夹。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5. 在下一个弹出的窗口需要指定芯片信号，直接填**STM32H743ZGTx**即可，然后点击完成即可。
|
|
|
|
|
|
|
|
|
|
6. 工程添加成功的瞬间便会触发一次cmake预构建如下图所示。此时用快捷键Ctrl+B即可触发编译，编译完成后即可看到0 error 0 warnings的编译成功提示，此时就可以正常下载调试代码了。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Git使用
|
|
|
|
|
### 写在前面
|
|
|
|
|
在软件开发过程中经常会遇到迭代修改问题：即在一个项目中反复修改或优化某一个功能，代码变动很大，然后最后甲方的一句”我觉得还是用最开始那一版吧”经常把我们搞得焦头烂额。而业界一般常用git或svn来进行代码维度的版本管理，我们目前内部在用的是郭大佬搭建的[git平台](http://123.207.52.103:3000/)，但是据我调研，大家目前都在把git当作一个云盘来使用而忽略了它的很多高级功能，此文章目的在于带大家了解一些git的基础操作和进阶操作。这里优先讲解我用到过的，其他的待大家完善。
|
|
|
|
|
|
|
|
|
|
### 安装Git（Windows下）
|
|
|
|
|
在[飞牛](http://192.168.18.234:5666/)的`/vol1/@team/SW_Group/提效软件`目录下（也就是主界面进去后依次点击**文件管理->团队文件->SW_Group->提效软件**）找到`Git-2.34.1-64-bit.exe`安装包并进行安装，安装选项较多无脑点下一步即可，当然也可以问一下AI那些选项都是什么意思让它给提提建议但一般都无伤大雅。
|
|
|
|
|
|
|
|
|
|
## 关于cmake与CMakePresets.json
|
|
|
|
|
|
|
|
|
|
大家一定注意到了根文件夹下的CMakePresets.json文件，这个文件就是cmake实现可裁剪模块化配置的关键文件。其中描述了开启哪些编译选项。CMakePresets.json文件的工作原理实际上就是代替命令行cmake中的裁剪配置命令参数，cmake会在每次预构建时读取CMakePresets.json文件内容并在build下生成编译中间文件。因此**每次修改完CMakePresets.json内容后如果需要其生效需要手动删除build文件夹重新触发cmake预编译**。
|
|
|
|
|
|
|
|
|
|
除了default-release区段外，其余区段均可以作为编译参数以控制编译哪个工程，同时区段间有继承机制，通过inherits字段维护。（上述区段指的是CMakePresets.json中name字段所对应的json块）
|
|
|
|
|
|
|
|
|
|
而在cubeide中可以通过可视化方式选择当前生效的区段，如下图所示（区段发生改变后需要删除build重新触发cmake预编译才可生效）：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 关于开启打印与Lua终端的编译宏
|
|
|
|
|
|
|
|
|
|
1. 使用串口Lua终端（默认在485_2）
|
|
|
|
|
|
|
|
|
|
开启USE_PRINT，关闭USE_TALNET
|
|
|
|
|
|
|
|
|
|
2. 使用网口终端（默认talnet的端口）
|
|
|
|
|
|
|
|
|
|
关闭USE_PRINT，开启USE_TALNET
|
|
|
|
|
|
|
|
|
|
3. 使用网口终端，且希望看到代码中的elog打印
|
|
|
|
|
|
|
|
|
|
开启USE_PRINT，开启USE_TALNET
|
|
|
|
|
|
|
|
|
|
4. 正常产品（485_2被使用）
|
|
|
|
|
|
|
|
|
|
关闭USE_PRINT
|
|
|
|
|
|
|
|
|
|
表格汇总（注意USE_PRINT实际上是485_2作为串口打印输出的宏定义，所以请在开启改宏时确保产品中485_2没有被使用）
|
|
|
|
|
|
|
|
|
|
| USE_PRINT | USE_TALNET | 效果 |
|
|
|
|
|
| --------- | ---------- | ------------------------------------------------------------ |
|
|
|
|
|
| 开启 | 开启 | 使用网口终端，且希望看到代码中的elog打印 |
|
|
|
|
|
| 开启 | 关闭 | 在485_2使用串口Lua终端 |
|
|
|
|
|
| 关闭 | 开启 | 使用网口终端，没有打印（一般用于485_2被使用又想用Lua终端的情况） |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 程序挂死类问题排查
|
|
|
|
|
|
|
|
|
|
所谓挂死类问题的问题现象一般是MCU突然死机无响应，如果电机开启了看门狗配置会触发抱闸，否则表现为机器人失控，即使遥控器急停也无效。属于比较**影响研发形象的问题**
|
|
|
|
|
|
|
|
|
|
老版本裸机代码缺少这方面的问题定位机制，当前切换了操作系统后应该发挥操作系统的优势，将此类问题的定位难问题得到解决。
|
|
|
|
|
|
|
|
|
|
因此，新版本的操作系统程序下下加入了离线日志系统。并在触发硬件错误时将栈信息保存到了片外flash上，这一定程度上实现了即使触发MCU挂死后并重启了设备，错误信息依然会保存。本文档就是用于指导如何将日志中的信息转化为可供我们定位问题的信息的方法。
|
|
|
|
|
|
|
|
|
|
1. 设置环境变量：`C:\ST\STM32CubeIDE_2.1.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.14.3.rel1.win32_1.0.100.202602081740\tools\bin`
|
|
|
|
|
|
|
|
|
|
2. 重启后进设备后台用`tail()`查看到的打印信息类似：
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
====== HardFault Detected ======
|
|
|
|
|
PSR= 0x21000023
|
|
|
|
|
PC = 0x08067C56, LR = 0x08036261
|
|
|
|
|
HFSR = 0x40000000 CFSR = 0x00000400
|
|
|
|
|
BFAR = 0x00000000 MMFAR= 0x00000000
|
|
|
|
|
sp = 0x2001FEE0
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
看到类似这种信息，表示刚才的机器人卡死是因为触发了MCU的错误中断
|
|
|
|
|
|
|
|
|
|
3. 执行命令，最后一个地址参数对应的就是PC和LR，PC是崩溃前最后的调用栈，LR是PC返回的地址
|
|
|
|
|
|
|
|
|
|
```sh
|
|
|
|
|
arm-none-eabi-addr2line.exe -f -C -e 你的程序.elf 0x08067C36
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
命令参数说明：
|
|
|
|
|
|
|
|
|
|
| `-e` | `--exe` | 指定要查询的 **ELF 文件**，也就是带调试符号的固件文件。这里就是 `你的程序.elf`。 |
|
|
|
|
|
| ---- | ------------- | ------------------------------------------------------------ |
|
|
|
|
|
| `-f` | `--functions` | 在输出文件名和行号之前，先输出该地址所在的 **函数名**。 |
|
|
|
|
|
| `-C` | `--demangle` | 把编译器生成的低级符号名还原成可读名称，主要用于 **C++ 符号还原**。 |
|
|
|
|
|
|
|
|
|
|
4. 应该可以看到如下输出：
|
|
|
|
|
|
|
|
|
|
```powershell
|
|
|
|
|
arm-none-eabi-addr2line.exe -f -C -e .\robot_h743.elf 0x08067C56
|
|
|
|
|
memcpy
|
|
|
|
|
/build/gnu-tools-for-stm32_14.3.rel1.20251027-0700/src/newlib/newlib/libc/machine/arm/../../string/memcpy.c:48
|
|
|
|
|
|
|
|
|
|
arm-none-eabi-addr2line.exe -f -C -e .\robot_h743.elf 0x08036261
|
|
|
|
|
rd_RingbufferPut
|
|
|
|
|
D:/vedio/robot_h743/robot/library/ringbuffer/ringbuffer.c:133
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
然后找着这个信息分析代码或添加日志进一步定位即可。也可以问AI，如果是简单的错误导致的一般AI静态分析代码就能定位原因。
|
|
|
|
|
|
|
|
|
|
## 常见问题
|
|
|
|
|
|
|
|
|
|
* 找不到.project和.cproject文件怎么办？
|
|
|
|
|
|
|
|
|
|
这是由于大家电脑里原来只有低版本的cubeide，多版本共存时双击.project文件会默认用低版本打开该工程，为了防止该情况我就把这俩文件删除了，转而依赖cmake去动态生成这两个文件。操作方法详见**使用cubeide导入工程**章节
|
|
|
|
|
|
|
|
|
|
* 导入cmake工程时报错`Invalid source directory location. No 'CMakeList.txt' found.`
|
|
|
|
|
|
|
|
|
|
这是由于指定的文件夹下没有CMakeList.txt，重点关注一下**使用cubeide导入工程**章节第四步填入的文件夹是否正确。
|
|
|
|
|
|
|
|
|
|
* 修改完CMakePresets.json后未生效？
|
|
|
|
|
|
|
|
|
|
手动删除build文件夹重新触发编译即可
|
|
|
|
|
|
|
|
|
|
* 我的工程代码根本没跑起来，或者跑到了其他位置。
|
|
|
|
|
|
|
|
|
|
关注`关于cmake与CMakePresets.json`章节中在cubeide中选择生效区段的部分，检查自己project下的自己的工程文件夹名称是否与当前区段一致。（**这里需要强制要求新增区段时其命名方式与文件夹名称一致**）
|
|
|
|
|
|
|
|
|
|
*
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
