STM32软件架构设计

1、架构设计的意义

（1）应用代码逻辑清晰、避免代码冗余、；
（2）代码通用，方便软件移植；
（3）最大限度做到无需大量修改即可复用；
（4）各功能独立，低耦合高内聚；
（5）利用架构及其规则进行开发，在开发时间、成本、生产率和产品质量方面具有极大的回报。

2、总体架构图

3、结构层说明

（1）应用层

应用层 为程序的总体运行框架，组织、整合、调用业务逻辑，完成产品整体功能；提供两种方案，如下：
a）使用 实时操作系统 ( FreeRTOS、μClinux、μC/OS-II) 实现多种任务，如 按键任务、显示任务、通信任务、心跳任务、定时任务 等；
b）由 消息队列搭建而成的多任务调度 方法，适合轻便型、内存小的芯片；准备中……

（2）业务逻辑层

业务逻辑层 通过调用应用接口层API接口实现产品的各个业务功能，如：
a）按键事件业务；
b）用户GUI业务；
c）通信收发业务；
d）线程守护业务；（看门狗）
e）系统自检业务；
……

（3）功能模块层

功能模块层 封装实现具体功能的子模块，如 :
a）储存读写 模组；
b）按键触发 模组；
c）系统心跳 模组；
d）显示操作 模组;
e）串口收发 模组；
f ）数据采集 模组；
……

（4）硬件抽象层

硬件抽象层 包含了两部分：
a）STM32片内外设驱动（ GPIO、RCC、ADC、SPI、I2C、USART、etc ）；
b）外设底层驱动 （ Screen font library、Sensor I2C / SPI read and write ）;

4、遵循规则

（1）命名

a）文件名添加前缀：硬件抽象层( hal_ )、功能模块层( fml_ )、应用接口层( api_ )、业务逻辑层( bll_ )、应用层( app_ );
b）api接口命名规则：api_功能名称，例：lis3dh传感器初始化接口命名 api_lis3dh_init()；

（2）调用

a）同一级别的层相互独立，互不影响、互不干扰、互不关联，不能相互调用，只能调用下层接口；
b）各个层之间不能跨层调用，如：在业务逻辑层不能直接调用功能模块层的代码 ，仅能调用应用接口层代码；

（3）增删

a）新增接口要求与整体规则统一，后续只能增加，不允许修改、不允许删除；
b）每次新增接口，需在文件头备注 （作者、版本信息、状态功能） ；

5、优劣评估

（1）优势

a）底层驱动变动、更换平台，只需更改底层驱动，其他的层次结构不受影响、干扰，无需重新修改；
b）功能模块变动，只需单独升级功能模块，其他模块不受影响，应用层也不受影响；
c）架构设计完成后主要的工作区在业务逻辑层，应用层的作为整体架构的调度者、领导者，通过调用业务逻辑完成产品功能。

（2）劣势

a）架构设计一般比较复杂，设计和实现一个好的架构需要相当的时间。所以，一般只有在架构可以被多次反复应用的时候，前期投入的时间成本会得到丰厚的回报；
b）架构设计规定了一系列的接口和规则，这虽然简化了二次开发工作，但同时也要求二次开发者必须记住很多规则，如果违反了这些规则，就不能工作。但是由于架构屏蔽了大量的领域细节，相对而言，其学习成本还是大大降低了；
c）架构的升级对已有产品可能会造成严重的影响，导致需要完整的回归测试。

6、实例

（1）说明

本例以stm32f030k6t6为主控的小玩具为介绍，内部资源及外部设备 如下：
a）MCU内部资源： 32k flash、4k ram、DMA、ADC、TIM、I2C、SPI、USART……
b）软件运行框架： 由于内存较小，所以采用 消息队列搭建而成的多任务调度 ；
c）外部设备：LED x 4、KEY x 2、DS1302、LIS3DH、OLED、锂电池充电管理、预留ESP32模块接口；

（2）项目文件结构

a）树形结构图：

b）文件说明：
kernel： 主架构目录，存放5个层，每个层带 src、inc；
obj： 工程编译输出文件，存放编译过程文件以及hex文件；
project： 工程项目编译及编辑文件，编译器 keil 工程文件、编辑器 source insight 4 工程文件；
readme: 说明文件，软件变更、软件版本、项目状态说明

（3）Keil 工程结构

7、总结

（1）初次写博客，总结 前人思想 + 个人见解，不足之处，欢迎指出，Thank you ！！！
（2）文中的 消息队列搭建而成的多任务调度 后续以一篇独立博文说明，此处不做详细说明；
（3）没有最好的程序架构，只有只有最适合的！