基于mcu的一种分层软件架构

基于mcu的一种分层软件架构（一）

1、写在前面

先来个图：

经过了一段时间的琢磨与思考。借鉴操作系统的分层原理，也搞出来了一种mcu的层状软件结构。好了，不说虚的啦。所有的一些方法和思想，都是对经历痛点的思考后，在人类智力范围内，被捣鼓出来，用来解决或是减弱痛点的。否则就是形而上了，没有意义。

 说说把它弄出来的初衷吧。大前提，所有的电子产品在初期研发、迭代升级阶段，都会有软件或是硬件的修改(当然，本文仅限于带mcu产品哈)。修改软件，可能是为了提高功能、定制功能等等；修改硬件，可能是为了优化成本、提高硬件稳定性，有时甚至会修改mcu。如果没有一个合适的软件结构，那我们一定会各种改改改了；更有甚者，硬件改变后，软件要推翻重做，哈哈，那个苦呀。基于上述痛苦，作为接受过九年义务教育我们，当然要与之斗争呀。

2、引子

下面说说带有mcu的产品基本构成吧（忽略结构和外观）。

 1、对于一个带有mcu的产品其硬件结构一般就是一个电路板，上面集成有mcu最小系统、led灯、lcd、继电器、WiFi模块、485串口、232串口、h桥、电源等各种东东。mcu呢是一个可编程的东西，它通过自身的io、并口、串口等各种接口与板子的其他设备产生联系。我们可以通过对mcu编程，间接控制板子上的各种设备。因为mcu的特殊性，我们可将硬件分为mcu和外围设两个部分。可以画个圈圈图，如图1所示。大圈圈代表整个板子，小圈圈代表mcu，大圈圈减小圈圈是板子上出mcu的外围设备。

图1 一般的硬件结构

 2、对于软件，我们通过mcu这个“中介”，根据一些功能逻辑进行编码，有序的控制各种设备。这样有序运动的硬件满足我们生活中的各种需求，形成形形色色的电子产品。如果没有细分软件结构。如图2所示，就是右边的代码就是我们所说的软件，自己构成的一大坨（具体是啥样呢，可能是一个带有合理架构的有序整体；也可能是混乱的夹杂各种全局变量寄存器操作；也可能里就一个.c文件一个main函数构成撑起了整个业务逻辑；当然还有，自己脑补吧）。

图2 产品整体组成

在这里，我们可以看到我们前面所说的痛点。如果图2中右边的“代码”，在软件里mcu或是板子的具体寄存器操作与具体应用混合在一起。一旦左边的“大圈圈”里的某个东东改变了，那就有可能全局搜索“代码”部分，修改各个部分的具体操作。如果没有合理的架构，回望过去尽是汗水加泪水呀！！！

我们的痛点可以描述为这样，即：硬件发生了，会带来软件的大量修改。

3、分层抽象

第一步抽象分层：

为了解决上述问题，可以对硬件加以抽象，在具体应用和硬件之间加入一个中间层，该中间层的任务是将具体的硬件操作加以封装，一旦硬件修改，仅仅修改中间层就可以了。那么软件就可以构成了一个简单的层状结构了，如图3所示。中间层在这里我们叫做“产品的硬件抽象”，具体应用是“应用程序”。

图3 带有中间层的软件架构

采用该结构的后果：硬件修改后，我们可以不必去修改具体的应用程序，只需将对应的“硬件抽象”的实现修改就好了。这样我们的程序是不是更加灵活了。

当然，使用该操作也是有一定约定的；即应用程序，不允许调用处“产品硬件接口抽象”之外的任何板子上的操作，否则，该结果就会被打乱，脱离的初衷。

第二步抽象分层

我们知道，板子的硬件构成是带有一个小圈圈的大圈圈。mcu（小圈圈）本身往往有很多外设接口（串口、并口，gipo，ad）用于与板的其他设备进行交互。这些“外设接口”代码量也往往比价大，且很多要操作寄存器，如果和mcu外围设备的编码夹杂在一起，一旦硬件修改，从mcu到具体外设都是需要大量修改的；更糟糕的如果mcu修改啦，整个硬件部分的代码都是需要修改的。就此，可进一步抽象分层。如图4所示。将硬件部分，如图实际硬件那样分为两层，这样就构成了三层结构。

采用该结构的后果：硬件修改后，我们可以不必去修改具体的应用程序，只需将对应的“硬件抽象”的实现修改就好了。这样我们的程序是不是更加灵活了；同样在mcu改变时，使得硬件相关代码部分修改达到最小化。更加灵活。

图4 三层结构

本文是为了介绍，这个分层架构方法，并不是介绍具体实施的。所以呀，可根据具体经验发挥各种编程技巧。这里介绍，该结构在实施是需要具体注意的概念，以免违反初衷。

1、该分层架构是由MCU接口抽象、产品的硬件抽象、和应用程序三个层次；

2、mcu接口抽象、定义mcu各个外设访问的接口属性和操作。切记是定义好的、标准化后的。可以自己标准化也可以根据主流架构进行标准化（比如st厂家的hal库、外设标准库）。

3、“产品的硬件抽象”大部分形式上是对板子上各个硬件属性和操作进行标准的定义。但是，切记该层是“硬件抽象”，即根据产品的具体性质，标准化的“抽象硬件”，可能会存在一个“抽象硬件”调用使用多个实际硬件才能实现，也有可能一个实际的硬件可以实现多个抽象硬件（这个抽象很重要，该层的核心，其模块定义直接关系到应用的可扩展性、效率）。

4、不允许跨层操作，如果必须的话，就在中间层提供接口进行传递。例如应用层要访问“mcu”自带的“看门狗”，那么就在“产品的硬件抽象”层添加“看门狗模块”，该模块调用mcu的“看门狗”。（当然这也是分层软件的弊端之一，前期的工作量会很大，不过分层的效益是随时间增加的，而这一弊端是一个初期的静态弊端，长期来看，利大于弊的）。