新闻中心

EEPW首页 > 嵌入式系统 > 设计应用 > ARM/uClinux应用程序的开发

ARM/uClinux应用程序的开发

作者:时间:2012-11-16来源:网络收藏
  的开发

  因为目标板上用,它提供的程序接口和linux下的基本一致,不一致的部分主要在于不支持MMU(应该说是是为不带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招你惹你了,你老贬它。其实不然,首先以上说的东西一般在IDE的project菜单下的option或build option中找到,只是一般不用管罢了。另一个方面,IDE就像是傻瓜照相机,很多工作他都帮你完成了,使用简单。但如果要做摄影师的话,你就少不了要对每一个细节都了解。其实编译程序也是一样。(你可以对优化,警告级,宏定义等诸多选项进行自己的选择)。以下是几个主要步鄹:(以下有些我也不确认,如发现问题,请及时纠正。

  (1) 预编译。 主要工作就是处理所有#开头的,包括头文件。以前搞不清头文件和可执行文件有没有什么联系(因为总看见两个文件名字取一样的),现在知道,他们之间没有任何联系。在预编译结束后,头文件的使命就结束了。在下一次介绍不同平台程序移植时可以看到,预编译有时非常有用。

  (2) 编译。编译应该是最主要的一步,就是将源文件生成CPU能识别的语言,一般是 后缀为.o的目标文件,应该说,此时的文件就已经可以执行了。当然这个时候外部函数等外部符号都没有引入,对于被编译程序来说,这些外部符号还只是留一个倩影,压根儿不知它在不在。你可以在你的程序里调用一个不存在的函数,甚至都不用声明,在编译阶段,很多编译器只是给个警告。只有在链接时才会报错。(呵呵,够弱智!)

  (3) 链接:链接才是清帐的时候,以前在程序里用到的外部符号都要把真正的东西交出来。你可以指定需要连接在一起的目标文件,也可以告诉编译器库文件的名字和路径(指定方法下次讲)。编译器会去找,需要注意的是,库的指定需要注意顺序。首先,如果不同的库里有同名函数,并且该函数被调用,那么在前面的就被链接进去了,这一点对于头文件路径的指定也适用,如果你自己的头文件和系统头文件相同,并且你的头文件路径在系统头文件路径前面,你的头文件就会代替头文件。库文件是由相应的程序(linux下是ar命令)将需要被添加到库里的目标文件(该文件是编译阶段生成的)组织起来生成档案文件,同时可以建立一个检索,检索内容为所包含的目标文件中定义的符号。也就是说,库文件并不是必须的,但它为经常使用的目标文件中的函数提供了快速的检索机制。
以上就是主要的步鄹,当然除此之外,还有一些用于格式转换的工具等。不一一介绍。知道编译器的细节对于程序的开发和移植都是很有好处的。
 
  程序开发过程中调试也是至关重要,因为可以先在主机上调试,所以可以使用linux下的gdb,(有点像dos 下的debug)。但是只是用到了皮毛,还有一个专用于宿主机模式的调试工具gdbserver,一直没时间研究,希望用过的大侠多发些文章铺路。
另外还会遇到如何作ramdisk,如何让系统启动自己的程序,这些都太linux了,没接触过linux的人会晕,为了大家的健康,就不讲了,遇到问题可以给我email,大家一起讨论。

  4.不同平台间程序的移植--简单程序的移植

  研究程序移植的那两周是最痛苦的两周,没有太多可以借鉴的东西,只能摸黑向前走,于是更加坚定决心要整理些东西给后来的弟兄。不过话说回来,各位弟兄别被我前面说的吓倒,只要搞清你要作什么,程序移植其实是比较简单的事情。
首先列出一些问题:

  (1) X86上运行的程序能不能在51单片机上运行,为什么,有没有可能,如果可以,应该做哪些工作才可以实现。

  (2) 相同CPU平台,DOS的程序为什么可以在windows下运行,能不能在linux下运行,为什么,作什么工作可能实现。

  为什么可以移植程序,为什么要移植程序?

  程序可以移植首先要感谢开发出高级语言的大牛们,记住,无论多么漂亮的代码经过编译以后都要变成CPU可以识别的机器语言,而几乎一千种CPU说着一千种语言。为保证大家有共同语言,规定一种高级语言――高级语言。每一个CPU派出自己的翻译――编译器。这个翻译精通两国语言,高级语言和自己的语言。(由此已经可以看出编译工具在程序移植中的重要性)。只要程序没有硬件上的约束,可以说这种沟通是无极限的,甚至于不同操作系统平台。(操作系统也是程序,也可以移植喽)举例:在x86的windows下用VC(或TC,BC)编一个c程序实现i=i+1,丝毫不改就可以用51的C编译器重新编译并在51单片机上运行。一次小型的移植就结束了。


上一页 1 2 下一页

关键词: ARM uClinux 应用程序

评论


相关推荐

技术专区

关闭