软件架构

软件架构–六组份解析：嵌入式架构建议书

这份笔记是今年学习的时候开的坑，认真学习前辈的知识，温故知新。

1
软件架构这东西，众说纷纭，各有观点。什么是软件架构，我们能在网上找到无数种定义。比如，我们可以这样定义：软件架构是软件系统的基本结构，体现在其组件、组件之间的关系、组件设计与演进的规则，以及体现这些规则的基础设施。怎么定义一般来说，基本上不重要，我们不是在写学术书籍，关心软件架构能解决什么问题才是更重要的。软件架构不是制定出来的，而是产品和业务需求所决定的，架构师所做的，只是忠于需求，并合理的表达了需求。软件架构也从来都不是一成不变的。在产品或者产品线的整个生命周期中，随着业务和需求的变化，软件架构不断发展和变化，以适应新的需要。软件架构，也不是一个简单的项目问题，而是产品或产品线的技术战略问题。一个良好设计并推广的软件架构，能带来如下好处。最大限度地减少不必要的返工使嵌入式软件在宏观层面建立规划增强复用性，降低开发成本便于团队内部的技术培训使技术积累更加容易。经常看到的一个常见问题是，新手工程师，由于经历与知识不足，往往看不到项目全貌，很难深刻理解软件架构，他们往往要经过多年的专业训练，才能逐渐建立架构意识。但软件架构真的只是资深工程师和架构师的专利吗？这个也不见得。古人作文，讲究立意为先。今天工程师做项目和产品，也应该先立意。这个意，就是指要有高度。工程师入门能从软件架构的高度出发，看待软件问题，相信对软件的理解，会更加深刻一些。因此，总结了软件架构的六个步骤，供嵌入式工程师参考。

抽象层

建立硬件/设备抽象层，使得应用层不再依赖硬件
这个很好理解，找个直观的例子来说就是换芯片。如果开发的产品直接依赖某个芯片厂商的固件库，特别是：在应用层代码直接调用了底层代码。这样产生了强依赖，在移植的时候是非常非常麻烦的。假设现在我们的供应商换成了其他的硬件厂商，那么直接更换就需要去应用层的代码里面找到以前调用的底层代码，并一一根据功能更换为新的硬件厂商提供的代码，这简直是在损耗公司软件工程师的生命啊！！！真的很麻烦。耦合的架构如果更换MCU会非常非常的困难，如果原来使用了DMA，但是新的芯片不支持DMA传输，好家伙，这改动就大了，工程慢，交期慢，拖到最后交不了，尾款拿不不到。

许多新手乃至老手嵌入式工程师，在未了解软件架构之前，把应用层功能和硬件相关的代码，不由自主的搅和在一起写。这种做法非常普遍。比如下面的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
void modbus_rtu_write_reply(uint8_t add, uint8_t func_code, uint16_t reg, uint16_t data)
{
    rs485.buff_tx[0] = add;
    rs485.buff_tx[1] = func_code;
    rs485.buff_tx[2] = (uint8_t)(reg >> 8);
    rs485.buff_tx[3] = (uint8_t)(reg);
    rs485.buff_tx[4] = (uint8_t)(data >> 8);
    rs485.buff_tx[5] = (uint8_t)(data);

    uint16_t crc16 = mb_crc16(rs485.buff_tx, 6);

    rs485.buff_tx[6] = (uint8_t)(crc16);
    rs485.buff_tx[7] = (uint8_t)(crc16 >> 8);

    rs485.tx_total = 8;
    rs485.tx_num = 0;

    /* Send data from the uart port. The hardware related program. */
    LL_USART_ClearFlag_TC(USART1);
    LL_USART_EnableIT_TC(USART1);
    USART1->DR = rs485.buff_tx[rs485.tx_num ++];
}

