基于Eclipse的嵌入式集成开发环境的研究与实现

胡 昊，蒋志翔，张 杨

（中国航天科工集团第二研究院706所，北京100854）

0 引 言

一个良好的集成开发环境能够简化开发过程，减轻开发人员用于工具上的精力，提高开发效率。当前比较流行的开发环境平台软件有Microsoft Visual Studio、Eclipse、Code Blocks等，这些开发环境提供了一般软件开发所需的一系列功能，然而对于嵌入式开发的支持却相对薄弱，或缺乏跨平台的支持，或缺乏一些开发功能；而对嵌入式开发支持较好的一些开发环境如Tornado又不提供源码，不能根据需求更改功能［1，2］。嵌入式系统的交叉开发环境一般包括交叉编译器、交叉调试器和系统仿真器等，并采用宿主机／目标机模式开发嵌入式应用软件。国内外虽然对于嵌入式方向的研究和工程较多，但真正掌握核心开发技术、尤其是完全掌握交叉开发流程的公司和个人却是少数。

在对通用的开发环境进行研究后，本文针对上述缺陷，提出对当前嵌入式集成开发环境的改进方案，并且在Eclipse框架的基础上进行了实现。本文旨在研究并实现能够在x86宿主机上交叉开发MIPS架构、龙芯3A 处理器的目标机上应用程序的集成开发环境。在开发环境中，不仅实现了基本的程序构建功能，为嵌入式工具链提供了健全的支持，同时还设计了一系列开发和测试工具，改进了编译方式，提高了开发效率，能够在一定程度上缩短开发周期、降低成本。

1 嵌入式实时操作系统

本文基于项目是面向MIPS架构的龙芯3A 硬件平台的嵌入式操作系统及集成开发环境的研发。进行交叉开发，必须在开发环境中集成目标机操作系统的一系列和编译链接相关的文件。本项目中目标机上运行的特定嵌入式实时操作系统，也是由项目组开发，如图1 所示为基于Rtems内核的嵌入式实时操作系统的架构图，分为4层结构：硬件抽象层、核心层、系统服务层和应用服务层［3］。硬件抽象层主要是和体系架构相关的驱动支持软件；核心层由一系列核心组件组成，包括实时任务调度、内存管理系统、IO 系统等模块组成；系统服务层主要完成给各种应用提供操作系统级的服务支持，包括VxWorks、Posix、Classic 3种API（application programming interface）的支持；应用服务层主要提供TCP／IP协议栈、GUI系统、文件系统等组件［4，5］。Rtems内核具有支持多任务，支持事件驱动、基于优先级抢占的调度算法和具有快速响应的中断管理等优势。

操作系统为上层应用程序的编写提供了一套API，但由于不是在目标机上直接开发应用程序，在宿主机上就需要提供目标机操作系统的各类链接库文件和头文件等［6］。将这些系统文件集成于开发环境目录之下，根据目录组织结构，设计开发环境的路径解析和文件查找功能，在构建程序时自动或手动去查找所需要的文件。

图1 嵌入式实时操作系统基本架构

根据各层的实现原理及关系，将操作系统源文件在Cygwin下编译成一系列的库文件和可执行文件，供开发环境在程序构建过程中调用。如图2所示即为开发环境中操作系统相关的主要文件目录树，其中Tyche目录下为程序构建过程中所需要的文件总目录，三级子目录tyche中是操作系统核心文件，里面主要包含了工具链的二进制文件（bin）、系统头文件 （include）、C／C＋＋库、系统库文件（lib）、makefile模板文件 （make）、说明手册 （man）等。

图2 开发环境中操作系统相关文件目录

2 CDT简介

CDT （C／C ＋＋development tool）是一套开源的Eclipse的插件，用于对C／C＋＋程序开发的支持。由于Eclipse平台强大的功能及友好的界面和特性，Java开发人员也想将这些优秀的性能提供给C／C＋＋开发人员。CDT对Windows平台和Linux 平台均提供了支持，并且由于Eclipse的插件结构形式，使得外部插件能够无缝连接到Eclipse内核中。本项目以最新的版本CDT8.2为基础进行研究，开发特定目标机平台的集成开发环境，相比较其他平台的集成开发环境，不仅拥有其已有的功能，同时还设计实现了一些新的功能，丰富了开发环境的辅助功能。

