嵌入式软件架构基础设施设计方法

简介: 嵌入式软件架构基础设施设计方法

大家好,今天分享一篇嵌入式软件架构设计相关的文章。

软件架构这东西,众说纷纭,各有观点。在我看来,软件架构是软件系统的基本结构,包含其组件、组件之间的关系、组件设计与演进的规则,以及体现这些规则的基础设施。

软件架构,从来不是一件容易事,它贯穿在产品的整个生命周期,需要所有团队成员遵守并自律,才能将架构思想在软件中体现。新手工程师,由于经历的项目太少,看不到项目全貌,很难从全局理解软件架构。但软件架构真的只是资深工程师的专利吗?这个也不见得。

古人作文,讲究立意为先。今天工程师做项目和产品,也应该先立意。这个意,就是指要有高度。工程师入门能从软件架构的高度出发,看待软件问题,相信对软件的理解,会更加深刻一些。因此,我总结了软件架构的六个步骤,供嵌入式工程师参考。

上次谈到了嵌入式软件架构的第一个步骤,抽象层。建立抽象层(HAL或者DAL)的目的,是为了隔离硬件,让代码与硬件无关。即使整个项目的代码,由某工程师一个人完成,抽象层仍是是有必要的。

但这次我们要聊的是,统一的基础设施,这是针对多人合作一个项目,或者多个项目共享同一个系统架构的情况。

如果说,你手头的项目,没有与他人合作,也不会有后续的相关项目,软件基础设施这一步,可以直接跳过。

基础设施,分为硬件基础设施和软件基础设施。硬件基础设施,包含常用器件库、封装库、原理图库和硬件参考设计等等;而今天我们讨论的重点,主要在于软件基础设施。软件基础设施包含以下内容:

  • • 基础数据结构。
  • • 底层库。比如C标准库、加密库、校验库、工具库等等。
  • • 操作系统/调度机制。包含操作系统以及调度相关服务。
  • • 中间件。比如文件系统、协议栈、数据库等。
  • • 框架与机制。比如消息通信机制、事件驱动机制、状态机框架、行为树框架。
  • • 工具支持。
  • • 统一的编程工具链。
  • • 统一的代码风格和编程规范。

在一些小公司粗放的开发模式中,并不规定工程师所依赖的软件平台、硬件平台和工具,而是由工程师自己决定。很多工程师,也喜欢这种自由奔放的开发模式,认为只有在这种环境中,才能发挥自身创造力。这种认知是有偏差的,这个我们后续找机会详细讨论。

随着小公司研发能力的提升,对软件基础设施进行约束和规定,几乎是注定的事情。因为软件区别于其他技术的本质,是在于其复用性。

复用程度越高的软件,质量越高,对开发效率和开发质量的提升,就越大。无论从公司的降本增效还是科学管理的角度,都有着强大的动机,去统一软件基础设施。当软件的基础设施统一之后,会产生如下优点:

  • • 软件质量提升,风格的高度一致性
  • • 软件复用性,会提升至一个新的水平
  • • 将可复用的功能,尽量抽象到基础设施层,减少软件冗余,提升开发效率。
  • • 为高层模块提供约束和纪律
  • • 有利于团队的技术积累和技术传承
  • • 有利于团队的技术培训
  • • 是团队进行单元测试和测试驱动开发,以及跨平台开发的前提。

因此,是否统一,根本不是一个有争议的问题;如何统一,才是今天我们的重点。

一、基础类型与宏定义

统一的软件基础设施的前提,就是声明统一的基础数据类型和宏,以克服不同的硬件平台和编译器的差异性。

比如下面是我从开源项目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)

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

/* Compiler Related Definitions */
#if defined(__ARMCC_VERSION)           /* ARM 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 (__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;

二、操作系统

有些芯片的资源太小,是不能运行操作系统的。这些芯片,一般而言,也没有办法建立严谨的嵌入式软件架构,我们会在后续《小资源芯片的软件开发平台》中,单独进行讨论。这里只讨论芯片的。

不同的芯片,所能跑的操作系统是不同的。但如果要建立软件基础设施,应该尽量选取同一个操作系统。

