构件化mbedOS工程框架研究与实现

刘长勇 王宜怀 彭 涛

1(武夷学院数学与计算机学院 福建 武夷山 354300) 2(苏州大学计算机科学与技术学院 江苏 苏州 215006) 3(认知计算与智能信息处理福建省高校重点实验室 福建 武夷山 354300)

0 引 言

随着嵌入式技术的快速发展和硬件工艺水平的逐渐提高，微控制器(Microcontroller Unit，MCU)的性能、功能和种类也得到不断更新，实时操作系统(Real-Time Operating System，RTOS)也逐渐成为嵌入式系统中不可或缺的部分。由于实时操作系统内核的底层性、代码结构的复杂性、调度的实时性，从而增加了嵌入式软件的开发难度、降低了开发效率。基于构件的设计技术越来越广泛地应用于大规模、复杂嵌入式软件开发[1]。通过对工程框架进行构件化的设计，将一个个相对独立的、被充分证明为可靠的构件统一在一起，对外提供调用接口[2]，可以有效提高软件的开发效率和软件质量，并能缩短开发时间、降低开发费用[3]，使嵌入式软件达到可适用、可移植和可修改性的目的。

目前已有很多关于嵌入式工程框架的研究，如刘宇传等[4]提出基于Module-MSG(Module-Message)的软件开发框架；戴巍等[5]利用组件的设计方法，将自顶向下和自底向上的开发方法相结合起来，提出了基于组件的嵌入式软件框架设计；屈新怀等[6]采用抽象工厂设计模式和模型驱动思想，利用XML关系数据存储机制和嵌入式SQL通信方式，提出可控嵌入式构件框架的开发方法；李运喜[7]从技术特征、能力组成、结构框架等角度对操作系统的软件架构进行分析，提出一种统一的、开放的、弹性的操作系统软件架构。

mbedOS是2014年由ARM公司出品的，是一种专为物联网(IoT)中的“物体”设计的开源嵌入式操作系统[8-9]。其不仅兼顾不同的内核、不同的微控制器和不同的开发环境，而且也提供各种硬件驱动、多种网络通信协议、各类测试用例和工具，这样的RTOS无疑是全面且强大的。而对于一般的嵌入式应用开发，其针对的是某一特定的内核、具体型号的MCU和开发环境，要从庞大的RTOS中抽取出应用开发所需的内容是有较大难度的。因此，为了降低开发难度、提高开发效率，必须按照嵌入式软件工程的基本思想和构件化的软件技术的要求，对RTOS工程框架建立模型，以构件为基础，规范文件组织结构，这样才能使嵌入式系统开发者快速地使用RTOS进行软件开发。本文阐述了RTOS软件最小系统的概念，给出了mbedOS最基本功能要素的抽取原则，依据嵌入式软件工程的基本理论和软件构件化的基本方法，提出了工程框架的设计原则，形成了结构合理、可扩充的、构件化的mbedOS工程框架，分析了该工程框架的合理性和可移植性。实验表明，该工程框架具有结构清晰、组织合理、可移植、可利用、可修改等特点。

1 RTOS软件最小系统

1.1 系统定义

在嵌入式系统开发中，不仅涉及到硬件电路，而且还需要软件编程。微控制器MCU的硬件最小系统是指包括电源、晶振、复位、写入调试器接口等可使内部程序得以运行的、规范的、可复用的核心构件系统[10]。类比硬件最小系统，本文提出软件最小系统的概念，它是包含工程最基本要素，能满足点亮一个发光二管最基本要求，甚至带有串口调试构件的工程框架，在此工程框架上用户可以自行进行扩充，添加新的构件，形成新的工程框架。