由于其复杂性，CDT 被分成了许多组件，他们都采用独立插件的形式开发，高度包含了面向对象的设计思想，从底层到高层的实现都秉承了高内聚、低耦合的设计原则，使得组件功能的扩展和删除都相当清晰。CDT8.2 包含了几十个独立插件，然而核心插件及功能描述见表1。

表1 CDT 的核心插件与功能描述

CDT8.2 提供了对GNU、Cygwin、MinGW、Visual Studio等一系列工具链的支持，并且集成了工程创建管理、工程构建、调试和目标机状态查看等C／C＋＋程序开发的配套功能。然而由于本项目中目标机平台的特殊性，CDT本身没有提供对MIPS架构目标机的支持，所以不能够直接使用CDT，需要进行2次开发以实现开发环境对C／C＋＋的支持。

3 设计实现

3.1 工程管理功能

开发环境的核心功能之一就是工程管理，而其中的难点就在于实现在开发环境中指定程序的构建方式。因为在编写大型应用程序的时候，往往需要面对复杂的编译过程和大量的源代码文件，该过程中需要处理配置选项、多种格式的输入输出文件、确定文件间复杂的依赖关系，同时还需要应对工程的反复修改编译［7］。工程上常用Makefile和make工具来实现程序自动构建的过程，但在开发大型程序时，如果程序员手动去编写所有的Makefile文件及组织相应的目录，人工地分析上述的输入输出文件及依赖关系将会使开发过程变得更为繁琐、开发效率极为低下，而且在后续的开发过程中工程文件将难以维护。特别是在嵌入式系统中，由于环境变量配置复杂，所需的库文件没有良好支持，极易导致编译或链接错误，因此在集成开发环境中提供工程的自动管理和构建功能，即自动生成Makefile，就显得十分必要［8］。

所需自动生成的Makefile共有4种：SubDir.mk、Objects.mk、Sources.mk 和 Makefile［9］。其中前3 种为子Makefile文件，最后一个为主Makefile，主Makefile中用include语句包含了前3种子Makefile。CDT8.2中各Makefile文件对应的功能和实现函数如下：SubDir.mk用于声明各级子目录模块的源文件和依赖关系，生成SubDir.mk的函数名为populateFragmentMakefile；Objects.mk用于声明生成的所有目标文件名和库文件名，生成函数名为populateObjectsMakefile；Sources.mk用于声明依赖的源文件及子目录名称，生成Sources.mk 的函数为populateSources－Makefile；生成主 Makefile 的函数为populateTopMakefile［10］。

开发环境中Makefile的生成流程，如图3所示。

图3 开发环境中Makefile的生成流程

项目中为了不破坏源代码的封装性和扩展性，保留了CDT 中这些接口函数的名称，而重构了其实现方式，以生成Rtems操作系统下的Makefile文件。第1步，首先开发环境能够自动为用户工程配置大部分环境变量和编译链接选项，图形化的配置界面也能让用户自行配置一些其他选项，在Makefile的生成过程中，会先获取这些配置信息并保存在相应的数据结构中，通过解析这些配置信息并根据模板编译规则生成一条条的编译命令，在后续过程中写入Makefile。第2步，遍历工程目录下的所有文件，获得工程文件的目录树，再根据文件后缀名判定是否为可编译的源文件，若为可编译的源文件则写入Makefile中的对应位置，生成依赖关系。最后将第1步中自动生成的编译命令写入Makefile，完成所有Makefile，随后调用make 工具，将Makefile中的命令传递给编译器和链接器执行，生成目标文件，完成工程的整个构建过程。

开发环境以良好的面向对象编程方式封装数据和接口，既继承了Eclipse和CDT 已有的优良特性，又包含了新增的功能，从而实现了开发环境中的工程管理功能，无需开发者自行去分析工程目录、工程配置信息和文件修改记录，能够自动编写Makefile文件并生成相应的编译命令，使得工程管理的难度明显下降，从开发方式来说也符合软件工程的规范。

3.2 编译链接功能及优化

3.2.1 编译链接

如图4所示，为项目中实现的应用程序构建流程。程序的构建过程从新建模板工程向导开始，在编辑器中编辑好源代码后，开发环境会自行调用C／C＋＋Parser和Codan工具检查代码语法和格式，之后根据用户操作执行工程的构建过程。

图4 开发环境中程序构建流程

