嵌入式Linux具有稳定、可伸缩及开放源代码等特点,可兼容多种处理器和主机,广泛适用于各种产品和应用。但是,交叉编译、设备驱动程序开发/调试,以及更小尺寸等要求对嵌入式Linux开发者来说都是严峻的挑战。为应对这些挑战,针对嵌入式Linux开发的专用工具应运而生,而且发展十分迅猛。
本文关键词:
嵌入式开发嵌入式系统嵌入式Linux开发工具
Linux是少数既可以在嵌入式设备上运行也可作为开发环境的操作系统之一。这一特性可让开发者在转向此开发系统之前于常用硬件(比如X86桌面系统)之上开发、调试和测试应用程序和库,因此可减少对标准参考平台和指令集仿真器的依赖。这一技术仅适用于应用程序和库,但不适用于设备驱动程序,因为后者的开发依赖于Linux架构。
Linux的快速发展及其桌面方案的不断涌现提出了一个重要问题:所选择的工具方案怎样在不同的Linux分布式系统上运行?它们依赖于主机平台的软件配置吗?
有些Linux工具提供独立于主机平台的开发环境,包括一系列可支持开发工具的应用软件、库和实用程序。这一方法几乎将开发环境与主机配置完全隔离开来,因此主机可以是任何Linux分布式系统,而且任何更新和修改都不会影响开发环境的功能。
这种方法的主要缺点是对存储空间的要求有所增加——约200MB,因为它自己实际上相当于一个微型Linux分布式系统。
可用的工具
一个
嵌入式Linux产品的开发需要几个阶段,包括为目标板配置和构建基本Linux OS;调试应用程序、库、内核及设备驱动程序/内核模块;出货前最终方案的优化、测试和验证。
有数百种开放源代码开发工具可供选择。只要开发者原意花时间和精力去调研、实施和维护一系列各不相同的工具,总能找出一个完整的解决方案,完成几乎任何开发任务。HSPACE=12 ALT="图1:开发者必须精确地考虑到这些工具的松散集合能提供什么样的功能,以及需要付出多大的努力才能形成完整的解决方案。">
在Linux应用程序和库的调试方面,GNU Debugger(GDB)作为一种标准已有几年的历史。它是一种命令行程序,由多个不同的图形用户界面前端予以支持,每个前端都能以多种方式提供调试控制功能。尽管GDB不是一个完美的方案,但它足够应对各种调试任务,而且已经得到开放源代码团体的广泛支持。
Linux内核或设备驱动程序的调试要比应用程序的调试繁琐得多。
在做调研时,以下方面应特别注意:
什么调试方法支持要开发产品的硬件?
需要什么内核补丁程序?
还需要其它什么补丁程序?
调试界面怎么样,如何使用?
该工具需要调试内核模块及处理虚拟地址转换吗?
还需要其它什么工具才能提供完整的方案?
经过进一步的调查,开发者往往发现工具A和工具B并没有提供完全一致的功能,因为它们是在彼此独立的情况下开发的。结果,开发者必须精确地考虑到这些工具的松散集合能提供什么样的功能,还需要付出多大的努力才能形成完整的解决方案。
如果不同处理器类型间的集成、可用性、互操作性和移植性很关键的话,开发者应考虑购买商用开发工具。这主要是因为将开发一个“免费”方案所付出的努力考虑进去,商用开发工具并不算贵。
Linux BSP
Linux系统有两大主要部分:带设备驱动程序的Linux内核;以及根文件系统,包括系统所需的全部支持应用程序、服务和库。
除了驻留在目标板上的OS组件外,还需要创建一个由GNU Compiler Collection构成的交叉编译环境,为库和二进制程序(binutils)提供支持。
虽然几乎每一个组件都可在网上找到,但在硬件或设备驱动程序支持、集成测试信息、交叉编译指南或软件兼容性方面却很难收集到太多信息。尽管开发者可从网上免费下载各种组件以配置
嵌入式Linux操作系统,但每个组件在版本、支持、稳定性和测试等方面的状态则需要开发者自己决定。然后,开发者还要完成最后的OS集成和测试,以及为所开发产品提供终身Linux OS维护。
另一方面,嵌入式Linux供应商所提供的商用Linux板支持工具包一般都是经过预先安装和测试的,而且提供支持和维护。其它须考虑的因素包括Linux桌面主机将会添加不同的库和内核功能,以及由于组织内的开发者变动而引起的长期维护问题。
品质保证部门一般会执行一系列严格的验证和性能测试,其中包括存储器泄漏检测/纠正、代码优化和任务跟踪等。那些想利用开放源代码工具开发面向非X86平台的嵌入式Linux产品开发者将会发现这一任务甚至要比选择开放源代码调试方案难得多。Linux Trace Toolkit、Valgrind工具及其它存储器分析程序可完成部分测试和验证任务。但总的来说,它们缺乏关键特性、集成功能及广泛的硬件支持。这些开放源代码分析工具的评估过程与评估调试方案的过程基本相同。
技术支持:0755-25327151和0755-83690619