定义1无操作系统软件最小系统是指依据嵌入式软件工程的基本原则与基本思想，将说明文档、内核相关文件、微控制器相关文件、用户板构件、软件构件、中断服务程序和无操作系统主程序等嵌入式系统工程最基本要素，按照构件化技术的基本理论组织成具有层次目录结构的工程框架。该工程框架能有效地降低项目的开发难度，提高开发效率，具备良好的可扩充性、可描述性、可移植性、可复用性的特性。

定义2RTOS软件最小系统是指将任务管理、调度管理、内存管理、中断管理、时间管理以及同步与通信等RTOS最基本功能要素，以构件的形式添加到无操作系统软件最小系统上，构成能至少实现对两个任务进行调度的工程框架。

1.2 mbedOS抽取原则

为了能构建RTOS软件最小系统，现以mbedOS为例介绍如何抽取RTOS的最基本功能要素。本文以5.7.4版本的mbedOS为研究对象，其源代码[9]可以从网站下载，解压后共包括2 503个文件夹和12 369个文件，所占空间达395 MB。它主要提供了内核管理、各类开发板外设定义与驱动、外设访问接口和各类应用程序的测试用例等，这样的操作系统是非常复杂且庞大的。但对于一般的嵌入式系统开发应用来说，它所采用的开发板在一个项目中通常情况只有一种。因此，必须从mbedOS代码中进行合理的抽取，以适用于自己的应用开发，可以遵循以下抽取原则：

1) 只针对某一内核的微控制器MCU。根据嵌入式系统开发中所涉及到的MCU内核，抽取与MCU相关的内核文件。

2) 最基本功能要素。其基本满足任务管理、内存管理、定时器管理、中断管理、调度管理、同步与通信等功能。

3) 保留CMSIS编译器相关文件。如CMSIS编译器GCC头文件、通用头文件和版本头文件等。

1.3 mbedOS最基本功能要素来源分析

按照以上抽取原则，去除外接组件、文档、中间设备访问层、硬件适配层、中间设备组件接口、目标板外设驱动、工具、USB驱动及各类测试等，主要保留了CMSIS编译器与芯片相关文件和系统内核等最基本功能要素文件。按“分门别类、各有归处”原则，将抽取后的文件分为编译器类、芯片类、mbedOS管理类、mbedOS内核类及mbedOS保护类，分别放在不同的文件夹内。以MKL36Z64VLH4[11]微控制器(ARM Cortex-M0+内核)为例，介绍这些文件来源，详见表1。由于篇幅有限，相同来源的文件未列出，具体可到苏州大学嵌入式学习社区网站(http://sumcu.suda.edu.cn)的“教学培训-教学资料-mbedOS”位置，下载“SD-mbedOS-Frame(KL36)”，查看测试工程的源代码。

表1 抽取后的mbedOS各文件来源表

2 mbedOS工程框架设计

2.1 设计原则

1) 遵循嵌入式软件工程的基本理论。工程框架的设计必须做到可理解、可移植、可修改，这样才能使开发的嵌入式软件具有完备性、正确性、健壮性和可靠性[12]。

2) 遵循嵌入式软件构件设计基本思想和基本原则。软件构件封装前，最关键的工作是要对构件的共性和个性进行分析，设计出合理的、必要的对外接口函数及其形参，以知识要素为核心，以模块独立性为准则进行封装。尽量做到：当一个底层构件应用到不同系统中时，仅需修改构件的头文件，对构件的源程序文件则不必修改或改动很小[10]。

3) 按照“分门别类、各有归处”原则。对工程框架的文件夹和共性文件进行归纳分类，以编号的形式建立相应的文件夹存放源程序和头文件。

2.2 结构分析

基于以上的设计原则，将各类驱动、mbedOS以及用户程序等均以构件的形式进行设计，形成mbedOS的构件化工程框架SD-mbedOS。该工程框架采用三层逻辑架构，即硬件层、中间层和应用层。硬件层包括内核访问层和微控制器访问层，其中芯片访问层包含硬件驱动构件、链接文件和启动文件，内核访问层包括编译器头文件、中断嵌套控制寄存器和异常处理程序。中间层包括软件构件、应用构件和实时操作系统。应用层包括中断处理程序、无操作系统主程序、操作系统启动程序、自启动任务执行程序和用户任务程序等。SD-mbedOS工程框架的层次模型与树形结构的对应关系如图1所示。