开始执行工程构建时，首先根据用户设置自动构建工程的Makefile 文件，其实现方法上一部分已有介绍。Makefile文件只是写入文件间依赖关系及编译链接规则，真正完成程序构建的是汇编器、编译器、链接器等一系列工具链。开发环境中提供了对2种工具链的支持，即Cygwin工具链和MinGW 工具链，绝大多数情况下使用的是在Cygwin环境下重新编译的 MIPS 工具链。包括mipstyche3.6－as （汇编器）、mips－tyche3.6－gcc （编译器）、mips－tyche3.6－g＋＋ （编译器）、mips－tyche3.6－ld （链接器）等，这些工具及相关文件都被放置到本文第1部分所提到的tyche／bin／目录下，开发环境根据系统环境变量进行查询和调用。对Makefile中的编译规则和文件依赖关系进行解析后，开发环境将调用make工具将对应的命令传递给上述编译工具，编译工具根据需要的文件查找Tyche目录下所需要的相关操作系统头文件、库文件以及工程目录下的源代码文件，最终生成目标机上可执行程序。

3.2.2 增量编译

在实现上，为提高工程的编译效率，研究并在开发环境中实现了增量编译功能。遍历工程目录下的所有文件，以接口类IResourceDelta保存工程文件目录树和配置信息的修改内容，再次构建工程时，获取记录的上一次编译时的工程信息，与当前工程信息对比，从而确立了工程的修改内容，即增量，根据增量信息，重新生成Makefile。

程序构建时，先判定编译方式是增量编译还是完全编译，如果是完全编译 （通常为第1次编译工程或者是用户选择完全编译选项），则会先执行工程清理过程，删除当前工程目录下所有Makefile和目标文件，再重新编译所有的源文件。如果是增量编译，就调用genrerateMakefiles 函数，其中用ResourceDeltaVisitor类的visit函数得到当前工程的IResourceDelta，即得到了工程内源文件和配置信息的修改记录；第2步，判定修改方式是增加、删除还是其他，并将这些信息告知Makefile的生成器，生成器遍历已修改的文件，根据修改过的文件名称和编译依赖规则重写Makefile，这样在后续真正的编译过程中就只会重新编译修改过的源文件及其依赖的文件，而不会重新编译未修改过的源文件。这样就实现了增量编译功能，避免了因为少量的源代码修改而需要重新编译整个工程的复杂过程，提高了编译效率。

增量编译过程及增量Delta的存储结构，如图5所示。

图5 增量编译过程及增量Delta的存储结构

3.2.3 代码检查

程序开发过程中，源代码自动检查也是集成开发环境设计中一个重要的问题，一个用户友好的开发环境必须提供较为完备的代码检查功能。Codan是一个非常优秀的C／C＋＋静态代码审查工具，将其与CDT 集成后，在编写程序源代码和工程编译过程中，开发环境会自行调用Codan工具检查代码语法格式和进行逻辑分析，例如缓冲区溢出问题，就能够被自动检查出来，并在出错位置以编辑器标记的形式输出，建立控制台输出信息与源代码位置的映射，实现错误代码定位功能，以便于开发人员修改程序代码。

Codan在实现上使用的是java的非确定型有穷自动机（nondeterministic finite automaton，NFA）引擎，这种正则引擎的特点是以表达式为主导，模式正则表达式在编译时效率较高，需要内存小，尽管在匹配过程中使用回溯匹配的算法，但使用者可以直接操控匹配的过程。如图6所示为NFA 引擎的一个匹配示例。

图6 NFA 引擎状态图示例

在程序的编译期，开发环境还需要获取编译器的所有输出信息并以流的方式重定向到控制台，对这些输出的字符串信息进行处理，以特定的方式显示出来。在字符串信息的处理上就采用了Codan的字符串处理函数，以java的NFA 正则表达式引擎基础，根据模式正则表达式匹配编译器输出信息，从而准确高效地分辨出正常输出、警告信息，错误信息，并以颜色标记的方式在控制台输出，为开发环境提供了完善的代码查错功能。

3.3 调试代理

调试方式也是嵌入式开发不同于一般应用开发的一项。本项目在开发环境实现了3种程序调试下载方式，即ejtag调试方式、串口调试、网络调试，为上层开发者提供了多种调试方式，可根据硬件条件的不同使用不同的调试下载方式。ejtag调试方式采用的是龙芯公司的ejtag仿真器链接目标机和宿主机，经开发环境下载调试目标机程序；网络调试实现经网线连接的下载调试方式，为追求下载速度和实现的简易，采用基于UDP 协议的TFTP 协议进行通信；串口调试方式则是使用串口线连接目标机与宿主机，采用RPC协议进行通信。

