关于单片机STM32裸机程序架构设计

本着授人以渔的原则，既提供我一直在用的程序架构，也讲程序架构的设计思路。

如果本文内容，你都能领悟并做到，不管项目多复杂，都将游刃有余。

我研发的那几年，接触大多数工程师，都没有程序架构的概念，基本一个while死循环干到底。

模块之间也没有封装好，导致代码写好以后，扩展性和维护性太差，类似的功能代码，也很难移植到新项目去复用。

早期我也是这样写的，反正实现功能就行了，代码好不好，功能上又看不出区别。

不过，等你接触到复杂的项目时，这招就行不通了，没设计好程序架构，根本做不稳定。

我意识到这个问题，是碰到两种需求的时候：

1.是做一个基于STM32的网关项目，项目做完以后，客户老是要改功能，客户不懂技术，在客户眼里，觉得改一个LED闪烁效果很简单，但对于程序架构没设计好的工程师来说，就是一个噩梦，比如每隔5秒快闪2次这种恶心的需求，搞不好很多代码都要重新组织。

我经常会被这种问题搞到头痛，特别是客户又催得急的时候，经常加班加到焦头烂耳，越急又越搞不出来。

2.我做过的很多项目，其实很多功能都有重复的，比如很多产品都有LED、都有按键、都有掉电参数存储、都有串口协议解析等等。

但是程序架构没写好，导致想移植代码，过来新项目复用时，不太好改，比如老项目才1个LED，新项目有6个LED，类似的还有按键等等。

后面为了有更多的时间摸鱼，我开始思考，怎么把程序写得，改起功能来很方便，代码复用性又很强那种，当时还不知道这个叫程序架构设计。

程序架构，我觉得是一个系统的学问，贯穿着整个项目，而不是具体某些细节。

就是各种功能模块，比如LED特效功能，按键检测功能，菜单功能，系统参数存储功能、语音功能、OTA升级功能等等。

这些功能模块的设计，我通常是采用硬件驱动代码和功能逻辑代码分离的方式，用大白话来说，就是一个功能模块，我可能会分2个.c文件来写，硬件驱动代码我以hal_xxx.c命名，功能逻辑代码我以mt_xxx.c命名。

硬件驱动代码主要是和单片机外设的配置代码，比如设置GPIO、Timer、串口、SPI这些，然后提供硬件接口给mt_xxx.c调用。

拿无际项目特训营的项目6来举例，这个项目可以实现远程控制，因为加了WiFi和4G模块。

如果你接触过类似项目，单片机和云平台之间，其实还有个串口通讯协议的，类似于下图这种。

按照我的思维，我会这样去设计程序：

单片机外设驱动的配置、串口发送数据、接收数据代码，我都放在hal_uart.c里。

串口协议数据发送和解析的代码，我会放在mt_protocol.c文件里。

这样就能实现硬件驱动代码和功能逻辑代码彻底分离。

那这样的好处是什么？

1.万一要换单片机了，如果通讯协议不变的情况下，mt_protocol.c文件代码可以不用改，只要改hal_uart.c硬件驱动程序，就能对接起来。

2.如果通讯协议格式变了，单片机不变，那只需要改mt_protocol.c文件代码就可以了。

3.调试方便，比如mt_protocol.c的功能，可以在PC上搭建一个开发环境先调试好，再对接硬件驱动接口，对于复杂的功能，这招还是很有用的，毕竟keil仿真调试没那么方便灵活。

这种设计，就是一种架构思维，解决了代码扩展性和移植性的问题。

如果每个功能模块都采用这种思维去设计，最终从整体看，你的程序架构就非常好了，就像组装汽车一样灵活了。

所以，要设计好程序架构，真的不是靠一个课程能搞定的，需要完整地做几个复杂的项目，并且有资深工程师的思路和代码，可以参考和借鉴，这样才能高效，系统地掌握。

每个功能模块都设计好以后，最后还需要有一个协调者。

类似于人的大脑，去协调手、脚、眼睛、耳朵、嘴巴。

这个大脑，一般就是程序的'地基'，类似于RTOS，就是'协调者'身份，负责调度协调整个项目的各个功能模块。

RTOS本质也是一种程序架构，但是我很少用，因为它的处境，其实很尴尬。

没那么复杂的项目，上RTOS并没有优势，反而为后期调试带来不必要的麻烦，如果对系统不熟悉，就像埋了一个定时炸弹，可能会跑一段时间后死机的现象。

复杂的项目，有些直接上Linux了，现在很多***，成本也能做得很低。

所以，现在rtos的应用，我觉得主要集中在中等复杂的项目，要求实时性很高，同时工程师，又不具备设计程序架构的能力时。

不过，至今为止，我基本是用自己设计的架构去替代RTOS，目前大多数产品都够用。

这个架构，我也录了套系统的教程，粉丝可以找我拿去参考学习。