在现存的操作系统中,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标准进行了支持;在 v嵌入式领域,CMSIS_OS也是为了建立操作系统的统一接口;但无论是POSIX和CMSIS_OS,被各RTOS支持的力度是不同,因此如果我们产品中需要建立严谨的嵌入式软件架构,还是要建立属于自己的OSAL,以便屏蔽掉操作系统的不同带来的差异。

三、中间件

中间件有很多类型,文件系统、各种协议栈、数据库、日志模块、Shell模块,都属于中间件的范畴。但在大部分情况下,这些也都属于软件基础设施的范畴。

因为我们一旦选择某个中间件,一般来说,是没有必要更换的,正是由于这种稳定性,中间件也可以纳入软件基础设施的范畴。以下是我经常使用的开源中间件:

  • • FatFS
  • • LwIP
  • • FlashDB
  • • uC/Modbus
  • • CAN Festival
  • • letter-shell

开源中间件,只占据了一小部分。实际产品中,中间件的大部分,都是产品或者项目私有的代码。我日常所使用的主要有: 日志模块 数据采集模块 通讯传输层协议 通讯应用层协议 文件传输协议 OTA功能 * 时间同步

中间件,占据了软件基础设施的大部分内容。在产品开发中,之所以软件复用性能够做到越来越高,中间件的积累,是一个很重要的原因。

四、框架与机制

在不同的产品上,开发嵌入式软件,除了RTOS之外,很多产品还需要一些框架的支持。常见的框架包括: 外设与驱动框架 设备框架 消息框架 状态机框架 行为树框架 事件驱动框架

这些框架的使用,与产品的特性相关,由产品和需求所决定。比如家庭服务机器人中,需要应用状态机框架和行为树框架,来应对复杂的应用层逻辑。而某些应用层逻辑比较简单的产品,就不需要使用状态机和行为树。

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

嵌入式软件有一个区别于其他软件领域的重要特性,那就是直接依赖于硬件。软件基础设施,有很多也是需要硬件去体现和承载。比如文件系统,在规定某个源代码比如FatFS作为其文件系统解决方案的同时,所伴随的硬件驱动程序和硬件推荐设计,也往往被固化,以便在下一个项目中进行复用,并节约时间。

对于一些重要的且复杂的软件基础设施,如文件系统、网络等,由于调试和测试都比较耗时,一般推荐固化硬件设计的方式。硬件工程师,应优先对这些重要且复杂的软件基础设置,分配硬件资源,而硬件的其他工程,比如IO、ADC等,再行分配。

结论

嵌入式软件基础设施,非常重要,根据项目与产品的不同,它所包含的内容也不尽相同。一般在项目启动时,就会初步选定一些软件基础设施的内容,比如RTOS、协议栈、文件系统等等。

需要指出的是,软件基础设施,也不是不变的,而是随着产品开发发展,不断会有新的组件和元素,加入到软件基础设施中去,也有可能会剥离掉旧的组件,就像生物的新陈代谢。

软件基础设施的新陈代谢,要温和,要相对稳定,添加和删除,都要执行谨慎原则。