上面的这一段代码，不是一个好例子。从函数LL_USART_ClearFlag_TC开始的一句，也就意味着，这个Modbus的代码，和MCU提供出的固件库耦合在一起写了。此处的代码，显然违反了这一原则。Modbus作为高层模块，此处对MCU固件库的API进行了依赖。对于这种将硬件相关的代码与功能耦合在一起的软件架构，在本文中，我们姑且称之为“耦合架构”；而要追求的，是将隔离硬件相关的软件架构，称之为“隔离架构”。接下来，我们将详细对比，耦合架构和隔离架构各自的特征。

耦合架构的毛病：

  • 移植问题
  • 单元测试困难（给定输入测输出）
  • 不易扩展（例如我应用层一大堆代码，而且有相互联系的，一堆全局变量，扩展的时候就很容易一坨答辩山，出bug的几率大大增加）

最好的做法是：高层模块不依赖于底层模块，它们都依赖于抽象。例如对片上的外设进行抽象，例如串口、GPIO啊等等，高层的模块应该依赖于这些设备的抽象层。

隔离架构

  • 调用抽象层代码：应用层永远都调用抽象层，不能跨层调用

  • 符合依赖倒置的原则：应用层不依赖于固件库，而是依赖于抽象层；驱动模块也按照抽象层的对下接口进行实现

  • 便于移植：硬件相关的功能变得非常集中，被压缩在非常小的范围内，甚至可以完全不动应用层

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
________________________________________________________________________
|  应用层代码A                                                          | 
|  包含硬件抽象层的代码H                                                 | 
|_______________________________________________________________________
                                    |
________________________________________________________________________
|  硬件抽象层代码H                                                       |
————————————————————————————————————————————————————————————————————————
                                    |
________________________________________________________________________
| 驱动1、2、3.....                                                      |
————————————————————————————————————————————————————————————————————————
                                    |
________________________________________________________________________
|  芯片商固件库                                                          |
————————————————————————————————————————————————————————————————————————
                                    |
________________________________________________________________________
|  硬件                                                                 |
————————————————————————————————————————————————————————————————————————

抽象层的内容：

  • 对上接口：API：供应用层调用
  • 逻辑实现：抽象设备或者抽象硬件的内部实现，比如：增加缓冲区，保证线程的安全和其他逻辑
  • 对下接口：对驱动程序如何实现的约定

基础设施OS

建立统一的嵌入式软件基础设施
软件最具有价值的特性：可以复用。软件和其他的行业最大的不同就是它的复用成本很低，只要架构足够合理，它的价值就能越来越大。

基础设施包括哪些内容：

上次谈到了嵌入式软件架构的第一个步骤，抽象层。建立抽象层（HAL或者DAL）的目的，是为了隔离硬件，让代码与硬件无关。即使整个项目的代码，由某工程师一个人完成，抽象层仍是是有必要的。但这次我们要聊的是，统一的基础设施，这是针对多人合作一个项目，或者多个项目共享同一个系统架构的情况。如果说，你手头的项目，没有与他人合作，也不会有后续的相关项目，软件基础设施这一步，可以直接跳过。基础设施，分为硬件基础设施和软件基础设施。硬件基础设施，包含常用器件库、封装库、原理图库和硬件参考设计等等；而我们讨论的重点，主要在于软件基础设施。软件基础设施包含以下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
基础数据结构。
- 0基础类型与宏定义：克服不同的硬件平台和编译器的差异性。
- 1底层库。比如C标准库、加密库、校验库、工具库(数学、矩阵、容器)等等。
- 2操作系统/调度机制。包含操作系统或及调度相关服务，例如RTOS、freeRTOS。
- 3中间件。比如文件系统、协议栈、数据库等。
- 4框架与机制。消息通信机制、事件驱动机制、状态机框架、行为树框架、外设驱动框架(片上)、设备框架(传感器、电机等系统上的)。
- 5工具支持:测试、调试、仿真等软件工具的支持。

