|
软件架构这东西，众说纷纭，各有观点。在我看来，软件架构是软件系统的基本结构，包含其组件、组件之间的关系、组件设计与演进的规则，以及体现这些规则的基础设施。软件架构，从来不是一件容易事，它贯穿在产品的整个生命周期，需要所有团队成员遵守并自律，才能将架构思想在软件中体现。新手工程师，由于经历的项目太少，看不到项目全貌，很难从全局理解软件架构。但软件架构真的只是资深工程师的专利吗？这个也不见得。古人作文，讲究立意为先。今天工程师做项目和产品，也应该先立意。这个意，就是指要有高度。工程师入门能从软件架构的高度出发，看待软件问题，相信对软件的理解，会更加深刻一些。因此，我总结了软件架构的六个步骤，供嵌入式工程师参考。 上次谈到了嵌入式软件架构的第一个步骤，抽象层。建立抽象层（HAL或者DAL）的目的，是为了隔离硬件，让代码与硬件无关。即使整个项目的代码，由某工程师一个人完成，抽象层仍是是有必要的。但这次我们要聊的是，统一的基础设施，这是针对多人合作一个项目，或者多个项目共享同一个系统架构的情况。如果说，你手头的项目，没有与他人合作，也不会有后续的相关项目，软件基础设施这一步，可以直接跳过。 基础设施，分为硬件基础设施和软件基础设施。硬件基础设施，包含常用器件库、封装库、原理图库和硬件参考设计等等；而今天我们讨论的重点，主要在于软件基础设施。软件基础设施包含以下内容：
在一些小公司粗放的开发模式中，并不规定工程师所依赖的软件平台、硬件平台和工具，而是由工程师自己决定。很多工程师，也喜欢这种自由奔放的开发模式，认为只有在这种环境中，才能发挥自身创造力。这种认知是有偏差的，这个我们后续找机会详细讨论。随着小公司研发能力的提升，对软件基础设施进行约束和规定，几乎是注定的事情。因为软件区别于其他技术的本质，是在于其复用性。复用程度越高的软件，质量越高，对开发效率和开发质量的提升，就越大。无论从公司的降本增效还是科学管理的角度，都有着强大的动机，去统一软件基础设施。当软件的基础设施统一之后，会产生如下优点：
因此，是否统一，根本不是一个有争议的问题；如何统一，才是今天我们的重点。 一、基础类型与宏定义统一的软件基础设施的前提，就是声明统一的基础数据类型和宏，以克服不同的硬件平台和编译器的差异性。比如下面是我从自己的开源项目EventOS中摘录出来的代码，不见得很完整，只能代表在我在项目里需求。 #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)编译器相关的宏定义。使用宏，屏蔽掉编译器的差异，会 一些常用的数据结构。这些数据结构，与硬件和编译器无关，是在代码中频繁使用，并在多个模块间共享的数据结构，有必要将其提升至基础设施的层面进行支持，以避免各个模块，对同一个数据类型，进行不同的定义带来的数据转换问题。这些数据结构，与产品紧密相关，不同的产品类型之间，各自是不同的。比如下面的定义。 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;二、操作系统有些芯片的资源太小，是不能运行操作系统的。这些芯片，一般而言，也没有办法建立严谨的嵌入式软件架构，我们会在后续《小资源芯片的软件开发平台》中，单独进行讨论。这里只讨论芯片的。 不同的芯片，所能跑的操作系统是不同的。但如果要建立软件基础设施，应该尽量选取同一个操作系统。在现存的操作系统中，FreeRTOS和国产RT-Thread对各种不同的硬件架构的芯片，支持比较广泛，可以作为RTOS的首选。而当产品线异常丰富时，特别是使用了某些小众芯片，或者使用芯片商提供的操作系统时，就没有办法建立统一的软件基础设施。这时，有两个办法解决这一问题：
三、中间件中间件有很多类型，文件系统、各种协议栈、数据库、日志模块、Shell模块，都属于中间件的范畴。但在大部分情况下，这些也都属于软件基础设施的范畴。因为我们一旦选择某个中间件，一般来说，是没有必要更换的，正是由于这种稳定性，中间件也可以纳入软件基础设施的范畴。以下是我经常使用的开源中间件：
开源中间件，只占据了一小部分。实际产品中，中间件的大部分，都是产品或者项目私有的代码。我日常所使用的主要有：
中间件，占据了软件基础设施的大部分内容。在产品开发中，之所以软件复用性能够做到越来越高，中间件的积累，是一个很重要的原因。 四、框架与机制在不同的产品上，开发嵌入式软件，除了RTOS之外，很多产品还需要一些框架的支持。常见的框架包括：
这些框架的使用，与产品的特性相关，由产品和需求所决定。比如家庭服务机器人中，需要应用状态机框架和行为树框架，来应对复杂的应用层逻辑。而某些应用层逻辑比较简单的产品，就不需要使用状态机和行为树。 软件基础设施与硬件的关系嵌入式软件有一个区别于其他软件领域的重要特性，那就是直接依赖于硬件。软件基础设施，有很多也是需要硬件去体现和承载。比如文件系统，在规定某个源代码比如FatFS作为其文件系统解决方案的同时，所伴随的硬件驱动程序和硬件推荐设计，也往往被固化，以便在下一个项目中进行复用，并节约时间。 对于一些重要的且复杂的软件基础设施，如文件系统、网络等，由于调试和测试都比较耗时，一般推荐固化硬件设计的方式。硬件工程师，应优先对这些重要且复杂的软件基础设置，分配硬件资源，而硬件的其他工程，比如IO、ADC等，再行分配。 结论嵌入式软件基础设施，非常重要，根据项目与产品的不同，他所包含的内容也不尽相同。一般在项目启动时，就会初步选定一些软件基础设施的内容，比如RTOS、协议栈、文件系统等等。 需要指出的是，软件基础设施，也不是不变的，而是随着产品开发发展，不断会有新的组件和元素，加入到软件基础设施中去，也有可能会剥离掉旧的组件，就像生物的新陈代谢。只是，软件基础设施的新陈代谢，要温和，要相对稳定，添加和删除，都要执行谨慎原则。 |
|
|
