基于arm+uClinux的嵌入式系统的开发,移植

1．开发平台的选择和论证2．开发环境的建立3．一般程序的开发4．Linux程序向ARM+uClinux平台的移植5．剩下的问题希望诸位多多补充自己的想法，以利于大家共同提高。

1．开发平台的选择和论证一个项目拿到手，如何选择开发平台（主要是指CPU和操作系统以及开发环境和工具）应该说至关重要，有时这不光影响进度，产品质量，可维护性等一般问题，甚至涉及到方案的可实现性。

本人结合自己的网络监控系统简单归纳了一些对平台的考虑，还请各位补充。

从系统功能实现考虑：(1) 是否有片上外设，专用指令或配套的软件模块直接实现系统功能要求。

感觉这一条对很多人的决策影响很大(2) 价格这一点应通过CPU提供的资源综合考虑，它提供了多少有用的资源，多少没用的资源（那可都是银子呀！），还是那三个字，性价比，另一方面，是要抓主要矛盾，是不是有些特性是必须的，什么特性是用户需求里的亮点（就靠这些亮点往上抬价），这时该花的就得花了。

(3) 功耗本系统对CPU功耗要求不高，但对移动设备，这一点可是致命，而且这一点不是仅针对CPU，所有几乎器件都要勒紧裤腰带运行。

(4) 处理速度这项不用多说，大家都明白重要性，但具体算起来可是一门学问，一方面是自己需要多快的速度，如果加上非实时操作系统这事就不好控制，余量还是大点稳妥，另一方面，CPU指令周期多少，有没有流水，有没有并行，什么体系结构，有没有专用指令（看人家DSP多牛，干这事一绝），对外部存储器和外设的存取速度等等，哪一个慢了都叫瓶颈。

(5) 需要的硬件支持（如外部存储器，双电源等）这算是杂项，但会增加额外的价格，系统体积等，不容忽视。

从开发者的角度考虑：(1) 是否有足够的技术支持包括demo版及原理图，demo程序，操作系统和BSP，测试开发工具等。

(2) 自身条件;包括对项目开发周期的要求，开发人员对器件和开发模式的熟悉程度以及掌握的难易程度。

(3) 可用资源是否丰富（书籍，网络等）以上三点主要考虑迅速开发出稳定的系统。

(4) 系统的可继承性，可移植性和可扩展性。

(5) 是否有现货。

(6) 方案提供商的素质。

（包括技术水平和服务意识）。

根据以上考虑选择了s3c4510b（ARM7TDMI）＋uClinux开发模式(1) 以下是该平台对我的系统的满足情况：（和上面几点对应）本监控系统硬件部分主要要求以下部分：a．以太网接口（s3c4510b自带网络控制器）b．串口（自带）c．与数据采集芯片的接口（8位数据线，小于8位地址总线）。

（自带）本系统软件部分主要要求以下部分：a．硬件接口驱动程序（uClinux提供串口和网络控制器驱动）b．网络协议栈支持（uClinux提供TCPIP，UDP等的协议栈）c．应用层程序（如果算上可以从linux移植的程序来看，那就太多了，我就用到了一个现成的）(2) 本应用系统不是那种批量的东西，对价格要求不苛刻，而且这款CPU最便宜可以到55左右,可以接受。

(3) 本应用系统有固定电源，功耗要求不高。

当然，据说ARM在节省功耗上很有特点。

(4) 本应用系统速度方面要满足两方面：1。

串口：115200bps 2。

网络速度能到10Mbps 就行，所以对系统速度要求也不高。

这款ARM内部可以到50M。

(5) 系统对体积要求也不高，加片flash和RAM还是没问题（到目前为止感觉我的系统真是无欲无求！）从开发者的角度考虑：(1) 因为时间很紧（一个半月），所以支持越多越好。

目前从开发商那里拿到了开发板，原理图，uClinux，相应驱动，bootloader，拿来就可以用了。

