1. Windows平台下基于VSCode的STM32 GCC轻量级开发环境构建

在嵌入式系统工程实践中，开发环境的选择直接影响项目迭代效率与团队协作质量。传统Keil MDK或IAR Embedded Workbench虽功能完备，但商业授权成本高、配置复杂、跨平台支持弱，对初学者和中小型项目构成显著门槛。近年来，以GCC工具链为核心的开源生态日益成熟，配合VSCode这一高度可定制的现代编辑器，已能完整覆盖STM32项目的编译、烧录、调试及变量实时监控全流程。本文将基于真实工程经验，系统阐述如何在Windows平台上构建一套稳定、轻量、开源且长期可用的STM32 GCC开发环境。该方案不依赖任何商业软件，所有组件均为官方发布版本，配置一次即可复用于多个STM32系列芯片（F0/F1/F4/H7等），并具备向Linux/macOS平台平滑迁移的能力。

1.1 工程目标与能力边界定义

构建本环境的核心目标并非替代专业IDE，而是提供一个 最小可行、原理透明、易于调试 的工程基线。其最终实现能力包括：

  • 全链路编译 ：支持C/C++源码编译、链接，生成标准ELF格式可执行文件，并可导出为BIN/HEX格式用于量产烧录；
  • 无侵入式烧录 ：通过ST-Link V2/V3等标准调试器，完成程序下载、Flash校验、复位运行全流程；
  • 原生级调试 ：支持设置断点、单步执行、寄存器查看、内存监视，以及 全局变量与局部变量的实时值观测 ；
  • 工程可移植性 ：基于Makefile构建系统，工程结构清晰，可脱离VSCode在命令行中独立编译；
  • 扩展友好性 ：预留CMake集成接口，当项目规模扩大时可无缝升级为CMake管理。

需明确的是，该环境 不内置printf重定向、USB CDC虚拟串口、RTOS图形化调试插件等高级功能 。这些属于应用层增强，应在基础环境稳定后按需添加。本文聚焦于构建“能跑、能调、能看”的底层能力，确保开发者对编译链接、调试协议、工具链交互等核心机制建立直观认知。

1.2 工具链选型与版本兼容性分析

工具链的稳定性源于各组件间的严格版本匹配。经大量实测验证，以下组合在Windows 10/11环境下表现最为可靠：

组件 推荐版本 获取方式 关键特性说明
ARM GCC Compiler GNU Arm Embedded Toolchain 10.3-2021.10 ARM官网或压缩包内提供 支持ARMv6-M/v7-M/v8-M指令集，FPU浮点运算支持完备， -mcpu 与 -mfpu 参数定义清晰
Build System GNU Make 4.3 GnuWin32项目或压缩包内提供 Windows原生Make实现，无需MSYS2/MinGW环境，与VSCode任务系统兼容性最佳
Debug Server OpenOCD 0.12.0 OpenOCD官网或压缩包内提供 对ST-Link固件支持完善， stlink.cfg 与芯片-specific配置分离清晰，避免版本冲突

特别强调： 严禁混用不同来源的工具链 。例如，从ARM官网下载的GCC与从Chocolatey安装的OpenOCD可能因路径约定或DLL依赖产生不可预知错误。本文推荐的“一键压缩包”方案，已将上述三者及其依赖（如 libusb-1.0.dll ）统一打包，所有二进制文件均经过交叉验证，可直接解压使用。

1.3 目录结构设计与路径规划原则

合理的目录结构是环境长期可维护的基础。我们采用分层隔离设计，避免工具链与工程代码相互污染：

D:\toolchain\
├── gcc\          # ARM GCC编译器根目录
│   └── bin\      # arm-none-eabi-gcc.exe等可执行文件所在
├── make\         # GNU Make根目录
│   └── bin\      # make.exe所在
└── openocd\      # OpenOCD根目录
    └── bin\      # openocd.exe及scripts目录

此结构遵循三大原则：
- 隔离性 ：工具链位于独立磁盘分区（如D:\），避免因系统盘清理误删；
- 确定性 ：每个工具的 bin 目录路径唯一且固定，便于环境变量配置；
- 可追溯性 ：目录名明确标识工具类型与版本（如 gcc-10.3-2021.10 ），未来升级时可并行共存。

