几种Linux下嵌入式开发环境的简单介绍
buildroot
emDebian实际上并不一定适合于资源非常紧缺的超小型系统,比如只有2M Flash的小型控制系统。另外发行版的软件通常会以通用代码来编译,例如,为了尽可能在各种X86平台上都能够安装,大多数发行版通常会以i686甚至 i386代码集来编译软件,可以使文件的通用性很强,但CPU的性能却不能发恢到最好(这就是为什么有时会看到一些厂商或爱好者发布PIII、PIV、 athlon等优化系统的原因),这对于嵌入式系统来说也不会是一件好事情。另外,没有源码的控制权,一些需要定制的东西也会变得难以实现,因此,从源码开始构建仍然有必要。
嵌入式Linux开发中使用的CPU速度往往向对不会太高,因此,尽可能提高代码的性能就非常必要。通常开发人员应该对该CPU的具体型号有一定的了解,以便启用编译器中对该型号的优化,以ARM为例,我们可以通过 -march=armv5te 和 -mtune=arm9tdmi 来对代码在ARM9上的运行进行优化。有时这些优化体现出来的性能改善是比较大的,我曾对比过一些复杂算法的代码优化前后的性能(执行速度),都有一定的提升。另外在PIV上测试过以i686和pentium4对一个语音编码算法进行优化,运算速度居然提高了几倍。
这种幅度的提升可能只是一个特例,这个算法有大量的复杂浮点运算,使用i386或 i686指令集和使用更先进的PIV指令集编译出来的机器代码对于同一个运算的解释可能采用完全不同的指令来完成,因此性能提升较大就不足为奇了。同样这种代码,在ARM上通过ARM4和ARM5来优化后在ARM9上运行,却没有那么大的提升。看来对CPU的一定了解也应该是嵌入式系统软件设计者应该具备的能力。
那么又如何控制可执行文件的大小呢?除了却除软件中不需要的部份外,我们还应该考虑软件所引用的库文件。GNU的Glibc是一个非常宠大而完整的库,至少对于嵌入式系统来说,其体积显得过于大了一些。uClibc的提出较好的解决了这样一个问题。uClibc尽可能的兼容Glibc,大多数应用程序可以在很小或完全不修改的情况下就可能使用uClibc替代glibc。通过 uClibc来代替Glibc,可以在不改变应用程序功能的前提下,大大减少发布文件的大小,无论应用程序以静态链接来编译,还是以动态链接形式编译。
不过使用uClibc代替并不是简单的设置一两个参数就行了,通常需要使用一个不同的工具集(gcc/binutils等)来编译代源码。手工的构造这样一个环境,对于大多数普通程序员来说,不一定是一件很简单的事情,因此, uClibc的开发者创造出一个叫做buildroot的工具集。 buildroot将自动构造编译基于uClibc代码的工具集和uClibc库,并提供一个可配置的框架和一些构建一个基本系统的配置文件。用户只需要通过配置菜单选择了相应的目标软件,buildroot就可以从构建基本工具集开始,一直到最后构建出目标系统所需要的东西,如嵌入式系统常用的基于 ext2的initrd,jffs根文件系统,压缩的根目录树等,这些代码都是基于uClibc而不是系统的Glibc的。Buildroot对主机系统的要求较小,通常只需要主机系统提供足以构建工具链(toolchain)的工具,如gcc/binutils等,当工具链编译完成后,对目标系统需要的源码的编译过程与主机系统的开发工具集基本上就没有什么关系了。因此,不同的主机如果能够通过第一步,编译完成工具链,那么编译出来的目标系统的执行代码就可以几乎不存在由于系统引起的差异。这样,开发人员就可能在各自喜欢的Linux发行版上进行开发,而不必担心出现什么兼容性问题。
linux操作系统文章专题:linux操作系统详解(linux不再难懂)
评论