IDE/IoT/实践小熊派LiteOS工程配置、编译、烧录、调试（基于 bearpi-iot_std_liteos 源码）

概述

本文基于小熊派社区提供的源码和简要集成开发环境搭建说明，实践 LiteOS 物联网端侧应用程序的工程配置、编译、烧录和调试。相较基于 LiteOS Studio 或 VSCode IoTLink 插件搭建的IDE，其不再受限仅能使用旧版本VSCode及其插件，也不只局限于针对LiteOS的开发。本文内容涉及VSCode、Cortex-Debug、GCC工具链、JLink调试工具、menuconfig、genconfig等使用方法说明。

@HISTORY
在小熊派开发板上烧录的第一个程序，是按照小熊派社区提供的IDE来搞的。后来在前几个HCIP实验操作中，我使用的是 LiteOS Stduio 开发环境，后来使用的是 VSCode + GitBash + GCC + Cortex-debug 集成开发环境方案，小熊派提供的依赖包也不稀用了。

实验准备

BearPi-IoT_Std开发板针对不同需求的开发者，提供了使用GCC编译和MDK编译的两种开发方式，也不单单可以对接华为云平台。针对华为云，其并没有使用 LiteOS Studio 或 VSCode IoTLink 插件，而仅使用华为云物联网SDK库 。

参考资料说明

参照1: 小熊派IoT开发板社区帮助文档中提及的IDE搭建过程，软件 -> 十分钟上手教程(GCC)。
参考2：小熊派-物联网·仲 -> Codelabs -> 基于NB-IoT的智慧路灯案例。
参考3：GitEE 小熊派开源社区/BearPi-IoT_Std_LiteOS 帮助文档。

如上几个参照都是小熊派社区中给出的，第1个参照中的Demo，关于环境搭建过程是更详细的，但源码案例是不带LiteOS的。第2个参照中，关于环境搭建过程的描述相对简单，其源码案例是带LiteOS、带IoTDA云端产品、模型、设备配置说明的。两个参照请结合者使用。

示例程序下载

小熊派-物联网·仲 -> 软件 -> 连接物联网平台开发教程 -> 华为云平台的智慧路灯案例，或者小熊派-物联网·仲 -> Codelabs -> 基于NB-IoT的智慧路灯案例，中提及的 BearPi-IoT_Std_LiteOS 源码，GitEE下载地址 ，压缩文件217M大小，

学习外设操作时，可用 BearPi-IoT_Std（不带LiteOS） 开发板案例代码，GitEE地址，

LiteOS Studio

小熊派示例程序可以在多个IDE完成编译和调试，包括 LiteOS Studio 集成开发环境。在 #<IDE/IoT/搭建物联网(LiteOS)集成开发环境，基于 LiteOS Studio + GCC + JLink># 这篇文章中，我最初使用的是小熊派社区的（bearpi-iot_std_liteos-master）示例程序，而不是华为云HCP-IOT提供的 LiteOS_Lab_HCIP 示例程序。眼尖的我发现，在 bearpi-iot_std_liteos-master.vscode 目录下是存在 launch.json 运行调试配置文件的，某配置下的内容可能如下，

{"version": "0.2.0","configurations": [{"name": "Jlink Debug","cwd": "${workspaceRoot}","request": "launch","type": "liteos-studio-debug","servertype": "jlink","device": "STM32L431RC","showDisassemble": true,"interface": "swd","postLaunchCommands": ["delete","b main","monitor reset halt","continue"]}]
}

用 LiteOS Studio 打开 bearpi-iot_std_liteos-master 项目文件夹，并执行目标板卡、编辑器、烧录器等工程配置后，就会生成一套相对完整的 launch.json + settings.json 文件。其实，不光是小熊派的源码，任何在VSCode下打开的工程，都可以。我们关注Makefile类型。

IDE依赖包（bearpi提供）

参照小熊派社区提供的说明，下载 developTools.zip ，解压并运行 developTools.exe，按提示安装。后文会详解这个依赖包内容。

依赖包安装过程，首先是拷贝，可见 developTools 目录中的内容如下，

除了拷贝上述如交叉编译工具链等，还会触发安装 STM32 ST-LINK Utility、Git 2.38.0 等驱动或工具，

GitBash

Git Bash 能支持代码管理，并不是此处选择它的原因。我们看中的是，GitBash 支持大部分Linux命令，可直接运行为Linux设计的Makefile脚本，使得我们可以在Windows上基于GCC工具链编译Makefile的工程。而cmd和PowerShell本身无法直接解析Makefile文件。

