本文仅个人观点看法 在开启本期的内容之前呢，我们先介绍两个编程概念，这两个概念想必大家也听说过： ** 面向过程编程 ** ， ** 面向对象编程
** 。前者旨在解决目的，将目的 ** 按步骤逐步逐步实现 ** 。后者旨在将事物对象化，把 对象作为基本结构单元
来设计，而我们只需要调用这些对象即可。 而C语言就是一种 ** 面向过程 ** 的编程语言，C++是一种 ** 面向对象 **
的编程语言，而我们常规的利用Keil也好，STM32CubeIDE亦或是Visual Studio
Code也好这些都是大体基于C语言而并没有广泛的引入C++，我们常用的 ** STM32的编程还是一种面向过程的编程 ** 。
无论是 寄存器、标准库、HAL库这些在 编程思维
上本质并没有多大区别，CubeMX等工具的推广，也只是起到了快速初始化或者移植一些框架的目的，但到了驱动编程那一步，既没有一个 ** 统一的规范 **
，各个模块文件的使用都不一定兼容，相信不少朋友也在使用过程中被不同的库所折磨过吧。
而反观一些可以通过面向对象编程的单片机/MPU例如常见的树莓派，ESP32，他们的使用和上手极为简单。
例如在ESP32中将串口作为一个对象，打开串口是一种方法，C++完美的 解决了同一个名称的函数不能有多种参数 的方法，这种重载的方式是实现 **
面向对象编程 ** 的必要条件。
但是这种方式如果仅仅是针对内部资源，这是远远不够的。
例如对于一个OLED屏幕，我们只需要在库中搜索相对应的库，就可以完美地调用相对应的库函数。
因此相比于在C语言的开发，C++的面向对象编程无疑是大幅度地 ** 降低开发难度，提高开发效率 **
也能为嵌入式开发降下一大门槛，在依赖于现成库的基础上脱离底层进行开发。
而为什么通常MPU中Linux开发有设备树的编程概念这一种面向对象编程，而通常STM32没有呢？大概率限制于MCU的性能往往远低于MPU，没办法在系统层面进行面向对象编程。
当然上述只是前言，现在开始我们本期的内容。
前几日我重新下载最新版的Visual Studio的时候，无意中看到安装选项中多了一项。
即使用 ** C++进行Linux和嵌入式开发 ** ，我想之前不知是未注意还是如何总之看到这个内容的第一个想法就是Visual Studio（注意这里是
Visual Studio 而不是 VSCode ）和STM32的结合。不过Visual Studio和STM32的结合使用早就出现，一是其
Visual Stduio Code 即 Visual Studio的轻量化版本就有挺多人使用来编译和烧录STM32，但是这是 ** 基于插件
** 的基础上，尤其是全网也未曾听闻有博客等不依靠插件来操作STM32（少数文章记录了利用Visual Studio结合插件烧录STM32）。
不过我在翻阅VS的更新手册的时候，在其对2022.17.6版本新增内容摘要中，在占据篇幅非常小地方，写到了。
没错， Visual Studio已经支持将STM32CubeIDE嵌入Visual Studio开发 ，而Visual
Studio则是完全支持面向过程编译的，并且Visual
Studio在程序员开发工具中广受欢迎，博主的C++最常使用的编译器，其本身也有非常好的社区环境以及非常广泛的使用量，这可以为STM32提供了一个非常好的开源环境。
VS的NuGet包管理也完美的支持快速将外设库导入到工程项目，这种 ** 熟悉且舒适 ** 的感觉。
而无独有偶，在这份更新报告前半个月，ST的官网有一篇关于 STM32全面支持Microsoft Visual Studio Code的新闻。
这不得不让人思考，在数年之前，ST便逐渐停止了标准库的更新，甚至较为新的一些芯片以及不支持标准库的开发了，从此开始大力地推行HAL库以及CubeMX的使用，这使得STM32有了专属于它的而非其他芯片所能比拟的生态优势。
而HAL抽象硬件的思想，也是面向对象开发的必要条件，如果一份代码需要根据不同的芯片来切换不同的底层库的话，那么他的面向对象过程开发也将会是困难重重。而HAL则保证了
不同芯片可以使用同一份运行源码 的条件。所以标准库到HAL库的迭代其实也是一种面向对象的升级，只不过方向不是在编程框架，而是把 ** 芯片作为了对象
** ， ** 从标准库的多对多， ** 到 了 HAL库的一对多 。
按照目前的所看趋势发展，无论是STM32CubeIDE的推广还是STM32与微软的合作，个人猜测今后的STM32开发有可能向着面向对象编程发展，主流的语言将会是用C++或者Python来替代C语言（还是C++优势大一些对于底层/内存空间的操作指针有着不可比拟的优势）。
同样的这种趋势也会 ** 大幅度的降低开发 ** ** 难度 **
甚至初学者可以像学习Python那样子通过调用各种库来使用STM32而不被如今抽象、复杂的底层所烦恼。同样的 ** 开发效率也会得到质一般的飞越 **
，而这种开发效率将会反哺其生态系统，一套围绕着STM32特有的生态系统，消费者同样的会在价格和开发效率中投入更多的思考。
当然如果随着开发难度的下降，也同样的会忽略逐渐底层，但是对于开发效率的大幅度提升来说，我认为这是可以接受，而如果像STM32等主流微控制器可以在一个优良且积极的开源环境中利用面向对象编程的话，微控制器领域又将迎来巨大的变革。