图1 mbedOS工程框架层次模型与树形结构对应关系

SD-mbedOS工程框架的树形结构包含8个带编号文件夹，其简明功能及特点如表2所示。

表2 SD-mbedOS工程文件夹内的基本内容

续表2

2.3 可移植性分析

工程框架的可理解、可移植、可复用是其价值的重要体现，良好的工程框架应该能在不同的内核、MCU、工程及开发环境之间进行有效移植。本文工程框架在设计时就已经考虑到可移植性问题，在设计文件夹时将文件按照“分门别类、各有归处”的原则放到相应的文件夹中，在进行框架移植时只要修改少量的内容就可完成。由于篇幅有限，表3列出了SD-mbedOS工程框架在MKL36Z64VLH4(简称KL36)、S32K144[13]和MSP432[14]三款MCU上的移植比较。

表3 SD-mbedOS工程框架在多个MCU上移植

注：表中的数字采用十六进制表示。

3 SD-mbedOS工程框架的应用与测试

3.1 测试工程的基本功能

测试工程在Kinetis Design Studio 3.0.0 IDE集成开发环境和金葫芦AHL-A系列Cortex-M0+内核的KL36微控制器(即AHL-AN100VL型号开发板)上进行。该开发板集成了SWD写入器、串口、三色灯、光敏电阻、磁阻、热敏电阻、LCD液晶、触摸感应接口TSI及用标准排针引出芯片的所有引脚，可以满足一般嵌入式应用开发的需要。本测试工程设计了三个任务，红灯任务每3秒闪烁一次，蓝灯任务每2秒闪烁一次，绿灯任务每1秒闪烁一次。

为实现以上各功能，需要在08_mbedOsPrg文件夹下添加自启动任务执行函数app_init、红灯任务thd_redlight、蓝灯任务thd_bluelight和绿灯任务thd_greenlight。自启动任务执行函数app_init的执行流程如图2所示，红灯任务(或蓝灯任务、绿灯任务)的执行流程如图3所示。

图2 app_init执行流程

图3 小灯执行流程

3.2 工程的运行测试

将测试工程编译后下载到开发板上，重新上电启动芯片，可以观察到红灯任务每3秒闪烁一次，蓝灯任务每2秒闪烁一次，绿灯任务每1秒闪烁一次。同时可以通过串口调试器输出各灯任务的切换情况。工程测试的运行结果如图4所示。可以看出在mbedOS的调度下任务运行正常，程序执行逻辑准确，实时性能得到满足。

图4 测试工程运行结果

4 结 语

实时操作系统mbedOS为不同的内核、MCU、开发环境、芯片生产厂家和用户提供了微控制器软件接口标准、各类通用库函数、目标板外设驱动、各类测试用例等丰富的资源，是一个庞大且功能强大的体系。任一工程师或用户在某一特定的应用开发中，一般是选用某一具体内核的MCU，要从这样一个庞大的资源体系中抽取出与开发相关的内容是有一定难度和困难的，需要花费大量的时间和精力。本文深入剖析mbedOS庞大资源的构成，厘清其结构关系、文件包含、宏定义、各类管理机制，根据嵌入式软件工程的基本思想，基于mbedOS提出了以构件为基础、以软件最小系统为核心的可移植、易扩充的工程框架，为广大嵌入式系统开发者快速应用、透彻理解mbedOS提供了基础，也为mbedOS的升级、MCU的变更、硬件驱动的增加等提供了良好的扩充模板。未来将针对内核、MCU、开发环境、应用需求等有关mbedOS移植的问题作进一步的讨论。