ARM/uClinux应用程序的开发

　　因为目标板上用uClinux，它提供的程序接口和linux下的基本一致，不一致的部分主要在于uClinux不支持MMU（应该说是uClinux是为不带MMU的cpu定制的），最明显的就是fork函数要用vfork函数替代，这也是编程时，感觉最不爽的一点(没办法，谁让咱们的CPU有生理缺陷)。另一个不易觉察的差异在于uClinux提供的库uClibc是经过裁减的。更适合于资源紧张的嵌入式系统（上回分解已经说了，应用程序很大一部分是在和库函数打交道，而且大家最终是链在一起，所以库函数大了，你的程序也小不了）。

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

　　以上也是为什么我认为开发嵌入式linux程序主机应该选用linux环境。对于以前没用过linux的人来说（比如我），开发程序前应该花3，4天时间熟悉linux环境，尤其是它的编辑器，用惯集成编译环境的人有时连编译器和编辑器的概念都模糊了，所以一般是直接进入集成编译环境，连写带编一气呵成，殊不知有些集成编译器提供的编辑器弱智的一塌胡涂，如果用熟了linux下的emacs，你就会发现他们之间的差距大概……要像我和盖茨那么大吧。所以编程序时应该选一款优秀的编辑器，linux下，我当然选emacs，虽然刚看见它的感觉是外表丑陋，使用复杂。但只要多用多练，对提高效率很有帮助。（将你的程序用两个编辑器完成，一半是用emacs的，一半是不用emacs的，看看效果：－）
对具体的linux编程我就不板门弄斧了，需要提个醒的是咱硬件出身的人作软件应该养成良好的编程习惯，别让作软件的笑话咱。因为作了些网络应用，所以介绍一些网络编程时要用到的网站和书籍;

　　>w.Richard.Stevens. 这可是linux网络编程的圣经级的书籍

　　http://www.fanqiang.com/a4/b7/ 适合于网络编程的入门。

　　还有IBM中国上关于linux的教程和文章，都是翻译过来的，有很多写非常不错。

　　其实类似的资源不计其数，遇到问题时应该先到google上狂搜一圈。

　　重点想说些关于编译器的东西，不了解它，在交叉编译环境下编译程序就寸步难行了，这无非是因为交叉编译环境下目标板编译器所处的寄人篱下的悲惨环境。想想在linux下将myprogram.c编译链接成应用程序myprogram，最简单的一句gcc –o myprogram myprogram.c 就可以了。（其实在诸如VC下你也可以找到类似的命令，集成开发环境只不过替你来调用它了）。一切看起来天经地义。

但试着把/usr/include路径改一个名字（比如改成stupid_include），再这样编译一下，会发现程序中被 >引用的头文件（比如#include）都找不到了。因为编译器看见这样的头文件会到系统指定的路径下寻找，而这个路径是由环境变量保存的（linux和windows下都是这样的）。针对以上情况，不将路径名字改回去，但是给编译器加一个参数如下：

　　gcc –I/usr/stupid_include –o myprogram myprogram.c 会发现错误信息没了，一切又恢复了往日的宁静，顿时明白，不用环境变量，通过参数，同样可以将这些信息告诉编译器。 返回来说说你的目标编译器，虽然占用了人家的地盘，编译器，头文件，库文件，一个都不少，但你要编一个程序编译器照样发晕，因为没有环境变量告诉它自己需要的头文件和库文件在哪里。看来只有两种办法，一个是抢占了主机的环境变量改成自己的（整个儿一个土匪）,或者在编译时加上必要参数（还是这样绅士一些），告诉编译器需要的文件的位置。（除此之外，还有其他一些参数也是如此）。

　　从源程序到可执行文件根据情况不同可能分好几步，一般每一步可能都会有一个应用程序实现，像gnu提供的arm开发工具链其实就是这么一组程序。提供从编译到链接到格式转化的全套服务。你可以用arm－elf－gcc命令一步到底直接产生可执行文件（其实也是在自己的任务完成后调用下一个程序），也可以每一步加上自己的参数，只作自己的事。

编译器的主要参数的使用下次将程序的移植时再讲。这里想说一下编译器产生应用程序的几个主要步鄹，讲这个问题的原因还是很多人无法区分诸如编译和链接，不用问，这一切还是IDE集成开发环境惹的祸。有人会说，IDE招你惹你了，你老贬它