夜雨聆风▼点击下方名片，关注公众号，获取更多精彩内容▼
大家好，我是贺老师，嵌入式 AI工程师，《嵌入式AI：让单片机学会思考》课程主理人，专注AI在MCU上的落地实践。
一、各类芯片与板卡生态的 IDE / 开发环境
瑞萨关于嵌入式AI这块确实也不弱，瑞萨官方也再一直推荐自家的嵌入式AI的方案。e² studio 是 Renesas 面向 RA、RZ、RL78、RX、RH850、RISC-V MCU 等系列的 Eclipse 系集成开发环境。它覆盖样例代码下载、工程创建、构建、烧录和调试，是瑞萨 MCU 项目常见的官方入口。
在嵌入式 AI 方向，瑞萨还有 e-AI、Reality AI Tools 等相关工具。瑞萨官方资料中提到，e-AI 可以把 PyTorch、Keras、TensorFlow、TensorFlow Lite 量化模型等转换并导入到 e² studio 相关环境中。也就是说，瑞萨的 AI 链路不是单独看一个 IDE，而是 e² studio + FSP / SDK + AI 工具组合使用。
Arduino IDE：快速演示和轻量验证的低门槛入口
Arduino IDE 不是某一家芯片厂商的专属 IDE，更准确地说，它是板卡生态入口。很多 TinyML 示例选择 Arduino Nano 33 BLE Sense、ESP32 或兼容板，就是因为库安装方便、示例多、上手快。它适合快速演示传感器采样、简单推理、串口输出。
它的短板也很明显：工程结构管理、调试能力、复杂外设配置和长期维护能力都比较弱。适合 Demo 和轻量原型，不适合把复杂嵌入式 AI 产品长期放在 Arduino 工作流里维护。
PlatformIO：多开发板原型验证的高频工具
PlatformIO 也不是芯片原厂 IDE，而是跨平台嵌入式开发环境。它把板卡配置、库管理、编译、烧录、串口监视整合进 VS Code 工作流，对 ESP32、Arduino、部分 STM32 原型验证很友好。
如果项目目标是快速比较多块开发板，PlatformIO 会比手工配置多个 IDE 省事。但如果项目深度依赖某家厂商的 AI 工具链，例如 STM32Cube.AI、NXP eIQ 或瑞萨 e-AI，就要提前确认生成代码、链接脚本、启动文件和调试链路能否顺利接入。
二、Keil MDK 与 IAR：独立于芯片原厂的专业 IDE
Keil MDK
Keil MDK 在 Cortex-M 项目里仍然非常常见，很多工业控制项目、存量工程、RTOS 示例和芯片支持包都围绕它建立。它的优势是ARM生态成熟，调试链路稳定，CMSIS 支持完整。对于已经使用 Keil 的项目，把 AI 推理模块作为新增组件接进去，往往比重建整个工程更现实。
在嵌入式 AI 项目里，Keil 的价值主要体现在固件侧：查看内存、调试 HardFault、定位栈溢出、分析外设驱动、管理 RTOS 任务。模型训练不在 Keil 里完成，但模型部署后出现的很多问题，最终都要回到固件调试。
IAR Embedded Workbench
IAR 更偏商业交付和高可靠场景。它的编译器优化、C-SPY 调试器、静态分析、功能安全相关生态，是很多工业、汽车、医疗类项目愿意采用它的原因。对嵌入式 AI 来说，IAR 不是为了更好训练模型，而是为了让最终固件在体积、速度、调试和交付规范上更可控。
如果项目已经进入量产阶段，或者对编译器、代码体积、长期维护和工具支持有明确要求，IAR 值得认真评估。
三、VS Code：跨平台嵌入式 AI 项目的统一工作台
VS Code 本身不是传统意义上的嵌入式 IDE，但现在已经很难绕开。嵌入式 AI 项目一般同时包含了C/C++ 固件、Python 数据脚本、模型文件、量化工具、日志分析脚本和测试数据等。
传统 IDE 往往只擅长产生固件，VS Code 更适合把这些内容放到一个项目结构里统一管理。
典型组合是 VS Code + CMake + GCC + OpenOCD / J-Link，再根据芯片平台接入对应 SDK。
STM32 可以使用 STM32 VS Code 相关扩展或 CMake 工程；
ESP32 可以使用 ESP-IDF VS Code 扩展；
多开发板原型可以使用 PlatformIO。它的优势是跨平台、可脚本化、Git 友好，也更容易接入持续集成。
它的风险是自由度太高。工具链路径、芯片包版本、Python 依赖、调试器配置、CMake 参数，如果没有明确记录，很容易出现“这台电脑能编译，另一台电脑不行”。因此 VS Code 适合工程规范比较清楚的项目，不适合靠手工配置一路试出来。
嵌入式 AI 项目更推荐这样的目录结构：project/ firmware/ MCU 固件工程 models/ 模型文件、量化结果、权重头文件 scripts/ 数据处理、模型转换、日志分析脚本 datasets/ 原始数据、验证数据、标注说明 docs/ 接线说明、部署步骤、测试记录 tools/ 串口工具、benchmark、自动化脚本四、Edge Impulse 与厂商 AI Studio：不是传统 IDE，但很关键
嵌入式 AI 项目里，还有一类工具不能忽略：它们不是传统 IDE，却承担了模型开发工作台的角色。
Edge Impulse 覆盖数据采集、特征提取、模型训练、量化、部署库生成，适合快速完成从数据到模型的闭环。它不能替代 CubeIDE、Keil、IAR 或 VS Code 写固件，但能显著降低数据和模型阶段的成本。坏处是收费。
ST 的 STM32Cube AI Studio、ST Edge AI Developer Cloud，TI 的 Edge AI Studio，NXP 的 eIQ 相关工具，瑞萨的 e-AI / Reality AI Tools，也都属于这个趋势：厂商不再只提供 C IDE，而是把模型库、量化、部署、benchmark、示例工程整合到一起。
对嵌入式 AI 来说，未来很少是“一个 IDE 解决所有问题”，更常见的是“固件 IDE + AI Studio + 脚本工具 + 云端 benchmark”的组合。AI Studio 能缩短模型到设备的距离，但不能替代板级调试。真实项目仍然要回到 IDE 里处理传感器采样、DMA、缓存一致性、RTOS 调度、串口日志、功耗和异常状态。
五、最后怎么选：按项目类型给一个直接结论
STM32 + TinyML 项目：优先 STM32CubeIDE + STM32Cube.AI / STM32Cube AI Studio。先把模型资源占用、推理时间和板端输出跑通，再考虑是否迁移到 VS Code 或 CMake 工作流。
ESP32 AI 项目：优先 ESP-IDF + VS Code 扩展。摄像头、语音、网络、PSRAM 和 FreeRTOS 都和官方框架关系紧密，手工拼工具链不划算。
NXP 平台项目：优先 MCUXpresso / MCUXpresso for VS Code。先跟随 NXP SDK、板级示例和 eIQ 生态跑通，再决定是否迁移到更通用的工程体系。
瑞萨平台项目：优先 e² studio + FSP / SDK，并结合 e-AI 或 Reality AI Tools。瑞萨的 RA、RZ、RX 等平台有自己的工具链节奏，不建议完全套用 STM32 或 ESP32 的经验。
工业存量项目：如果已有 Keil 或 IAR 工程，不建议为了 AI 模块推倒重来。更合理的做法是把模型推理封装成模块，接入原有工程和调试链路。
跨平台验证项目：优先 VS Code + CMake / PlatformIO / 厂商 SDK。把固件、模型、数据脚本和测试日志放进同一套仓库，后续迁移和复现实验会轻松很多。
数据和模型快速闭环：可以使用 Edge Impulse 或厂商 AI Studio。它们适合处理数据采集、特征提取、模型训练、量化和部署代码生成，但最终仍要回到目标 IDE 做板端集成。
来源说明：相关信息来源于芯片原厂官网以及网络公开数据，若有侵权请联系删除，谢谢。