工程师实践提示 ：切勿将工具链解压至 C:\Program Files 等含空格或特殊权限路径。Windows下路径空格会导致Makefile中 $(CC) 变量解析失败，引发 No rule to make target 等隐晦错误。这是新手最常踩的坑之一。

2. 系统级环境变量配置

环境变量是操作系统识别命令行工具的唯一途径。配置不当将导致VSCode无法调用编译器，是环境搭建失败的首要原因。

2.1 配置流程与验证方法

  1. 打开系统环境变量设置 ：
    按 Win + R → 输入 sysdm.cpl → 切换到“高级”选项卡 → 点击“环境变量”。

  2. 编辑用户变量中的Path ：
    在“用户变量”区域找到 Path ，双击进入编辑界面。点击“新建”，依次添加以下三条路径（请严格对应你解压的实际路径）：
    D:\toolchain\gcc\bin D:\toolchain\make\bin D:\toolchain\openocd\bin

  3. 强制刷新环境变量 ：
    关闭所有已打开的命令行窗口（CMD/PowerShell/VSCode终端）。重新打开一个新的CMD窗口，执行以下命令验证：
    bash arm-none-eabi-gcc -v make -v openocd -v
    每条命令应输出对应工具的详细版本信息。若提示“不是内部或外部命令”，请检查路径拼写、斜杠方向（Windows必须为反斜杠 \ ）及是否遗漏 bin 子目录。

2.2 路径配置中的关键细节

  • 斜杠方向修正 ：
    Windows系统要求路径分隔符为反斜杠 \ ，而GCC工具链内部脚本（如 arm-none-eabi-gcc ）默认使用正斜杠 / 。此差异在VSCode的JSON配置中尤为关键。例如，在 c_cpp_properties.json 中指定编译器路径时：
    json "compilerPath": "D:\\toolchain\\gcc\\bin\\arm-none-eabi-gcc.exe"
    必须使用双反斜杠 \\ 进行转义。若直接粘贴资源管理器中复制的路径（如 D:\toolchain\gcc\bin\arm-none-eabi-gcc.exe ），VSCode会将其解析为非法转义序列而报错。

  • 避免路径冲突 ：
    若系统中已存在其他GCC（如MinGW或WSL中的GCC），其路径可能已加入 Path 。此时需将 D:\toolchain\gcc\bin 置于 Path 列表 最上方 ，确保系统优先调用ARM专用编译器。可通过在CMD中执行 where arm-none-eabi-gcc 确认实际调用路径。

  • 权限与防病毒软件干扰 ：
    部分国产杀毒软件（如360、腾讯电脑管家）会将 openocd.exe 误判为风险程序并阻止其访问ST-Link设备。首次运行OpenOCD时若出现“Access Denied”错误，请临时关闭杀软或将其加入白名单。

3. STM32CubeMX工程生成与Makefile适配

STM32CubeMX是ST官方提供的图形化配置工具，其核心价值在于自动生成符合HAL库规范的初始化代码。但默认生成的工程面向Keil/IAR，需进行针对性改造以适配GCC Makefile构建系统。

3.1 CubeMX关键配置项解析

在CubeMX中生成工程时，以下配置直接影响后续GCC编译的成败：

  • Project Manager → Toolchain / IDE ：
    必须选择 Makefile 。此选项 instructs CubeMX 生成 Makefile 而非 .uvprojx 或 .ewp 。其他选项（如SW4STM32）虽也生成Makefile，但其结构与本文方案不兼容。

  • System Core → SYS → Debug ：
    根据调试器类型选择：

  • ST-Link：勾选 Serial Wire （推荐，占用引脚少）或 JTAG ；

  • CMSIS-DAP：勾选 SWD 。
    此配置决定 main.c 中 HAL_Init() 后调用的调试接口初始化函数。

  • Clock Configuration ：
    确保HSE（外部高速晶振）或HSI（内部高速RC）配置正确。GCC链接脚本（ STM32F407VGTx_FLASH.ld ）中定义的Flash起始地址（ 0x08000000 ）与RAM大小（ 0x20000000 起始）严格依赖于此处的时钟树设置。若时钟配置错误，程序可能启动即死机。

  • Pinout & Configuration → Peripherals ：
    所有启用的外设（如USART1、SPI1）将自动生成对应的 MX_xxx_Init() 函数，并在 main.c 的 while(1) 前被调用。此过程完全自动化，无需手动编写寄存器操作。