统一的编程工具链。
统一的代码风格和编程规范。
在一些小公司粗放的开发模式中，并不规定工程师所依赖的软件平台、硬件平台和工具，而是由工程师自己决定。很多工程师，也喜欢这种自由奔放的开发模式，认为只有在这种环境中，才能发挥自身创造力。这种认知是有偏差的，这个我们后续找机会详细讨论。随着小公司研发能力的提升，对软件基础设施进行约束和规定，几乎是注定的事情。因为软件区别于其他技术的本质，是在于其复用性。复用程度越高的软件，质量越高，对开发效率和开发质量的提升，就越大。无论从公司的降本增效还是科学管理的角度，都有着强大的动机，去统一软件基础设施。当一个实验室有完善的技术体系的时候，内部技术培养是很水到渠成的事情。


**当软件的基础设施统一之后，会产生如下优点：**
    软件质量提升，风格的高度一致性
    软件复用性，会提升至一个新的水平
    将可复用的功能，尽量抽象到基础设施层，减少软件冗余，提升开发效率
    为高层模块提供约束和纪律
    有利于团队的技术积累和技术传承
    有利于团队的技术培训
    是团队进行单元测试和测试驱动开发，以及跨平台开发的前提。
    因此，是否统一，根本不是一个有争议的问题；如何统一，才是重点。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
//   - 0基础类型与宏定义：
    
//统一的软件基础设施的前提，就是声明统一的基础数据类型和宏，以克服不同的硬件平台和编译器的差异性。例如：
#include <stdbool.h>

typedef unsigned int                    eos_u32_t;
typedef signed int                      eos_s32_t;
typedef unsigned short                  eos_u16_t;
typedef signed short                    eos_s16_t;
typedef unsigned char                   eos_u8_t;
typedef signed char                     eos_s8_t;
typedef bool                            eos_bool_t;

#define EOS_NULL                        ((void *)0)

#define EOS_U32_MAX                     (0xffffffffU)
#define EOS_U32_MIN                     (0U)
#define EOS_U16_MAX                     (0xffffU)
#define EOS_U16_MIN                     (0U)
#define EOS_U8_MAX                      (0xffU)
#define EOS_U8_MIN                      (0U)

编译器相关的宏定义。使用宏，屏蔽掉编译器的差异，会:

/* Compiler Related Definitions */       /* ARM Compiler */
#if defined(__ARMCC_VERSION)           

    #define eos_section(x)              __attribute__((section(x)))
    #define eos_used                    __attribute__((used))
    #define eos_align(n)                __attribute__((aligned(n)))
    #define eos_weak                    __attribute__((weak))
    #define eos_inline                  static __inline

#elif defined (__GNUC__)                /* GNU GCC Compiler */

    #define eos_section(x)              __attribute__((section(x)))
    #define eos_used                    __attribute__((used))
    #define eos_align(n)                __attribute__((aligned(n)))
    #define eos_weak                    __attribute__((weak))
    #define eos_inline                  static __inline

#elif defined (__IAR_SYSTEMS_ICC__)     /* for IAR Compiler */

    #define eos_section(x)              @ x
    #define eos_used                    __root
    #define eos_align(n)                PRAGMA(data_alignment=n)
    #define eos_weak                    __weak
    #define eos_inline                  static inline

#else
    #error "The current compiler is not supported. "
#endif

/*一些常用的数据结构。这些数据结构，与硬件和编译器无关，是在代码中频繁使用，并在多个模块间共享的数据结构，有必要将其提升至基础设施的层面进行支持，以避免各个模块，对同一个数据类型，进行不同的定义带来的数据转换问题。这些数据结构，与产品紧密相关，不同的产品类型之间，各自是不同的。比如下面的定义。*/

typedef struct eos_date
{
    eos_u32_t year               : 16;
    eos_u32_t month              : 8;
    eos_u32_t day                : 8;
} eos_date_t;

typedef struct eos_time
{
    eos_u32_t hour               : 8;
    eos_u32_t minute             : 8;
    eos_u32_t second             : 6;
    eos_u32_t ms                 : 10;
} eos_time_t;