OpenOCD

OpenOCD 是一款开源的调试软件，提供 GDB 服务器、Flash 编程、边界扫描等功能，需依赖硬件调试器（如 ST-Link、J-Link）与目标芯片通信。 ST-Link、J-Link 是物理调试器硬件，负责将 USB 信号转换为 JTAG/SWD 协议信号，直接连接目标设备。STM32系列微控制器内部对 JTAG/SWD 调试协议的支持是硬件集成的，属于芯片设计中的固有功能模块。

以STLink为例，
OpenOCD 需加载 interface/stlink.cfg 配置文件，通过调试器硬件与目标芯片交互。OpenOCD 启动后作为 GDB 服务器，开发者通过 GDB 客户端（如 arm-none-eabi-gdb）发送调试命令，硬件调试器负责信号传输。不同的开发环境，可以依赖相同的调试硬件，但调试机制却不同。这也最可能是我STLInk使用失败的原因，即配置不合理。

STM32CubeIDE 明确依赖 GDB 客户端-服务器架构，而 Keil MDK 则采用专有调试引擎，不直接依赖 GDB 服务器。

STM32CubeIDE 默认使用 OpenOCD 作为调试后端，OpenOCD 充当 GDB 服务器，负责与 ST-Link 硬件通信，翻译调试指令为 SWD/JTAG 协议。用户通过 IDE 集成的 GDB 客户端（如 arm-none-eabi-gdb）发送命令，OpenOCD（GDB服务）转发至 ST-Link，最终操作目标 MCU。

Keil 的 µVision 调试器通过 ULink 协议簇（专有协议）直接与 ST-Link 通信，无需 GDB 服务器中介。其内置的调试引擎直接解析用户操作（如断点设置），并转换为 SWD/JTAG 信号。Keil 支持 CoreSight 技术，通过硬件单元（如 ETM）实现非侵入式追踪，此类功能由调试器直接控制，不依赖 GDB 协议。专有协议减少协议转换开销，适合实时调试。直接支持 SWV（Serial Wire Viewer）、RTOS 线程感知等高级功能，无需额外配置。

GNU MCU Eclipse / make 构建工具

是一款基于 Eclipse IDE 的插件套件，专为嵌入式系统开发设计，支持 ARM Cortex-M/R/A 和 RISC-V 等架构的微控制器（MCU）开发。它通过整合开源工具链、调试工具和硬件支持包，为开发者提供了跨平台的嵌入式开发环境，尤其适用于对成本敏感或需要灵活配置的项目。以下是其核心特性与技术解析，
多架构支持 #原生支持 ARM Cortex-M（如STM32系列）、Cortex-R/A 及 RISC-V 架构，覆盖主流嵌入式芯片，如STM32F1/F4、GD32、ESP32等。提供预配置的工程模板，支持不同厂商的硬件抽象层（HAL）和启动文件生成。
工具链整合 #集成 GNU Arm Embedded Toolchain（GCC编译器）和 OpenOCD（调试与烧录工具），支持源码级调试、Flash编程及JTAG/SWD接口通信 。内置 Windows Build Tools（含GNU Make和BusyBox），弥补Windows环境下Linux命令缺失的问题。
硬件支持扩展 #通过 CMSIS Packs 管理芯片厂商的驱动库（如STM32Cube HAL），自动适配不同MCU的外设配置。支持 ST-Link、J-Link 等调试器，以及 QEMU 模拟器用于无硬件开发测试。

虽然上述套件功能挺多的，但在小熊派提出的这个IDE中，似乎仅仅就是使用了其make工具。这里的make工具也可以直接使用mingw中的make工具，比如Qt安装目录下的，一些大牛就是这么干的，我也实际测试了下，没有问题。

DFP 软件包/芯片驱动/BSP代码

我有一个问题，
Keil下需要安装的那些pack，与芯片相关的驱动等，在GCC+VSCode下如何获取或构建？

DFP（Device Family Pack）本质，是半封闭的硬件支持包，提供预编译的启动代码、闭源驱动库，但包含开源的寄存器定义和链接脚本。与之类似的概念是BSP代码，即板级支持包（Board Support Package）相关的硬件驱动和初始化代码，也即硬件主板与操作系统或用户代码之间的适配层。在Keil开发环境下，我们要安装pack软件包，如DFP，之后才能进行后续编译过程，