3.2 Makefile工程结构剖析

CubeMX生成的Makefile工程包含以下核心文件，理解其作用是后续调试的基础：

文件 作用 工程中位置
Makefile 主构建脚本，定义编译规则、链接脚本、目标文件依赖关系 工程根目录
startup_stm32f407xx.s 启动汇编代码，包含复位向量表、栈指针初始化、 SystemInit() 调用 Core\Startup\
STM32F407VGTx_FLASH.ld GNU LD链接脚本，定义Flash/RAM内存布局、段（ .text , .data , .bss ）分配 Core\
Drivers/ HAL库源码与头文件，由CubeMX根据所选外设自动裁剪 Drivers\

关键洞察 ： Makefile 中 CPU_FLAGS 变量（如 -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4 ）必须与目标芯片的CPU架构严格匹配。F4系列需 cortex-m4 ，F1系列则为 cortex-m3 ；若启用FPU，则 -mfloat-abi 必须为 hard ，否则浮点运算将异常。

3.3 VSCode工程导入与工作区初始化

VSCode本身不管理构建系统，其角色是作为智能编辑器与任务调度器。导入CubeMX生成的工程步骤如下：

  1. 安装必要插件 ：
    - Cortex-Debug （必备，提供GDB调试接口）；
    - C/C++ （微软官方，提供IntelliSense与语法检查）；
    - Chinese (Simplified) Language Pack （可选，中文界面支持）。

  2. 打开工程文件夹 ：
    在VSCode中， File → Open Folder ，选择CubeMX生成的工程根目录（含 Makefile 的文件夹）。VSCode会自动识别为C/C++项目。

  3. 初始化工作区配置 ：
    首次打开时，VSCode会在工程根目录下创建 .vscode/ 子文件夹，其中包含：
    - c_cpp_properties.json ：配置IntelliSense引擎的编译器路径、包含目录、宏定义；
    - tasks.json ：定义 build 与 flash 等可执行任务；
    - launch.json ：配置调试会话，指定GDB路径、OpenOCD配置、SVD文件。

工程师实践提示 ： .vscode/ 文件夹应纳入Git版本控制。它记录了团队成员共享的标准化开发环境，避免“在我机器上能跑”的协作陷阱。

4. VSCode核心配置文件详解

VSCode的智能化高度依赖三个JSON配置文件的精准设定。任何一处参数错误都将导致编译失败或调试中断。

4.1 c_cpp_properties.json ：智能感知的基石

此文件指导VSCode的C/C++扩展如何解析代码。典型配置如下：

{
  "configurations": [
    {
      "name": "STM32F4",
      "includePath": [
        "${workspaceFolder}/**",
        "${workspaceFolder}/Drivers/STM32F4xx_HAL_Driver/Inc/**",
        "${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32F4xx/Include/**",
        "${workspaceFolder}/Drivers/CMSIS/Include/**"
      ],
      "defines": [
        "USE_HAL_DRIVER",
        "STM32F407xx"
      ],
      "compilerPath": "D:\\toolchain\\gcc\\bin\\arm-none-eabi-gcc.exe",
      "cStandard": "c11",
      "cppStandard": "c++17",
      "intelliSenseMode": "linux-gcc-arm"
    }
  ],
  "version": 4
}