typedef struct eos_imu_data
{
    float acc[3];
    float gyr[3];
    float mag[3];
} eos_imu_data_t;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
- 2 操作系统
有些芯片的资源太小，是不能运行操作系统的。这些芯片，一般而言，也没有办法建立严谨的嵌入式软件架构，我们会在后续《小资源芯片的软件开发平台》中，单独进行讨论。这里只讨论芯片的。不同的芯片，所能跑的操作系统是不同的。但如果要建立软件基础设施，应该尽量选取同一个操作系统。在现存的操作系统中，FreeRTOS和国产RT-Thread对各种不同的硬件架构的芯片，支持比较广泛，可以作为RTOS的首选。而当产品线异常丰富时，特别是使用了某些小众芯片，或者使用芯片商提供的操作系统时，就没有办法建立统一的软件基础设施。这时，有两个办法解决这一问题：
- 一 编写高层模块时，使用宏定义和条件编译，选择对应的RTOS API。这种一般用于所使用的操作系统较少的情况，比如说只有两三种。
static void *task_handler = NULL;
static void task_func_module_one(void *parameter);

void module_one_init(void)
{
    /* Newly creating a task to run the module. */
#if (EOS_RTOS_NAME == EOS_RTOS_NAME_FREERTOS)
    xTaskCreate(task_func_module_one,
                "TaskModule", 2048, NULL, 2,
                (TaskHandle_t *)&task_handler);
#elif (EOS_RTOS_NAME == EOS_RTOS_NAME_RTTHREAD)
    task_handler = rt_thread_create("led1", task_func_module_one, NULL,
                                    2048, 2, 20);
#else
    eos_assert(false);
#endif

    eos_assert(task_handler != NULL);
}

/* The task function of the module one. */
static void task_func_module_one(void *parameter)
{
    (void)parameter;

    /* Initialization. */

    while (1)
    {
        /* Add the task function. */
    }
}

-  二 建立操作系统抽象层（OSAL，Operating System Abstraction Layer），以屏蔽操作系统的差异，使高层模块依赖于OSAL。这种情况适合于资源丰富的情况。著名的POSIX标准，就是为了建立OSAL的，FreeRTOS和RT-Thread都在不同程度上对POSIX标准进行了支持；在嵌入式领域，CMSIS_OS也是为了建立操作系统的统一接口；但无论是POSIX和CMSIS_OS，被各RTOS支持的力度是不同，因此如果我们产品中需要建立严谨的嵌入式软件架构，还是要建立属于自己的OSAL，以便屏蔽掉操作系统的不同带来的差异。 
1
2
3
4
5
6
7
8
9
10
3 中间件
中间件有很多类型，文件系统、各种协议栈、数据库、日志模块、Shell模块，都属于中间件的范畴。但在大部分情况下，这些也都属于软件基础设施的范畴。因为我们一旦选择某个中间件，一般来说，是没有必要更换的，正是由于这种稳定性，中间件也可以纳入软件基础设施的范畴。以下是经常使用的开源中间件：
/*FatFS
LwIP
FlashDB
uC/Modbus
CAN Festival
letter-shell*/
开源中间件，只占据了一小部分。实际产品中，中间件的大部分，都是产品或者项目私有的代码。日常所使用的主要有： 日志模块 数据采集模块 通讯传输层协议 通讯应用层协议 文件传输协议 OTA功能 * 时间同步。
/*中间件，占据了软件基础设施的大部分内容。在产品开发中，之所以软件复用性能够做到越来越高，中间件的积累，是一个很重要的原因。*/
1
2
4 框架与机制
在不同的产品上，开发嵌入式软件，除了RTOS之外，很多产品还需要一些框架的支持。常见的框架包括： 外设与驱动框架 设备框架 消息框架 状态机框架 行为树框架 事件驱动框架.这些框架的使用，与产品的特性相关，由产品和需求所决定。比如家庭服务机器人中，需要应用状态机框架和行为树框架，来应对复杂的应用层逻辑。而某些应用层逻辑比较简单的产品，就不需要使用状态机和行为树。