继续讨论前，我们必须先看看DFP的内容包含哪些？大致哈，大致如下，可能并不精准，

在了解上述pack的大致内容后，结合自己近来对STM32CubeMX工具的使用经验（也有类似pack配置的过程），若有所思。
当我们在MX中生成MDK工程时，确实是有Pack处理的，MX会在.uvprojx中写入Pack依赖项（如<Package=“Keil.STM32F4xx_DFP” Version=“2.15.0”/>），Keil打开工程时自动安装缺失Pack。CubeMX生成的Makefile不包含Pack引用，所有必需文件（启动代码、HAL库）均以源码形式提供，这些源码MX会替你、替你、替你生成。以下是MX新建的一个GCC类型的工程，

GNU Tools Arm Embedded / 交叉编译工具链

GNU ARM嵌入式工具链（也称为 GNU Arm Embedded Toolchain 或 arm-none-eabi-gcc），专为 ARM Cortex-M/R 系列微控制器（无操作系统/RTOS）开发设计。基于GCC（GNU Compiler Collection）构建，遵循GPL协议，完全免费。支持 Windows、Linux、macOS 全平台兼容。其在代码优化效率方面略逊于Keil/IAR等商业工具链，但相比于其优点，大多时候这可以忽略。

工具链协作，

如上，在GNU ARM嵌入式工具链中，.c文件通过arm-none-eabi-gcc编译为目标文件的过程实际隐含了预处理和汇编阶段，但开发者通常无需手动调用独立工具。当执行arm-none-eabi-gcc -c main.c -o main.o时，GCC内部自动按以下顺序处理：

关于GCC ARM，后期会单独发布一篇文章，这里不再多说。ST 官方提供的命令行工具包（STM32Cube Command-Line Tools），包含预配置的 ARM GCC 编译器（gcc-arm-none-eabi）、CMake、OpenOCD 等工具。 GNU Arm Embedded Toolchain Downloads，也可以直接下载 win32.zip 工具链版本。当然，去GUN官网探索一番也不错。

ST-LINK_Utility

ST-LINK Utility 是意法半导体（STMicroelectronics）为STM32系列微控制器开发的编程与调试工具，支持通过ST-LINK调试器实现代码烧录、芯片信息读取及调试功能。具体参见，ST逛网中的表述，这是个旧工具，ST不再维护它了，而是直接推荐STM32CubeProgrammer软件的使用。ST-LINK Utility / STM32CubeProgrammer 是STM32开发者不可或缺的工具，尤其适合量产烧录和快速调试。

@NOTE
小熊派IoT开发版，板载STLink（基于STM32F103）。为了迎合LiteOS Stduio的使用，前期我已经将其烧录成了JLink固件，可参见IOT专栏下相关文章，实践中确实比直接使用STLink顺心很多。在后文的实验中，针对小熊派开发板，我们也是把STLink当做JLink来使用，针对普通嵌入式板卡我们之间使用JLInk工具，且在实际工作中Jlink的调试性能表现也比STLink强很多。

环境变量

上述 developTools 安装过程在用户环境变量中增加了如下路径，

在系统环境变量中添加了如下路径，

要注意的是，上述安装过程增设的系统环境变量，可能会与某些之前安装软件，如Qt等，在环境变量设置上存在冲突。在 #<IDE/IoT/搭建STM32集成开发环境 / VSCode + GitBash + GCC + Cortex-debug 方案># 文中，我们会详细探讨此问题。

软件项目配置

前文我们已经搭建好了一个编译环境，接下来我们将尝试使用它编译不同类型的工程。如何配置小熊派源码工程是本章重点。

menuconfig 配置

//在Gitbash中执行以下指令，以启动配置工具
start menuconfig.exe

先前并没有正儿八经用过 menuconfig 工具，它是什么样子的，

实际上，menuconfig.exe 和 genconfig.exe 确实属于通用工具。 以下来自于网络，
menuconfig 是 Linux 内核、RT-Thread、鸿蒙、LiteOS等嵌入式操作系统常用的图形化配置工具，其核心基于 Kconfig 语法和 ncurses 库。它通过读取 Kconfig 文件生成菜单界面，允许用户对内核模块、驱动、软件包等进行裁剪和配置，最终生成 .config 文件指导编译流程 。而 genconfig 通常用于将用户通过 menuconfig 选择的配置项（保存在 .config 中）转换为具体的编译宏定义（如 autoconfig.h）。
我现在没有时间去探究什么 Kconfig 语法，只能留给以后。总之如上两个工具可以自动化配置我们的Demo工程。如上图，使用合适的操作，选择我们本次要实验的SC1智慧路灯工程。