软件硬件并行开发。

（bootloader 和网络控制器驱动没提供原码，比较可惜：－（(2) 当时我对嵌入式系统的开发模式和ARM都是只有耳闻，linux接触过一个月左右。

现在想起来有些后怕。

(3) 网上的资源，非常多。

提供一些我常用的。

::URL::/ uClinux的大本营。

::URL::/ 里面有些技术文章非常不错。

::URL::/::URL::/ 这是国产的linux站点。

uClinux-dev@ 这是uClinux的邮件列表，回答问题的都是大牛，非常有帮助，记住把你的邮件设置成纯文本格式。

申请是在：::URL::/mailman/listinfo/uClinux-dev web方式。

(4) 采用以上开发模式，软件的可维护性，可移植性和可扩展性都不错。

(5) 目前该CPU使用还是比较普遍，现货没问题。

(6) 方案提供商的素质吗……..还算可以吧:-)根据以上考虑和目前的开发情况，这套方案还是比较令人满意。

2．开发环境的建立。

先说两句废话为和我以前一样对操作系统（尤其是嵌入式操作系统）迷惑的弟兄解释些概念。

因为总是有人在问是不是一定要用操作系统，我的CPU能不能移植操作系统，可以移植什么操作系统，有了操作系统可不可以运行某些程序。

从我的个人经历来讲，这其实就是许多硬件出身的弟兄对操作系统这个东西有神秘感（和我一年前一样）。

说白了，操作系统就是一段设计非常巧妙的程序，和你自己的程序从本质讲没有区别，于是，以上问题转为，我是不是一定要用这段程序，我的CPU能不能运行这段程序，可以跑什么样的程序。

这个程序可以跑，调用这个程序接口的另一个程序能不能跑！答案也就变得简单，操作系统对任何一个CPU都不是必须的（对嵌入式系统更是如此），你可以自己编些程序在没有操作系统的PC裸机上跑（BIOS就是这样的），像玩C51一样，（虽然奢侈的让人有些心痛），或者移植UCOS到上面。

另一方面，现代操作系统大多需要一些硬件的支持，（像保护模式的实现），反过来说，高端CPU中专门有针对支持操作系统的体系结构，这样，许多操作系统的实现是挑剔硬件平台的。

其实其它程序也一样，你编的程序使用的片上外设另一CPU上没有，那这段程序就无法移植了。

这就是话粗理不粗。

书归正传，还是聊聊ARM＋uClinux开发模式下开发环境的建立（其实下面说到的东西不仅限于这种硬件平台和操作系统）很久以前就在介绍嵌入式系统开发的书上见过“交叉编译环境”这词，当时觉得很玄，用了以后才知道，其实就是解决在谁的地盘上用谁的工具编谁的代码问题。

编译的最主要的工作就在将你的程序转化成运行该程序的CPU所能识别的机器代码，不同的CPU有相应的编译器，另一方面。

编译器本身也是程序，当然也要在某一个CPU平台上运行。

于是交叉编译的交叉点就在那个编译器本身是CPU1上的一个程序，却在为CPU2编译代码（整个一个吃里扒外！）。

这么一想，以前用51和dsp的开发软件（大部分都是IDE－集成开发环境）开发程序时，都算是交叉编译啦。

当然，假如在你的ARM系统上，操作系统已经正常运行，并且你的资源足够多，你可以把PC机上运行的ARM编译工具移植到ARM上，然后所有该系统的应用程序都直接在ARM系统上编译，这就不算交叉编译，但如果有条件这么作，程序的开发或者移植就方便多了，因为整个开发过程又回到在自己PC机上编应用程序的那种模式了，那就是在自己的地盘上用自己的编译器编自己的应用程序。

与不使用操作系统的开发模式不同（此处的操作系统尤其指提供了专门的接口函数库的操作系统，目前的UCOS就不算），在目标板（就是实现系统的板子）使用操作系统的开发模式下，交叉编译环境中还需要该对应该操作系统的库。

