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

1、写在前面

先来个图:

mcu 业务程序架构 mcu软件架构_应用程序

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

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

2、引子

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

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


mcu 业务程序架构 mcu软件架构_串口_02

图1 一般的硬件结构

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


mcu 业务程序架构 mcu软件架构_应用程序_03

图2 产品整体组成

 

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

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

3、分层抽象

第一步抽象分层:

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


mcu 业务程序架构 mcu软件架构_mcu 业务程序架构_04

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

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

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

第二步抽象分层

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

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


mcu 业务程序架构 mcu软件架构_应用程序

图4 三层结构

 

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

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

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

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

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