我们可以通过 menuconfig 工具来生成 .config 文件，但这需要一个细致的配置过程。在源码 …\targets\STM32L431_BearPi\Demos\oc_nb_lwm2m_light 下存在一个已经精确配置好的 defaults.sdkconfig 文件，其与 menuconfig 粗配置生成的文件，对比如下，

我们这里参照 基于NB-IoT的智慧路灯案例 中的说明，拷贝已有配置文件，

cp Demos/oc_nb_lwm2m_light/defaults.sdkconfig .config

@NOTE
HCIP实验手册中提及的 HCIP_LiteOS_LAB 示例程序，其项目原始配置文件应该是使用menuconfig、genconfig等工具生成的，但为了更好的贴合 LiteOS Stuido 的使用，这些文件有所改动。我尝试使用上述工具解析配置它，并没有成功，可能需要基于KConfig做修正。

genconfig 生成头文件

start genconfig.exe

前文提过， genconfig 用于将用户通过 menuconfig 选择的配置项（保存在 .config 中）转换为具体的编译宏定义，这里生成的是 config.h 文件。关于 menuconfig 和 genconfig 的使用，以后再谈。

STM32CubeMX-xxx.s 启动文件

使用MX新建的GCC工程，与MDK Keil工程类型一致，也有"标准的"启动文件，我是有点小欢喜的。之前我一直以为小熊派给出的示例程序中，是使用了标准启动文件的，因为我曾经在示例源码中搜到过。但实际上并不是想象的那样美好，小熊派的示例程序，并没有像上文 MX-GCC 工程那样，存在一个startup_stm32f427xx.s启动文件。

接下来我把自己扔进了一个更大的坑里，并且截止本文发稿，哈哈，一直没有爬出来，
#<IDE/基于STM32的程序在MDK Keil下的启动过程和中断管理分析>#
#<IDE/基于STM32的程序在GCC工具链下的启动过程和中断管理分析>#
#<IDE/华为云物联网操作系统LiteOS如何接管STM32硬件中断管理?>#
尽管截止到此刻，上述几个文章都还没有整理完成，我还有一堆为什么在脑海里，窝成一团。我目前搞明白的仅仅是：
1、针对STM32F427ZIT6芯片在MDK-Keil和GCC工具链下的startup_stm32f427xx.s启动文件差异，其根本原因在于汇编语法规范、工具链工作流程及初始化机制的不同。具体的不同，这里就不展开啦，可能需要很强的汇编知识基础和嵌入式ARM架构知识才能看懂吧。
2、STM32启动文件是芯片上电后执行的首个程序，负责初始化微控制器的底层环境并引导至 main() 函数。其核心功能，

3、启动文件是作为源文件（ASM汇编）参与编译过程的。打开MX-Makefile文件，可以看到有如下语句和启动文件相关，

# ASM sources
ASM_SOURCES =  \
startup_stm32f427xx.s# ASM sources
ASMM_SOURCES = 
....

在 Makefile 中，变量名 ASM_SOURCES 中的 ASM 是 Assembler（汇编器）或 Assembly（汇编语言）的缩写。

启动文件是ASM汇编文件，也算是一种代码级别的东东，也要参与编译过程，生成目标文件，其通过汇编器直接生成为.o文件。

LiteOS 接管中断管理

前文提到，即使是小熊派的源码程序，也没有使用标准的启动文件。这是为啥呢?
其实，LiteOS 有两种移植方案，OS接管中断和非接管中断方式。接管中断的方式，是由LiteOS创建和管理大部分中断，需要修改stm32启动文件，移植比较复杂。小熊派的示例工程中，使用的就是后边这种难的，当然这是更使用于物联网应用场景的。我个人感觉，随着CubeMX兴起，LiteOS非接管中断方式，可能会是主流移植方式，以后新建自己的工程，我也大概率会使用LiteOS非接管中断方式移植模式。

最近时间略紧张，再加上自身基础知识有限，暂时不去研究 “LiteOS 是如何接管 STM32 硬件中断管理” 这个问题了。

软件编译

这里的make和gcc的执行都是依赖于系统环境变量配置的，在其他文章中会继续探讨不依赖系统环境变量的方案。