参数解析 ：
- includePath ：必须包含HAL驱动、CMSIS设备头文件、CMSIS核心头文件三级路径。 /** 表示递归包含所有子目录，确保 #include "stm32f4xx_hal.h" 等语句能被正确解析。
- defines ：宏定义必须与CubeMX生成的 main.h 中一致。 STM32F407xx 定义激活F4系列特定寄存器映射； USE_HAL_DRIVER 启用HAL库。
- compilerPath ：指向ARM GCC编译器绝对路径，必须使用双反斜杠转义。
- intelliSenseMode ： linux-gcc-arm 是VSCode对ARM GCC的专用模式，比通用 gcc-arm 提供更准确的函数跳转与参数提示。

4.2 tasks.json ：构建与烧录的自动化中枢

此文件将 make 命令封装为VSCode可识别的任务。关键配置如下：

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build",
      "type": "shell",
      "command": "make",
      "args": ["-j8"],
      "group": "build",
      "presentation": {
        "echo": true,
        "reveal": "always",
        "focus": false,
        "panel": "shared",
        "showReuseMessage": true,
        "clear": true
      },
      "problemMatcher": "$gcc"
    },
    {
      "label": "flash",
      "type": "shell",
      "command": "make",
      "args": ["flash"],
      "group": "build",
      "presentation": {
        "echo": true,
        "reveal": "always",
        "focus": false,
        "panel": "shared",
        "showReuseMessage": true,
        "clear": true
      }
    }
  ]
}

关键参数说明 ：
- "args": ["-j8"] ： -j 参数指定并行编译作业数。 -j8 表示同时启动8个编译进程，可显著缩短大型工程编译时间。数值建议设为CPU逻辑核心数（如i7-8700K为12核，可设 -j12 ）。
- "problemMatcher": "$gcc" ：启用GCC问题匹配器，自动将编译器输出的 error: 与 warning: 行高亮为红色/黄色，点击可直接跳转到错误行。
- flash 任务调用 make flash ，其行为由 Makefile 中 flash: 目标定义，通常执行 openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c "program build/your_project.elf verify reset exit" 。

4.3 launch.json ：调试会话的精密控制

此文件是调试功能的核心，其配置精度直接决定能否成功连接芯片并观测变量：

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "STM32F4 Debug",
      "type": "cortex-debug",
      "request": "launch",
      "servertype": "openocd",
      "cwd": "${workspaceRoot}",
      "executable": "./build/your_project.elf",
      "device": "STM32F407VG",
      "configFiles": [
        "interface/stlink.cfg",
        "target/stm32f4x.cfg"
      ],
      "svdFile": "${workspaceRoot}/STM32F407VGTx.svd",
      "preLaunchTask": "build",
      "overrideAttach": true,
      "armToolchainPath": "D:\\toolchain\\gcc\\bin",
      "showDevDebugOutput": false,
      "postLaunchCommands": [
        "monitor reset halt",
        "monitor flash write_image erase ./build/your_project.elf"
      ]
    }
  ]
}

核心参数深度解析 ：
- "executable" ：必须指向 build/ 目录下生成的 .elf 文件，而非 .hex 或 .bin 。ELF格式包含完整的符号表（Symbol Table），是GDB实现变量观测的前提。
- "configFiles" ： interface/stlink.cfg 定义ST-Link硬件通信协议； target/stm32f4x.cfg 定义F4系列芯片的Flash编程算法与内存映射。二者缺一不可。
- "svdFile" ：SVD（System View Description）文件是CMSIS标准的芯片外设描述XML。它使调试器能将 0x40013800 这样的物理地址映射为 GPIOA->ODR 这样的可读名称，实现外设寄存器的可视化观测。SVD文件需从 ST官网SVD页面 下载对应芯片型号。
- "preLaunchTask": "build" ：确保每次启动调试前自动执行 build 任务，避免调试陈旧代码。
- "postLaunchCommands" ： monitor reset halt 强制芯片复位并停在复位向量； monitor flash write_image erase 执行擦除-编程-校验全流程，确保Flash内容最新。

5. 编译、烧录与调试全流程实战

理论配置完成后，需通过具体操作验证环境完整性。以下以一个LED闪烁工程为例，演示端到端流程。

5.1 创建最小可验证工程

  1. CubeMX配置 ：
    - MCU选择 STM32F407VGTx ；
    - SYS → Debug 设为 Serial Wire ；
    - Pinout 中将 PA5 （LED常用引脚）配置为 GPIO_Output ；
    - Project Manager → Project Name 设为 led_blink ；
    - Toolchain / IDE 选择 Makefile ；
    - 点击 Generate Code 。

  2. 添加应用代码 ：
    在 Src/main.c 的 while(1) 循环中添加：
    c HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5); HAL_Delay(500);

5.2 编译与烧录操作

  • 编译 ：
    Ctrl+Shift+B → 选择 build 任务 → 回车。终端将显示 make -j8 执行过程，最终输出 arm-none-eabi-size build/led_blink.elf ，显示代码/数据/堆栈占用大小。若出现 undefined reference to 'HAL_GPIO_TogglePin' ，检查 Drivers/STM32F4xx_HAL_Driver/Src/ 下的 .c 文件是否被正确加入 Makefile 的 CSRCS 变量。

  • 烧录 ：
    Ctrl+Shift+B → 选择 flash 任务 → 回车。OpenOCD日志将显示：
    Info : STLINK v2 JTAG v37 API v2 SWIM v7 VID 0x0483 PID 0x3748 Info : clock speed 1000 kHz Info : STLINK v2 device has a jtag speed of 1000 kHz Info : Target voltage: 3.221703 Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints Info : starting download Info : Flash write completed at address 0x08000000 in 0.234s Info : Verified OK Info : Resetting target
    若卡在 Target voltage ，检查ST-Link与开发板的 3.3V 、 GND 、 SWDIO 、 SWCLK 四线是否连接牢固。

5.3 调试与实时变量观测

  1. 启动调试 ：
    F5 或点击左侧调试图标 → 选择 STM32F4 Debug 配置 → 开始。VSCode底部状态栏将显示 Debugging ，OpenOCD窗口弹出。

  2. 设置断点与单步 ：
    在 HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5); 行左侧灰色区域单击，设置断点。程序将在该行暂停，右侧“变量”面板自动显示 GPIOA （GPIO_TypeDef结构体）、 GPIO_PIN_5 （uint32_t值为 0x00000020 ）。

  3. 实时变量观测（Watch） ：
    在“监视”面板点击 + 号，输入 GPIOA->ODR ，回车。该表达式将实时显示GPIOA输出数据寄存器的值（如 0x00000020 表示PA5输出高电平）。连续按 F10 （单步跳过），可观察 ODR 值在 0x00000020 与 0x00000000 间切换。

  4. 修改变量值（调试技巧） ：
    在“变量”面板中右键 GPIOA->ODR → Set Value → 输入 0xFFFFFFFF 。此时PA0-PA15全部输出高电平，可快速验证GPIO配置。

工程师实践提示 ：若“变量”面板为空，首先检查 .elf 文件是否生成（ build/ 目录下是否存在）；其次确认 launch.json 中 executable 路径是否正确；最后检查SVD文件路径是否有效。常见错误是SVD文件名与芯片型号不匹配（如F407VGTx误用F407VE.svd）。

6. 外部库集成与工程扩展

实际项目中，常需集成第三方库（如OLED显示屏驱动、FatFS文件系统）。本文以GitHub上的 SSD1306 OLED库为例，说明集成方法。

6.1 库文件组织与Makefile适配

假设库文件结构如下：

OLED/
├── Inc/
│   └── ssd1306.h
└── Src/
    └── ssd1306.c

集成步骤：
1. 将 OLED/ 文件夹复制到工程根目录；
2. 修改 Makefile 中 INC_DIRS 变量，添加OLED头文件路径：
makefile INC_DIRS := $(addprefix -I,$(wildcard $(PROJECT_DIR)/OLED/Inc))
3. 修改 CSRCS 变量，添加OLED源文件：
makefile CSRCS += $(wildcard $(PROJECT_DIR)/OLED/Src/*.c)

6.2 VSCode配置同步更新

  • c_cpp_properties.json ：在 includePath 中添加 "${workspaceFolder}/OLED/Inc" ；
  • tasks.json ：无需修改， make 会自动识别新增的 .c 文件；
  • launch.json ：无需修改，调试器通过ELF符号表自动索引新函数。

6.3 库初始化与调用验证

在 main.c 中：

#include "ssd1306.h"

int main(void) {
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();
  MX_SPI1_Init(); // OLED通常接SPI
  ssd1306_Init(); // 初始化OLED
  ssd1306_DrawString(0, 0, "Hello World!", Font_11x18, White);
  ssd1306_UpdateScreen();
  while (1) { }
}

编译后，OLED屏幕将显示”Hello World!”。若显示乱码，检查SPI引脚配置（ SCK , MOSI , CS , DC , RST ）是否与库要求一致。

7. 常见问题诊断与解决方案

7.1 编译阶段典型错误

  • arm-none-eabi-gcc: command not found ：
    环境变量 Path 未正确配置，或VSCode终端未继承新环境变量。解决：重启VSCode，或在VSCode终端中执行 $env:Path += ";D:\toolchain\gcc\bin" （PowerShell）。

  • undefined reference to 'HAL_Delay' ：
    Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_tim.c 未加入 CSRCS 。CubeMX生成的 Makefile 有时会遗漏此文件，需手动添加。

  • error: 'HAL_GPIO_TogglePin' undeclared ：
    #include "stm32f4xx_hal_gpio.h" 缺失，或 c_cpp_properties.json 中 includePath 未包含HAL GPIO头文件路径。

7.2 烧录与调试阶段故障

  • OpenOCD连接失败：”Error: unable to find a matching CMSIS-DAP device” ：
    ST-Link驱动未安装。前往ST官网下载 STSW-LINK009 ，安装 ST-Link USB Driver 。

  • 调试时变量显示 <optimized out> ：
    编译器优化等级过高（如 -O2 ）。在 Makefile 中查找 OPT = -Og （调试优化），确保其值为 -Og （专为调试优化）或 -O0 （无优化）。

  • SVD文件加载失败：”Failed to load SVD file” ：
    launch.json 中 svdFile 路径错误，或SVD文件损坏。验证：用浏览器打开SVD文件，确认其为合法XML格式。

7.3 性能调优建议

  • 编译加速 ：在 tasks.json 中将 -j8 提升至 -j$(nproc) （Linux）或 -j$(Get-ComputerInfo).CsNumberOfLogicalProcessors （PowerShell），充分利用多核。
  • 调试响应 ：在 launch.json 中添加 "armToolchainPath" ，显式指定GDB路径，避免VSCode自动搜索耗时。
  • Flash编程提速 ：在 Makefile 的 flash 目标中，将 openocd 命令的 -c "program ..." 替换为 -c "program ... verify" ，跳过校验步骤（仅限开发阶段）。

8. 进阶：向CMake构建系统的平滑演进

当项目规模超过50个源文件或需支持多平台（Windows/Linux/RTOS）时，Makefile的维护成本急剧上升。此时应迁移到CMake，其优势在于：

  • 跨平台一致性 ：同一 CMakeLists.txt 可在Windows（Ninja）、Linux（Make）、macOS（Xcode）下生成本地构建文件；
  • 依赖管理清晰 ： target_link_libraries() 显式声明库依赖，避免Makefile中隐式链接错误；
  • IDE集成友好 ：CLion、Qt Creator等IDE原生支持CMake，无需额外配置。

迁移步骤简述：
1. 在工程根目录创建 CMakeLists.txt ，定义 cmake_minimum_required(3.10) 、 project(led_blink) ；
2. 使用 find_package(CMSIS REQUIRED) 定位CMSIS库；
3. 通过 add_executable() 添加可执行目标， target_sources() 添加源文件；
4. 用 target_compile_options() 设置 -mcpu 等标志；
5. 在VSCode中安装 CMake Tools 插件，按 Ctrl+Shift+P → CMake: Configure 生成构建文件。

此演进路径已在多个量产项目中验证，可确保从入门到专业的无缝过渡。

我曾在某工业网关项目中，初始使用本文所述Makefile方案开发Bootloader，当应用层增加FreeRTOS、LwIP、MQTT后，果断切换至CMake。整个迁移过程仅耗时半天，所有调试功能（包括RTOS线程视图）均完整保留。这印证了本文构建的底层能力具有极强的延展性——它不是一个封闭的玩具环境，而是一套经得起工程考验的坚实基座。

Logo
openvela

openvela 操作系统专为 AIoT 领域量身定制，以轻量化、标准兼容、安全性和高度可扩展性为核心特点。openvela 以其卓越的技术优势，已成为众多物联网设备和 AI 硬件的技术首选，涵盖了智能手表、运动手环、智能音箱、耳机、智能家居设备以及机器人等多个领域。

更多推荐

cover

Arm Ethos‑U65：YOLOv8n 模型准备与 Vela 编译

avatar openvela
cover

Arm Ethos-U65 介绍（1） 架构、数据格式与算子

avatar openvela

UniAD_v2 模型NPU适配

参考github网址：https://github.com/OpenDriveLab/UniAD/tree/v2.0参考readme：https://gitcode.com/Ascend/DrivingSDK/blob/master/model_examples/UniAD/README.md。

avatar openvela