目录
相关文章
|
1月前
|
自然语言处理 算法 JavaScript
面向长文本的多模型协作摘要架构:多LLM文本摘要方法
多LLM摘要框架通过生成和评估两个步骤处理长文档,支持集中式和分散式两种策略。每个LLM独立生成文本摘要,集中式方法由单一LLM评估并选择最佳摘要,而分散式方法则由多个LLM共同评估,达成共识。论文提出两阶段流程:先分块摘要,再汇总生成最终摘要。实验结果显示,多LLM框架显著优于单LLM基准,性能提升最高达3倍,且仅需少量LLM和一轮生成评估即可获得显著效果。
71 10
面向长文本的多模型协作摘要架构:多LLM文本摘要方法
|
1月前
|
机器学习/深度学习 人工智能 NoSQL
记忆层增强的 Transformer 架构:通过可训练键值存储提升 LLM 性能的创新方法
Meta研究团队开发的记忆层技术通过替换Transformer中的前馈网络(FFN),显著提升了大语言模型的性能。记忆层使用可训练的固定键值对,规模达百万级别,仅计算最相似的前k个键值,优化了计算效率。实验显示,记忆层使模型在事实准确性上提升超100%,且在代码生成和通用知识领域表现优异,媲美4倍计算资源训练的传统模型。这一创新对下一代AI架构的发展具有重要意义。
76 11
记忆层增强的 Transformer 架构:通过可训练键值存储提升 LLM 性能的创新方法
|
8天前
|
机器学习/深度学习 算法 文件存储
神经架构搜索:自动化设计神经网络的方法
在人工智能(AI)和深度学习(Deep Learning)快速发展的背景下,神经网络架构的设计已成为一个日益复杂而关键的任务。传统上,研究人员和工程师需要通过经验和反复试验来手动设计神经网络,耗费大量时间和计算资源。随着模型规模的不断扩大,这种方法显得愈加低效和不够灵活。为了解决这一挑战,神经架构搜索(Neural Architecture Search,NAS)应运而生,成为自动化设计神经网络的重要工具。
|
3月前
|
运维 负载均衡 Shell
控制员工上网软件:高可用架构的构建方法
本文介绍了构建控制员工上网软件的高可用架构的方法,包括负载均衡、数据备份与恢复、故障检测与自动切换等关键机制,以确保企业网络管理系统的稳定运行。通过具体代码示例,展示了如何实现这些机制。
154 63
|
2月前
|
机器学习/深度学习 算法 数据可视化
基于深度混合架构的智能量化交易系统研究: 融合SSDA与LSTM自编码器的特征提取与决策优化方法
本文探讨了在量化交易中结合时序特征和静态特征的混合建模方法。通过整合堆叠稀疏降噪自编码器(SSDA)和基于LSTM的自编码器(LSTM-AE),构建了一个能够全面捕捉市场动态特性的交易系统。SSDA通过降噪技术提取股票数据的鲁棒表示,LSTM-AE则专注于捕捉市场的时序依赖关系。系统采用A2C算法进行强化学习,通过多维度的奖励计算机制,实现了在可接受的风险水平下最大化收益的目标。实验结果显示,该系统在不同波动特征的股票上表现出差异化的适应能力,特别是在存在明确市场趋势的情况下,决策准确性较高。
88 5
基于深度混合架构的智能量化交易系统研究: 融合SSDA与LSTM自编码器的特征提取与决策优化方法
|
8月前
|
存储 边缘计算 Cloud Native
“论模型驱动架构设计方法及其应用”写作框架,软考高级,系统架构设计师
模型驱动架构设计是一种用于应用系统开发的软件设计方法,以模型构造、模型转换和精化为核心,提供了一套软件设计的指导规范。在模型驱动架构环境下,通过创建出机器可读和高度抽象的模型实现对不同问题域的描述,这些模型独立于实现技术,以标准化的方式储存,利用模型转换策略来驱动包括分析、设计和实现等在内的整个软件开发过程。
386 3
|
4月前
|
前端开发 JavaScript
掌握微前端架构:构建现代Web应用的新方法
本文介绍了微前端架构的概念及其在现代Web应用开发中的优势与实施方法。微前端架构通过将应用拆分成独立模块,提升了开发效率和灵活性。其核心优势包括技术栈灵活性、独立部署、团队协作及易于维护。文章详细阐述了定义边界、选择框架、管理状态和通信等关键步骤,并讨论了状态同步、样式隔离及安全性等挑战。微前端架构有望成为未来Web开发的重要趋势。
|
6月前
|
Cloud Native 安全 中间件
核心系统转型问题之云原生架构下的基础资源设施应重点考虑什么方面
核心系统转型问题之云原生架构下的基础资源设施应重点考虑什么方面
|
7月前
业务架构问题之什么是自上而下和自下而上的设计方法
业务架构问题之什么是自上而下和自下而上的设计方法
230 18
|
6月前
|
NoSQL Serverless 数据库连接
Serverless 架构实现弹幕场景问题之initializer方法在执行过程中遇到错误如何解决
Serverless 架构实现弹幕场景问题之initializer方法在执行过程中遇到错误如何解决
54 0

热门文章

最新文章