$ make clean
$ make -j8

我们使用VSCode打开，小熊派社区示例程序 bearpi-iot_std_liteos-master\targets\STM32L431_BearPi 文件夹，

Makefile工程文件就在此文件夹下，通过menuconfig工具设置工程为智慧路灯项目。
图省事的话，你可直接从 …\targets\STM32L431_BearPi\Demos\oc_nb_lwm2m_light 下复制默认文件去覆盖 .config 内容。还要记住的是，不是拷贝过去就万事大吉了哈，还要调用 genconfig 生成更新 iot_config.h 头文件，否则编译失败哈。

若VSCode打开的不是Makefile所在的路径，则编译时需要cd到Makefile路径之下，再进行编译。编译结果如下，

软件烧录

烧录前，先将小熊派开发板通过USB线与电脑连接。执行如下烧录指令，

$ make download

make download 指令是如何知道我使用了怎样的调试器或者调试协议的呢？

#######################################
# download
#######################################
OPENOCD_INTERFACE = stlink-v2-1.cfg
OPENOCD_TARGET = stm32l4x.cfg
OPENOCD_FLASH_START = 0x08000000
download:openocd -f $(SDK_DIR)/tools/openocd/$(OPENOCD_INTERFACE) -f $(SDK_DIR)/tools/openocd/$(OPENOCD_TARGET) -c init -c targets -c "reset halt" -c "flash write_image erase ./$(BUILD_DIR)/$(TARGET).bin 0x08000000" -c "verify_image ./$(BUILD_DIR)/$(TARGET).bin 0x08000000 bin" -c "reset run" -c shutdown

而如果使用JLink调试器（或STLink硬刷出来的JLink），配置会更简单些，注释掉上述配置，更换如下配置，

#######################################
# download 大河.qu
#######################################
# 添加烧录工具路径（根据实际安装位置调整）
JLINK_EXE ?= "C:\\Program Files (x86)\\SEGGER\JLink\\JLink.exe"
# 定义烧录目标
download:$(JLINK_EXE) -device STM32L431RC -if SWD -speed 4000 -CommanderScript ./flash.jlink

flash.jlink 文件，新建在Makefile所在目录下，内容如下，

halt                // 暂停 CPU
erase               // 全擦除
//加载bin/hex到指定的地址
loadfile ./build/Huawei_LiteOS.bin 0x08000000 
r                   // 复位芯片
sleep 10            // 延时确保复位稳定 /可能不需要
g                   // 运行程序 
exit                // 退出

下载完成，示例图，

软件调试

参见 #<IDE/基于VSCode搭建STM32集成开发环境 / Cortex-debug插件工作原理和使用方法（含3种JLink烧录方案）># ，理解 Cortex-Debug 插件使用方法。
在使用 LiteOS Studio 进行调试时，调试器类型为 liteos-studio-debug，要修改 launch.json 文件，替换为 cortex-debug。
配置 settings.json 也要进行修改，且不建议使用小熊派社区提供的工具链依赖包。具体参考，
#<IDE/IoT/搭建STM32集成开发环境 / VSCode + GitBash + GCC + Cortex-debug 方案>#

要配合 Cortex-Debug使用的话，小熊派提供的IDE依赖包，版本有点低，

需要更换较新版本低gdb客户端，如…gcc-arm-none-eabi-10.3\bin\arm-none-eabi-gdb.exe，进入调试，

运行测试

参见 #<IDE/基于STM32CubeMX构建Makefile工程，并实践工程配置、管脚配置、程序编译># ，理解 GCC 工具链下的 printf 输出重定向到指定串口。示例程序已实现了 printf的重定向，在 …\targets\STM32L431_BearPi\Src\uart_debug.c 文件中，

__attribute__((used)) int _write(int fd, char *ptr, int len)
{if(s_uart_init)  {HAL_UART_Transmit(&uart_debug, (uint8_t *)ptr, len, 0xFFFF);}return len;
}
__attribute__((used)) int _read(int fd, char *ptr, int len)
{int ret = 0;unsigned char  value;do {if(LOS_OK == LOS_SemPend(s_uartdebug_rcv_sync,LOS_WAIT_FOREVER)){ret = ring_buffer_read(&s_uartdebug_rcv_ring,&value,1);}} while(ret <=0);*(unsigned char *)ptr = value;return 1;
}

智慧路灯实验，平台侧结果显示，