比如uClinux提供的uClibc。

此时，开发用的主机上不光要有目标板CPU所需的编译工具，还要有对应操作系统的库，又因为一般库文件还要在开发机上拿目标CPU的编译器重新编译一下，所以还要把操作系统的原码也放到开发机上(或者把相应的库文件放到开发机上？)。

（唉，跟目标板没什么关系，却要帮它背这么多东西，真是上辈子欠它的！！）。

虽然操作系统的接口库至关重要，但大家似乎已经淡忘了它的存在。

这些多是因为大家已经远离了刀耕火种的年代（需要告诉编译器需要的include路径，lib路径，以及lib的名称），集成的编译环境让我们编译链接的所有繁琐工作化作对BUILD按钮的潇洒一击。

而且不论是windows环境，还是linux环境，都有环境变量去记录这些参数。

但尝试将/usr/lib目录改一个名字，你就会知道你不能无视他们的存在，因为操作系统的功能都是通过这些库来交给应用层程序使用的。

当然如果你的系统不依靠任何操作系统，像最原始的那种完全自己实现所有代码，就只需要一个编译工具，少了这些罗嗦事。

以上的东西一般时候是没有必要仔细研究，但交叉环境下开发或移植比较大的程序时，你可能就需要了解编译器，链接器等开发工具的几乎所有重要参数。

我在开发时，主机完全使用的是linux，如果有条件，建议大家这样作，linux的使用没有想象的复杂（虽然我现在身边还要放一本关于linux使用的书籍），而且开发程序可以先在主机上调通，然后用交叉编译工具为目标系统重新编译一遍，可以这样做是因为主机是linux，目标系统跑uClinux，两个操作系统提供的应用程序接口几乎是一样的，所以程序几乎不用修改。

在我的系统上，建立基本的开发环境过程如下。

(1) 安装gnu开发工具链（是GNU开发的针对ARM CPU的一组编译开发程序（是linux程序）。

包括arm－elf－gcc，arm－elf－ld等(2) 将uClinux源代码源代码解压到相应路径下，按照编译内核的步鄹编译一遍（此时使用的编译工具已经是上面提到的ARM编译工具了，因为它要在ARM CPU上运行，另外，和编译linux内核一样，此时可以通过menuconfig来对内核提供的功能进行裁减(3) 将库（uClibc）解压到相应路径下，用以上工具编译一遍。

这样最基本的环境就算搭建好了。

以上工作对于做过的人来说比较简单，这里介绍一下帮助没有使用或刚开始使用这种开发模式的弟兄们理清一下思路。

3．应用程序的开发因为目标板上用uClinux，它提供的程序接口和linux下的基本一致，不一致的部分主要在于uClinux不支持MMU（应该说是uClinux是为不带MMU的cpu定制的），最明显的就是fork 函数要用vfork函数替代，这也是编程时，感觉最不爽的一点(没办法，谁让咱们的CPU有生理缺陷)。

另一个不易觉察的差异在于uClinux提供的库uClibc是经过裁减的。

更适合于资源紧张的嵌入式系统（上回分解已经说了，应用程序很大一部分是在和库函数打交道，而且大家最终是链在一起，所以库函数大了，你的程序也小不了）。

于是基于这种开发模式的应用程序开发变成了linux下的程序开发。

而且在实际中一般是编好了程序先在主机上拿主机平台上的编译器编译并且调试一下（linux下的编译器就是gcc 了），当然前提是被调试的程序中需要的硬件条件主机具备，例如我的程序中有一段是针对串口的，于是先在主机编一个串口程序，调通以后拿目标板的编译器重新编译一下（例如arm-elf-gcc？）（如果看了上一章“交叉编译环境”，这里就不会晕了），下载到目标板上运行，一般来说就可以直接用了。