在Vscode中使用Cmake C/C++混合编程开发STM32

在Vscode中使用Cmake C/C++混合编程开发STM32

• 背景

  在之前的一个项目总结中：嵌入式日志系统设计，曾提到使用C语言面向对象的方式来开发STM32，最后也提出了在开发体验上并不友好，虽然最后的功能也全都实现了，但是C语言毕竟不是为面向对象设计的语言，在这一层上有着先天的劣势，想着以后是否可以使用C++来开发这样类似的项目，或者采用C/C++混合编程，这让我想起了几个月前曾搞过两个这样的试验，使用Make体系来完成的，后面也迁移到了Cmake体系，可惜时间拉的比较长了，找不到当初所参考的文章的。近来又把当时搞的Cmake编译STM32的工程翻了出来，尝试用C/C++混合编程来开发STM32，并且成功在板子上跑起来。

1. 使用C/C++混合编程

从汇编层面来看，C和C++的没有什么不同，最后都是编译称为arm的机器指令，但是C语言和C++却有非常大的不同，C++有众多大量的特性可以使用，并且对面向对象的支持也非常友好，有STL标准模板库，有着强大的泛型编程，并且还有像智能指针这样非常好用的工具，从开发角度来讲，C++有更强大的能力，虽然在速度上而言有些许的损失，但是在代码开发上，在架构设计上，以及在移植上，都更有优势，当然在移植系统上，也需要支持C/C++混合编程。

在我使用混合编程中发现一个问题，就是C++的部分库使得编译后的bin包非常大，这个库就是<iostream>，本来只有不到10K的bin包增加到了一百多K，这在部分嵌入开发平台上是不能忍受的，所以就做了一个试验，看看C和C++的几个常用库会给编译后的bin增加多大，其数据如下。

在测试过程中编译优化等级为Og，开启gdb调试选项，链接选项添加-specs=nano.specs -specs=nosys.specs，编译选项添加-ffunction-sections -fdata-sections -fno-exceptions，测试平台为stm32f103c6t6，不含fpu和dsp，编译工具为arm-none-eabi-gcc 10.3.1，表格中开启异常会关掉编译选项-fno-exceptions。

可以看出只有引入iostream头文件时，使得编译后的bin文件增加到一个很离谱的大小，其他头文件增加的大小都还在接受范围之内，可以预料到的是使用STL对bin包大小并没有太大的影响，因为STL模板库是以纯头文件的形式存在，并不会引入太多要编译的内容，而iostrem大概是由于stdin，stdout，stderr的问题，需要对输入和输出设备处理，使得编译的bin达到了160K，同时也可以看出stdio.h，也会增加不少文件大小，大概在3K左右，使用cstdio和stdio.h相差不大，在开启异常机制后增加了4K左右，不过在测试过程中发现，虽然开启了异常，但是catch语句无法捕捉异常，很遗憾无法在stm32上使用C++的异常机制，这也可能和链接编译选项的设置有关。

2. 总结

不管怎样瑕不掩瑜，不能使用iostream，可以使用C语言的stdio，不能使用异常机制，但是又大量的stl标准模板库的类型可以使用，可以使用C++的类来设计架构。所以在硬件快速发展的今天，使用更方便的开发语言和开发工具，可以加快我们对嵌入式软件的开发和部署。相信在使用C/C++混合编程后，项目团队的能力也可以进一步释放，虽然这对开发人员的要求也进一步提升，从简洁的C语言中，到特性繁多复杂的C++，从面向过程的开发理念到面向对象的开发架构设计，一切也都是挑战。又有时在感叹，其他平台的软件开发思想，一直向前推进，在嵌入式领域，居然还有这么多的软件开发人员，使用基础编程思想，维护复杂庞大的底层驱动软件，结果导致软件开发变成固件开发，换个平台，软件就要重新编写，希望在不久的未来，这一切可以发生改变。

目前我的编译系统也从make迁移到了cmake体系，也是为了更方便地扩展各种插件平台，这套项目代码和cmake编译体系，同时也保留了make编译系统，可以在我的仓库master分支上找到：STM32F103: stm32 personal code repository (gitee.com)