虽然调试方式有多种，但原理上大同小异。执行调试指令的过程是，先将GDB debugger的命令转化为机器更易处理的MI接口命令，MI是开发环境和调试接口交互的接口。之后发送给通信代理模块，发送给目标机，经解析后传递给GDB server执行，执行的结果又以特定的通信协议返回给宿主机开发环境进行解析，最后在用户界面显示，从而实现程序的调试执行［2］。

项目中使用的Debugger是在Cygwin环境下重新编译生成的mips－tyche3.6－gdb，在编译时给编译器增加参数－g，就能够在可执行文件中加入调试信息，包括源代码中变量描述定义信息，函数类型及参数信息等；在底层实现上实际上是调用ptrace系统调用获取调试进程的运行状态，比如堆栈的使用情况、各种变量的值等；获取的这些程序运行信息经过指定的通信协议封装成数据包回传给宿主机，并在开发环境中以MI接口解析数据，最终在开发环境的调试视图中显示变量的值、寄存器使用情况，实现了单步进入、单步跳过、单步回跳等功能。

调试代理原理如图7所示。

图7 调试代理原理

在调试功能的多次使用测试后，得到如表2 所示的3种调试下载方式特点的比较，3种调试下载方式各有优劣。

表2 3种调试方式特点对比

4 测试结果与分析

测试环境由x86 宿主机、龙心3A 目标机及连接设备（包括网线、串口线、ejtag仿真器）组成。主要测试应用程序的开发流程相关功能。测试结果表明，开发环境能够提供完整的工程创建、工程管理、编译和调试等界面及功能，能够根据工程修改信息进行增量编译，节省编译时间。应用程序可以多种方式下载到目标机上，因通信协议的不同下载速度有所差异，但均能够保证程序正确运行，达到了丰富调试方式，改善既有功能的目的。

5 结束语

为适应高效高质量的嵌入式开发方式，本文对嵌入式开发流程进行了深入的研究，针对已有开发工具的不足，进行了2次开发，设计并实现了特定MIPS架构目标机的交叉开发环境。开发环境目前已能够满足用户开发及调试目标机上程序的需求，测试情况与设计相符，提供了友好的交互界面，在继承Eclipse已有功能的基础上，根据需求实现了针对MIPS平台的工程管理、增量编译及远程调试功能，缩短了编译时间，改善了工程管理方式，从而提高了上层开发人员的开发效率。下一步的工作中，将对开发环境进行完善，继续扩展必要的辅助功能，包括多核支持，性能分析、目标机状态监测等。

［1］Kopetz H.Real－time systems：Design principles for distributed embedded applications［M］.Germany：Springer，2011.

［2］Sriram S，Bhattacharyya SS.Embedded multiprocessors scheduling and synchronization ［M］.USA：CRC Press，2009.

［3］On－Line Applications Research Corporation.Getting started with RTEMS ［S］.2011.

［4］Andrew S Tanenbaum. Modern operating systems ［M］.USA：Prentice Hall，2009.

［5］Rafael V Aroca.A real time operating systems（RTOS）comparison ［C］／／Workshop de Sistemas Operacionais，2009：2441－2452.

［6］Tan S，Tran Nguyen B.Survey and performance evaluation of real－time operating systems（RTOS）for small microcontrollers［J］.IEEE Micro，2009，99 （1）：1－14.

［7］Randal E Bryant，David R O’Hallaron.Computer systems：A programmer’s perspective［M］.USA：Prentice Hall，2010.

［8］Leupers R.Code optimization techniques for embedded processors：Methods，algorithms and tools ［M］.USA：Kluwer Academic Pubilshers，2010.

［9］NAN Fang.Embedded integration development environment analysis and design on Eclipse［D］.Xi’an：Xidian University，2009 （in Chinese）.［南方.基于Eclipse的嵌入式集成开发环境分析与设计 ［D］.西安：西安电子科技大学，2009.］

［10］WANG Yang.Embedded integrated development environment design and implementation on Eclipse ［D］.Chengdu：UESTC，2012 （in Chinese）.［汪洋.基于Eclipse架构面向Linux的嵌入式软件开发环境的设计与实现 ［D］.成都：电子科技大学，2012.］