几种Linux下嵌入式开发环境的简单介绍

　　做Linux嵌入式系统的对常见的几种嵌入式开发环境一定不会默生，由于主要接触网络相关产品的一些系统设计，因此，将可能用到的嵌入式开发环境简要总结一下。主要涉及下面的几个东东：

　　emDebian - http://emdebian.sourceforge.net

　　uCLinux - http://www.ucLinux.org

　　buildroot - http://buildroot.uclibc.org

　　scratchbox - http://www.scratchbox.org

　　openEmbedded - http://oe.handhelds.org

　　emDebian

　　emDebian基于将Debian用于嵌入式系统的目的而开发。Debian是一个发展很快的项目，在我第一次用Debian时，就再也不愿意换用其它的发布版了，目前我用的Debian已经安装了有两年的时间了，但现在系统仍然是 “最新”版本，良好的在线软件升级系统是Debian成功的原因之一。目前Debian已经支持11个体系的系统，包括X86、PPC、MIPS、 ARM、SH等(据最近的一则消息，ARM有可能不再支持)，并包含了大量的软件。这些要归功于Debian的开发团队，正因为有许多人使用和支持，因此，不是比较偏门的软件，基本上不需要从源码来安装，这也是我喜欢用 Debian的原因之一。

　　这样好的一个系统，当然有人愿意将其用到嵌入式系统中去。emDebian基于一个很简易的嵌入式系统开发的想法来构造嵌入式系统，即从一个成熟的系统中去除不需要的部份(如文档和不需要的工具)，精简出一个小的系统，这与下面要介绍的几个工具的想法刚好相反(下面几个都是基于 from scratch 即从无到有，从头构建的方式)。emDebian提供一些工具来协助完成从现有的系统或安装包(deb文件，类似Redhat的rpm)中提取需要的东东，并协助完成完整系统的构建，当然也支持交叉构建了，比如你可以在X86 的PC上构建一个基于ARM的嵌入式系统，而整个过程不需要编译任何一行源代码。

　　顺理成章的，emDebian的重要优势就展现出来了，现在你用的CPU超出11个 Debian支持范围了吗?没有，那么你可以简单的通过 emDebian构建目标系统;你所需要的主体软件在Debian支持的官方和非官方近2万个软件以外吗?没有，那么恭喜你，明天就可以给老板交工了。当然，对于特定的软件，可能还是需要从源码来构建，不过同样的，我们可以将其生成Deb包，然后将配置加到emDebian工具集中，同其它所有软件一样的选取和配置。

　　emDebian的发展似乎不是想像的那么好，现在主页上的新闻更新还是去2004年的。

　　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发行版上进行开发，而不必担心出现什么兼容性问题。

　　uCLinux

　　uCLinux与emDebian至少有两个重要的区别，第一是构建方式，前面已经提到过了，uCLinux属于 from scratch 一类的。另一个不同的地方，uCLinux是支持不在emDebian支持的11种CPU的，当然，这个说法不是很恰当，正确的说法是uCLinux支持那些不具备MMU单元的CPU体系。uCLinux的第一个目的是支持MC68328芯片，现在已经能构支持更多的CPU，如Intel i960，ARM等。不过，uCLinux的主体开发团队目前已经不再支持ARM了，还好 Samsung 的 Hyok S. Choi 接过了接励棒，Linux 2.6版本的补丁可以在 uCLinux/ARM2.6 找到。