软件基础设施与硬件的关系

嵌入式软件有一个区别于其他软件领域的重要特性，那就是直接依赖于硬件。软件基础设施，有很多也是需要硬件去体现和承载。比如文件系统，在规定某个源代码比如FatFS作为其文件系统解决方案的同时，所伴随的硬件驱动程序和硬件推荐设计，也往往被固化，以便在下一个项目中进行复用，并节约时间。对于一些重要的且复杂的软件基础设施，如文件系统、网络等，由于调试和测试都比较耗时，一般推荐固化硬件设计的方式。硬件工程师，应优先对这些重要且复杂的软件基础设置，分配硬件资源，而硬件的其他工程，比如IO、ADC等，再行分配。

结论

嵌入式软件基础设施，非常重要，根据项目与产品的不同，他所包含的内容也不尽相同。一般在项目启动时，就会初步选定一些软件基础设施的内容，比如RTOS、协议栈、文件系统等等。需要指出的是，软件基础设施，也不是不变的，而是随着产品开发发展，不断会有新的组件和元素，加入到软件基础设施中去，也有可能会剥离掉旧的组件，就像生物的新陈代谢。只是，软件基础设施的新陈代谢，要温和，要相对稳定，添加和删除，都要执行谨慎原则。

管理系统数据DATA

数据是系统的核心问题，要妥善识别和处理产品数据

功能分层与分解MOD

层次化、模块化、提升复用性，降低耦合，降低软件的复杂度

组件及接口设计COM

接口是模块之间的契约，组件是进行软件活动的最小单元

测试、调试与跨平台开发的支持Test

在架构层面提供自动测试、调试以及跨平台开发的支持，以提升效率

Teacher–Link
课程参考
固件、驱动、软件

LAST：

写在最后：一个合格的工程师，不局限于语言，不局限于方法，不局限于理论，而是解决问题，创造新的事物。每一个工程师都是改变世界的一份子，都是曾经最酷的少年少女，这一篇章的学习，方法论，都是最酷的，希望在工作和生活中学习和总结更多，也感谢前辈们的努力让我们能少走许多弯路。尊重这个世界上每一个推动社会前进的工程师和劳动者，世界因你们而更美好。

如果给程序员换个名称，我既不希望他们叫码农，也不希望他们叫35岁被优化，更不希望他们被叫做ICU后备战士，我愿意称每一个现代社会的缔造者为美丽的工程师。

大桥是桥梁工程师设计的，房子是土木工程师设计的，施工机械是机械工程师设计的，能源系统是电气工程师设计的，电路是硬件工程师配合设计的，操作系统、编译器是软件工程师设计的。算法、操作系统、硬件电路等等是现代社会的基石。搞算法的很优秀，但搞基础软件架构的并不比算法低一个档次，搞系统集成的也不比哪种工程师廉价，产品经理也不止是互联网大厂才有。薪资的高低并不决定工程师的高低，一切都是市场行为和经济在推动，脉脉上互喷互相比较的人也没有什么意义，只有明白自己真的喜欢什么，才能过得更好，那么多谦虚的技术大牛仍然做着他们所热爱的事，技术的劣都可以通过努力来补足。工程师要团结，我们都是光荣的劳动者，如果可以，我希望每一个领导者（政府、企业）都是技术出身，即使他们不是本领域，但只有真正成为过工程师、劳动者，参与到实际的劳动中去，才能体会每一个劳动者的伟大，才不会犯一些离谱的错误，各种组织才不会走歪。我们没有什么小资，没有什么中产，那都是意识形态产生的一些概念，持有价值度量物的多少并不代表人的高贵，愿每个工程师和劳动者都能过上幸福的生活。
--hypersonicty

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

继续努力<br>只做了一点微小的工作<br>谢谢大家<br>欢迎您给我发邮件沟通交流<br>ctysimple@qq.com<br>微信：CHENTY4869