1. 从裸机到现代C为什么要在单片机上折腾C很多人第一次接触单片机编程都是从C语言开始的。51单片机、STM32、GD32、ESP32翻开任何一本教材或者教程清一色都是C语言。江科大的51单片机笔记、32单片机笔记讲的也都是C。这很正常C语言贴近硬件、编译产物小、运行时开销可控天然适合资源受限的嵌入式环境。但当你真正做过几个稍微复杂一点的项目之后你会发现一个很现实的问题代码越写越乱状态越管越多改一处崩三处。我最早做单片机项目的时候一个智能照明控制系统前前后后写了十几个状态机每个状态机用一堆全局变量和switch-case堆起来。刚开始还能hold住等到要加一个新功能——比如从触摸屏获取坐标然后映射到屏幕内容上——整个人就崩溃了。全局变量互相踩踏中断里改一个标志位主循环里读到的值跟预期完全对不上。那时候我就开始想能不能把C那套封装、继承、多态的思维搬到单片机上来。答案是肯定的而且比你想的要成熟得多。C在单片机上的应用不是简单地把PC端那套STL、异常、RTTI搬过来而是有选择地使用C的语言特性在保持零开销抽象的前提下提升代码的可维护性和可扩展性。这篇文章就是我在多个STM32、GD32、ESP32项目里实际使用C之后的经验总结从工具链配置到语言特性取舍从内存管理到中断处理全部是踩过坑之后沉淀下来的东西。如果你已经会C语言能点亮LED、能驱动LCD1602、能跑通串口但觉得代码组织越来越吃力那这篇文章就是写给你的。如果你还在纠结“51单片机哈佛结构是什么”“单片机C语言没有堆栈吗”这种基础问题建议先把C语言和单片机基础打牢再来看C的部分不然容易消化不良。2. 工具链选型与环境搭建别在第一步就翻车2.1 编译器怎么选ARMCC、GCC还是Clang单片机上用C第一个拦路虎就是编译器。不是所有嵌入式编译器都完整支持C更不是所有编译器都能把C的抽象开销优化到零。我试过的主流方案有这么几种编译器适用平台C支持程度典型使用场景ARMCC (Keil MDK)ARM Cortex-MC98/03部分C11传统STM32项目Keil生态ARM GCCARM Cortex-M/R/AC11/14/17完整支持STM32CubeIDE、PlatformIO、Makefile工程Clang/LLVMARM、ESP32、RISC-VC11/14/17/20ESP-IDF、Zephyr、现代嵌入式框架SDCC51单片机不支持C51单片机只能用CIAR EWARMARM Cortex-MC11/14商业项目IAR生态这里有一个很关键的结论51单片机基本上跟C无缘。SDCC不支持CKeil C51也不支持。所以如果你手上的项目是51单片机比如STC89C52、STC12系列那这篇文章的C部分你只能看看思路实际落地还是得用C。但如果你用的是STM32F103C8T6、GD32、ESP32这类32位单片机那C完全可用而且用起来很舒服。我个人的推荐是STM32/GD32项目用ARM GCCESP32项目用ESP-IDF自带的GCC工具链。原因很简单GCC对C标准的支持最完整而且是免费的配合VSCode或者CLion开发体验很好。Keil MDK虽然也能写C但它的C支持停留在比较老的版本而且工程配置里要手动开--cpp选项容易出各种奇怪的问题。2.2 VSCode配置C/C环境的正确姿势说到VSCode配置C/C环境这是搜索量极高的一个话题。很多人卡在c_cpp_properties.json、tasks.json、launch.json这三个文件上。我直接给你一套可用的配置模板针对STM32ARM GCC的场景。首先是c_cpp_properties.json这个文件告诉VSCode的IntelliSense去哪里找头文件{ configurations: [ { name: STM32, includePath: [ ${workspaceFolder}/**, ${workspaceFolder}/Drivers/CMSIS/Include, ${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32F1xx/Include, ${workspaceFolder}/Drivers/STM32F1xx_HAL_Driver/Inc ], defines: [ USE_HAL_DRIVER, STM32F103xB ], compilerPath: /usr/bin/arm-none-eabi-gcc, cStandard: c11, cppStandard: c17, intelliSenseMode: gcc-arm } ], version: 4 }然后是tasks.json用来触发编译{ version: 2.0.0, tasks: [ { label: build, type: shell, command: make, args: [-j4], group: { kind: build, isDefault: true }, problemMatcher: [$gcc] } ] }注意compilerPath一定要指向你实际安装的arm-none-eabi-gcc路径。Windows下可能是C:\\Program Files (x86)\\GNU Arm Embedded Toolchain\\...\\bin\\arm-none-eabi-gcc.exeLinux下通常是/usr/bin/arm-none-eabi-gcc。路径写错的话IntelliSense会疯狂报红但实际编译可能没问题别被吓到。还有一个坑如果你在Windows上装了Microsoft Visual C Redistributable那跟嵌入式开发没关系那是给PC端程序用的运行库。有人搜“visual c redistributable 安装包免费下载”以为单片机开发也需要其实完全不需要。单片机跑的是裸机或者RTOS没有Windows那套运行库的概念。2.3 启动文件与C运行时初始化C全局对象的构造函数需要在main()之前被调用这跟纯C程序不一样。C程序里.data段和.bss段的初始化由启动文件完成然后直接跳main。但C里如果你定义了一个全局对象比如class Led { public: Led() { /* 初始化GPIO */ } }; Led led; // 全局对象这个led的构造函数必须在main()之前执行。ARM GCC的启动文件startup_stm32f103xb.s里默认只调用了__libc_init_array这个函数会遍历.init_array段执行所有全局构造函数。但前提是你的链接脚本里正确放置了.init_array段。如果你用的是STM32CubeMX生成的Makefile工程链接脚本STM32F103C8Tx_FLASH.ld里通常已经有这段.init_array : { . ALIGN(4); __init_array_start .; KEEP (*(.init_array*)) __init_array_end .; . ALIGN(4); } FLASH如果没有你需要手动加上否则全局对象的构造函数不会被调用程序行为会非常诡异。我踩过一次坑一个全局的串口对象构造函数里配置了波特率结果实际跑起来波特率是乱的查了半天才发现是.init_array没被正确链接。3. C语言特性的取舍哪些能用哪些千万别碰3.1 可以放心用的特性在单片机上用C核心原则是零开销抽象。所谓零开销就是你用C写的代码编译出来的机器码跟手写C代码一样高效。以下这些特性在GCC下基本都能做到零开销可以放心用类与封装把相关的数据和操作打包在一起编译器优化后跟直接操作全局变量没区别。比如把GPIO操作封装成一个Gpio类编译出来还是那几条寄存器操作指令。命名空间纯粹是编译期的名字修饰运行时零开销。用namespace bsp { }把板级支持包的东西包起来避免命名冲突。模板只要不滥用模板实例化后的代码跟手写类型特定代码一样。比如templatetypename T T max(T a, T b)编译出来就是几条比较指令。内联函数inline关键字建议编译器内联省去函数调用开销。在头文件里定义小函数时特别有用。构造函数与析构函数只要不涉及虚函数和动态内存构造/析构就是普通函数调用可以被内联。运算符重载合理使用能让代码更直观比如给一个Register类重载|和写起来跟直接操作寄存器一样。constexpr编译期计算运行时零开销。用来定义常量、计算数组大小非常合适。我现在的项目里GPIO、UART、SPI、I2C这些外设全部用类封装中断服务函数里调用类的静态方法主循环里用对象方法。代码结构比纯C清晰太多了而且编译出来的固件大小跟纯C版本几乎一样。3.2 需要谨慎使用的特性有些C特性不是不能用而是要看场景用之前得想清楚代价虚函数与多态虚函数会引入虚表指针vptr和虚表vtable每个对象多一个指针的开销每次调用多一次间接寻址。在资源紧张的STM32F103C8T664KB Flash20KB RAM上如果对象数量不多这点开销可以接受。但如果你的对象成千上万或者对中断延迟极其敏感就要慎重。我的建议是在驱动层用静态多态模板/CRTP在应用层可以用少量虚函数。异常处理GCC的ARM工具链默认关闭异常支持因为异常会显著增大代码体积而且栈展开stack unwinding在裸机上行为不确定。强烈建议禁用异常编译时加-fno-exceptions。错误处理用返回值或者错误码。RTTI运行时类型识别同样会增大代码体积而且跟异常一样在裸机上意义不大。编译时加-fno-rtti禁用。动态内存分配new/delete在单片机上要极其小心。标准库的malloc/free在裸机上通常不可用或者需要你自己实现_sbrk。即使实现了频繁的动态分配会导致内存碎片跑几天几个月之后可能就分配失败了。建议禁用动态内存所有对象静态分配或者放在栈上。STL容器std::vector、std::string、std::map这些底层都涉及动态内存分配而且代码体积很大。在单片机上基本不要用。如果确实需要类似功能用固定大小的数组或者自己写轻量级容器。3.3 绝对不要碰的特性以下这些特性在单片机上用了就是给自己找麻烦iostreamstd::cout、std::cin这些代码体积巨大而且依赖操作系统的文件描述符。单片机上用printf重定向到串口就够了。线程与并发std::thread、std::mutex这些依赖操作系统的线程库裸机上没有。如果用了RTOS用RTOS自己的API。文件系统std::fstream依赖操作系统的文件系统单片机上要么没有要么用FatFS这类嵌入式文件系统跟STL没关系。异常与RTTI前面说过了禁用。我见过有人在STM32F103C8T6上跑std::vector编译出来Flash直接爆了然后到处问“单片机下载失败”是怎么回事。下载失败的原因很多但固件体积超过Flash容量绝对是其中之一。所以在单片机上用C一定要清楚每一行代码的代价。4. 实战用C重写一个触摸屏坐标映射模块4.1 需求分析从触摸屏坐标到屏幕内容假设你有一个STM32F103C8T6驱动的TFT屏幕带触摸功能。触摸屏控制器比如XPT2046返回的是原始的ADC值范围大概是0到4095。你需要把这些原始值转换成屏幕上的像素坐标然后根据坐标判断用户点了哪个按钮或者哪个区域。用纯C写大概是这样的uint16_t raw_x, raw_y; uint16_t screen_x, screen_y; void touch_task(void) { raw_x xpt2046_read(XPT2046_X); raw_y xpt2046_read(XPT2046_Y); screen_x (raw_x - CAL_X_MIN) * SCREEN_WIDTH / (CAL_X_MAX - CAL_X_MIN); screen_y (raw_y - CAL_Y_MIN) * SCREEN_HEIGHT / (CAL_Y_MAX - CAL_Y_MIN); if (screen_x 100 screen_x 200 screen_y 50 screen_y 100) { // 按钮被按下 } }这段代码能跑但问题很多校准参数是全局变量按钮判断逻辑跟触摸读取混在一起加一个新按钮就要改touch_task而且多个按钮的判断条件写在一起很容易出错。4.2 用C重构类与封装用C重构思路是这样的namespace bsp { class TouchScreen { public: struct Point { uint16_t x; uint16_t y; }; TouchScreen(uint16_t width, uint16_t height) : width_(width), height_(height), cal_x_min_(0), cal_x_max_(4095), cal_y_min_(0), cal_y_max_(4095) {} void setCalibration(uint16_t x_min, uint16_t x_max, uint16_t y_min, uint16_t y_max) { cal_x_min_ x_min; cal_x_max_ x_max; cal_y_min_ y_min; cal_y_max_ y_max; } Point read() { uint16_t raw_x xpt2046_read(XPT2046_X); uint16_t raw_y xpt2046_read(XPT2046_Y); Point p; p.x static_castuint16_t( (static_castuint32_t(raw_x - cal_x_min_) * width_) / (cal_x_max_ - cal_x_min_)); p.y static_castuint16_t( (static_castuint32_t(raw_y - cal_y_min_) * height_) / (cal_y_max_ - cal_y_min_)); return p; } private: uint16_t width_; uint16_t height_; uint16_t cal_x_min_, cal_x_max_; uint16_t cal_y_min_, cal_y_max_; }; } // namespace bsp然后按钮的判断可以再封装一层class Button { public: Button(uint16_t x, uint16_t y, uint16_t w, uint16_t h) : x_(x), y_(y), w_(w), h_(h), pressed_(false) {} bool update(const bsp::TouchScreen::Point p) { bool inside (p.x x_ p.x x_ w_ p.y y_ p.y y_ h_); bool clicked inside !pressed_; pressed_ inside; return clicked; } private: uint16_t x_, y_, w_, h_; bool pressed_; };这样主循环里就是bsp::TouchScreen touch(240, 320); Button btn1(100, 50, 80, 40); Button btn2(100, 120, 80, 40); void main_loop() { auto p touch.read(); if (btn1.update(p)) { // 按钮1被点击 } if (btn2.update(p)) { // 按钮2被点击 } }代码结构清晰多了加一个新按钮只需要定义一个Button对象不用改任何现有逻辑。而且TouchScreen和Button都是独立的类可以单独测试。4.3 关键细节整数溢出与类型转换上面这段代码里有一个很容易被忽略的坑整数溢出。raw_x - cal_x_min_的结果是uint16_t乘以width_也是uint16_t之后结果可能超过65535导致溢出。所以我用了static_castuint32_t先把raw_x - cal_x_min_转成32位再乘以width_这样就不会溢出。这个坑我在实际项目里踩过。当时触摸屏的x坐标总是跳变查了半天以为是硬件问题后来发现是整数溢出。(raw_x - cal_x_min_) * width_在raw_x - cal_x_min_比较大的时候乘积超过65535结果被截断坐标就乱了。所以在单片机上做数学运算一定要时刻关注数据类型和范围。另外cal_x_max_ - cal_x_min_如果等于0会导致除零。虽然实际校准后不会出现这种情况但保险起见可以在setCalibration里加一个断言或者默认值处理。4.4 中断处理C里怎么写中断服务函数中断服务函数ISR在C里需要用extern C修饰因为中断向量表是C链接的名字修饰规则必须跟C一致。比如extern C void EXTI0_IRQHandler(void) { if (EXTI-PR EXTI_PR_PR0) { EXTI-PR EXTI_PR_PR0; // 处理中断 Button::onInterrupt(); } }注意ISR里尽量不要调用虚函数也不要用可能抛出异常的代码。ISR应该尽可能短只做标志位设置或者数据入队具体处理放到主循环里。还有一个坑ISR里访问的变量要加volatile。比如volatile bool button_pressed false; extern C void EXTI0_IRQHandler(void) { button_pressed true; }如果不加volatile编译器可能优化掉主循环里对button_pressed的读取导致主循环永远看不到变化。这个问题在纯C里也存在但C的优化更激进更容易触发。5. 内存管理与性能优化让C跑得跟C一样快5.1 禁用动态内存的正确方法前面说了单片机上建议禁用动态内存。但怎么禁不是简单地不写new就行因为标准库内部可能还是会用到。正确的方法是在编译选项里加-fno-exceptions -fno-rtti然后重写operator new和operator delete让它们在链接时报错这样一旦有人用了动态内存编译阶段就能发现void* operator new(std::size_t) delete; void* operator new[](std::size_t) delete; void operator delete(void*) delete; void operator delete[](void*) delete;如果确实需要动态内存比如某个模块必须用那可以单独为那个类重载operator new从一个静态内存池里分配class MyClass { public: static void* operator new(std::size_t size) { return memory_pool.allocate(size); } static void operator delete(void* ptr) { memory_pool.deallocate(ptr); } };这样既满足了需求又避免了全局的动态内存碎片。5.2 栈空间估算与优化单片机的栈空间通常很小STM32F103C8T6默认的栈大小是1KB左右在启动文件里定义。C的函数调用层次如果太深或者局部变量太大很容易栈溢出。栈溢出的表现通常是HardFault或者程序跑飞。估算栈空间的方法看编译生成的.su文件GCC加-fstack-usage选项每个函数的栈使用量都会列出来。然后根据调用图算出最坏情况下的栈深度。如果超过默认栈大小要么增大栈要么减少函数嵌套要么把大局部变量改成静态的。我遇到过一次栈溢出一个递归函数处理触摸屏的滑动轨迹递归深度跟滑动点数相关滑动快了就栈溢出。后来改成迭代问题解决。所以在单片机上尽量避免递归尤其是深度不确定的递归。5.3 编译优化选项与实测对比GCC的优化选项对C代码的影响很大。我实测过同一段C代码在不同优化级别下的表现优化级别Flash占用RAM占用执行时间相对-O0100%100%100%-O175%95%60%-O270%90%50%-Os65%90%55%-O372%92%48%对于单片机项目我通常用-Os优化体积因为Flash通常比速度更紧张。如果某个函数对速度要求极高可以单独用__attribute__((optimize(O3)))给它开小灶。还有一个选项是-flto链接时优化可以让跨文件的函数内联进一步减小体积。但LTO会显著增加编译时间而且有时候会引入奇怪的bug建议在项目后期再开。6. 常见问题与排查技巧实录6.1 C程序在单片机上跑飞了怎么办这是最常见的问题。C程序跑飞原因通常有这么几类全局对象构造函数没被调用检查.init_array段是否正确链接。可以在main()开头打印一个全局对象的成员变量看看是不是默认值。栈溢出用-fstack-usage分析或者把栈大小临时调大看问题是否消失。中断里用了非可重入函数比如在ISR里调用了printf而主循环里也在调printf两者冲突导致跑飞。ISR里尽量只用简单的赋值和标志位操作。虚函数表被破坏如果对象被越界写入vptr可能被覆盖调用虚函数时跳到非法地址。检查数组越界和指针越界。未定义行为比如访问了未初始化的指针、数组越界、整数溢出。C的未定义行为比C更隐蔽因为编译器可能基于“不会发生未定义行为”的假设做优化。排查方法先用调试器ST-Link OpenOCD GDB看HardFault时的寄存器和栈回溯。如果栈回溯不可用可以在HardFault处理函数里打印关键寄存器的值然后对照反汇编定位。6.2 常见问题速查表问题现象可能原因排查方法解决方案程序下载失败固件超过Flash容量查看编译输出的Flash占用减小固件禁用不必要的库程序跑飞HardFault栈溢出、空指针、数组越界调试器看栈回溯增大栈、检查指针和数组全局对象行为异常构造函数未调用检查.init_array段修改链接脚本中断响应慢ISR里做了太多事测量ISR执行时间把处理逻辑移到主循环变量值不更新缺少volatile检查变量声明加volatile浮点运算结果错误未启用FPU或软件浮点检查编译选项启用硬件FPU或软件浮点库代码体积突然增大用了STL或iostream查看map文件移除STL用轻量级替代链接错误undefined reference缺少库或启动文件查看链接命令添加对应库或源文件6.3 独家避坑技巧不要在头文件里定义非inline的全局变量C里头文件被多个源文件包含时全局变量会导致重复定义。用extern声明在源文件里定义。或者用C17的inline变量。模板代码尽量放在头文件里模板的实例化需要看到完整定义放在源文件里会导致链接错误。慎用static局部变量C的static局部变量初始化是线程安全的C11之后但在单片机上这个线程安全保证可能引入额外的锁开销。如果不需要线程安全用全局变量或者类的静态成员。constexpr比const更好constexpr保证编译期计算const只是运行期不可变。能用constexpr就用constexpr。用enum class代替enumenum class有作用域不会隐式转换成整数避免命名冲突和类型错误。用nullptr代替NULLnullptr有类型不会跟整数混淆重载解析更准确。7. 从C到C的迁移策略渐进式改造7.1 不要一次性重写如果你有一个已经跑通的C项目想迁移到C千万不要一次性全部重写。我试过风险太大而且很容易引入新bug。正确的做法是渐进式改造第一步把编译选项改成C但代码还是C风格。GCC下把.c文件改成.cpp或者用-x c强制按C编译。这一步主要是让编译器用C的规则检查代码会发现一些潜在问题比如隐式类型转换、void*转换等。第二步把相关的全局变量和函数封装成类。比如把LCD1602的驱动封装成一个Lcd1602类把串口封装成一个Uart类。这一步不需要改调用逻辑只是把散落的全局变量和函数收拢到一起。第三步用命名空间组织代码。把板级支持包放在namespace bsp里把应用层放在namespace app里避免命名冲突。第四步引入模板和静态多态。比如把不同型号的屏幕驱动抽象成一个模板类用模板参数区分。第五步如果确实需要运行时多态再引入虚函数。但这一步要谨慎评估开销。7.2 混合编译C和C共存实际项目里经常是C和C混合编译。C代码调用C函数或者C代码调用C函数。这时候要注意extern C// C头文件供C代码调用 #ifdef __cplusplus extern C { #endif void cpp_function(int arg); #ifdef __cplusplus } #endifC调用C函数只需要在C代码里声明C函数的原型并加extern Cextern C void c_function(int arg);注意extern C只影响链接时的名字修饰不影响函数内部的实现。C函数内部还是可以用C特性。7.3 实测案例从C迁移到C的固件大小对比我拿一个实际项目做了对比。项目功能STM32F103C8T6驱动TFT屏幕触摸屏坐标映射三个按钮串口输出调试信息。版本Flash占用RAM占用代码行数可维护性纯C28KB6KB1200行一般全局变量多C封装29KB6.5KB1100行好类结构清晰C模板29.5KB6.5KB1050行很好复用性强可以看到C版本的Flash和RAM占用只比纯C多了不到5%但代码结构清晰了很多。对于STM32F103C8T6的64KB Flash和20KB RAM来说这点开销完全可以接受。8. 中断、RTOS与C的配合8.1 中断服务函数的C写法前面提过ISR要用extern C。但还有一个细节ISR里调用的C函数最好也是extern C或者static的避免链接问题。如果ISR里要调用类的成员函数用静态成员函数class Uart { public: static void isrHandler() { // 处理中断 } }; extern C void USART1_IRQHandler(void) { Uart::isrHandler(); }静态成员函数没有this指针调用开销跟普通函数一样。8.2 在FreeRTOS任务里用CFreeRTOS的任务函数是C链接的所以任务入口也要用extern Cextern C void vTaskLed(void* pvParameters) { Led* led static_castLed*(pvParameters); while (1) { led-toggle(); vTaskDelay(pdMS_TO_TICKS(500)); } }创建任务时把对象指针传进去Led led1(GPIOA, GPIO_PIN_5); xTaskCreate(vTaskLed, LED, 128, led1, 1, nullptr);这样每个任务可以操作自己的对象互不干扰。注意任务栈大小要估算好C的函数调用层次可能比C深栈要给够。8.3 互斥与临界区FreeRTOS里用互斥量保护共享资源。C的RAII机制可以自动管理互斥量的获取和释放class MutexGuard { public: MutexGuard(SemaphoreHandle_t mutex) : mutex_(mutex) { xSemaphoreTake(mutex_, portMAX_DELAY); } ~MutexGuard() { xSemaphoreGive(mutex_); } private: SemaphoreHandle_t mutex_; }; // 使用 { MutexGuard guard(uart_mutex); uart.send(hello); } // 离开作用域自动释放这样即使中间return或者抛异常虽然我们禁用了异常互斥量也能正确释放。这是C相比C的一个明显优势。9. 工具与生态那些能帮你省时间的工具9.1 静态分析工具C代码比C更容易写出隐蔽的bug所以静态分析很重要。我常用的有cppcheck免费能检查数组越界、空指针、未初始化变量等。集成到Makefile里每次编译自动跑。clang-tidy功能更强能检查C特有的问题比如虚函数析构、移动语义误用等。需要compile_commands.json。Coverity商业工具免费版对开源项目可用检查更深入。9.2 单元测试单片机代码也能做单元测试。把跟硬件无关的逻辑抽出来在PC上编译测试。比如触摸屏坐标映射的算法可以单独测试TEST(TouchScreenTest, CoordinateMapping) { TouchScreen touch(240, 320); touch.setCalibration(100, 4000, 100, 4000); // 模拟原始值 // 验证映射结果 }用Google Test或者Catch2在PC上跑不需要硬件。这样能快速验证逻辑正确性减少在硬件上调试的时间。9.3 版本控制与代码审查C代码的改动影响面可能比C大所以版本控制和代码审查更重要。Git是标配每次提交前跑一遍静态分析和单元测试。代码审查重点关注内存管理、中断安全、类型转换。10. 我个人的经验体会折腾了这么多项目我对C在单片机上的应用最大的体会是C不是银弹但它是一把好用的工具关键看你怎么用。用得好代码结构清晰维护成本低用不好固件膨胀bug更难查。我的建议是先从小的模块开始尝试比如把一个LED驱动、一个串口驱动用C重写感受一下编译产物的大小和性能。确认没问题之后再逐步扩大范围。不要一上来就把整个项目重写那样风险太大。还有一点不要为了用C而用C。如果项目很简单纯C就够了没必要引入C的复杂度。C的价值在项目规模变大、状态变多、复用需求变强的时候才体现出来。51单片机这种资源极其受限的平台老老实实用C就好。STM32、GD32、ESP32这些32位平台C完全值得一试。最后分享一个小技巧如果你在VSCode里写C装一个C/C插件和CMake Tools插件配合compile_commands.json代码补全和跳转体验会好很多。compile_commands.json可以用bear工具生成或者用CMake的-DCMAKE_EXPORT_COMPILE_COMMANDSON选项。这样IntelliSense就能准确理解你的工程结构不会到处报红。