讲嵌入式移植的一篇常好的文章.docVIP

（讲嵌入式移植的一篇非常好的文章，原文出自《基于arm+uClinux的嵌入式系统的开发》,这是节选了其中讲移植的这一段）不同平台间程序的移植--简单程序的移植研究程序移植的那两周是最痛苦的两周，没有太多可以借鉴的东西，只能摸黑向前走，于是更加坚定决心要整理些东西给后来的弟兄。不过话说回来，各位弟兄别被我前面说的吓倒，只要搞清你要作什么，程序移植其实是比较简单的事情。 首先列出一些问题： (1) X86上运行的程序能不能在51单片机上运行，为什么，有没有可能，如果可以，应该做哪些工作才可以实现。 (2) 相同CPU平台，DOS的程序为什么可以在windows下运行，能不能在linux下运行，为什么，作什么工作可能实现。 为什么可以移植程序，为什么要移植程序? 程序可以移植首先要感谢开发出高级语言的大牛们，记住，无论多么漂亮的代码经过编译以后都要变成CPU可以识别的机器语言，而几乎一千种CPU说着一千种语言。为保证大家有共同语言，规定一种高级语言――高级语言。每一个CPU派出自己的翻译――编译器。这个翻译精通两国语言，高级语言和自己的语言。（由此已经可以看出编译工具在程序移植中的重要性）。只要程序没有硬件上的约束，可以说这种沟通是无极限的，甚至于不同操作系统平台。（操作系统也是程序，也可以移植喽）举例：在x86的windows下用VC（或TC，BC）编一个c程序实现i=i+1，丝毫不改就可以用51的C编译器重新编译并在51单片机上运行。一次小型的移植就结束了。可以移植已有的程序还要感谢开放源代码的弟兄，没有这些C文件和H文件让你重新编译一下，怎么在你的CPU上跑？其实不止这些，后面还会看见开源组织的牛人专为程序可移植性所作的专门的工作。 那么为什么要移植程序？ 问这问题就像问地上有个钱包为什么要捡一样，答案不言而喻。现成的东西为什么不要。当然，移植程序可没有捡钱包那么简单，尤其是第一次，后面会说一些移植之前应该考虑的问题。（就像现在地上有个钱包也千万别上去就揣自己兜里，说不定就是套）。另一方面，你给我你写好的程序让我拿去用，我还要考虑一下，或许里头问题多的还不如自己写一个。我这里所说的可移植的程序应该是维护比较好，比较成熟的源代码（像我后面的所说的UCD－SNMP），目前的开放源代码运动决不仅仅是把自己的程序公开就行了，而是有了一套成熟完整的版本控制，BUG报告和PATCH提交流程。 这样的代码才有更大的使用价值。 什么时候可以考虑移植程序？ 在基于嵌入式操作系统进行开发时，具有一定规模的程序都可以到网上查一查都没有成熟的源代码可用。前面已经说到，程序的移植最终只针对CPU，其实和操作系统没什么关系，但另一方面，因为代码中可能会使用一些库函数，这些库会包括C语言标准库和操作系统提供的API（应用程序接口）库。假设源代码中只包括C标准库，那么该程序就可以跨操作系统去移植。例如hello world程序中使用了printf，因为该函数是C标准函数，所以在X86上使用TC（BC或VC）可以直接编译运行，在ARM＋uClinux平台下也一样，但如果程序中调用了vfork函数，那么只有 linux一脉相承的操作系统支持这种特殊服务了，在window或dos操作系统下无法直接编译该程序了。只能找该操作系统支持的类似的功能来实现。再进一步，硬件上的生理缺陷也会为移植带来麻烦，S3C4510B不支持MMU，在其上运行的uClinux也不提供和MMU有关的服务（其实 uClinux本身可以支持MMU），于是在移植前相关的函数（比如FORK）都要被替代掉（使用VFORK）。好在uClinux和linux提供的应用接口大部分还是相同的。所以这样的工作还可以承受。 由上可知，如果是在各种嵌入式linux（除了uClinux以外，还有好几种）平台上开发，那么针对该平台以及linux平台上的源代码都可以使用，但是要牢记他们之间的差异。在我的系统中需要实现网络监控，所以想使用snmp协议，该协议和http，ftp一样属于应用层的成熟协议，专用于网络管理。目前已经有一些针对该协议成熟的代码，最有名的是ucd－snmp，不光软件本身功能强大，可移植性也比较好，在linux，unix等平台上都可以移植，于是决定将它移植到ARM＋uClinux平台上（别看现在说的这么轻松，当时接这活时都有点哆嗦）。 简单总结一下，移植应用程序的前提是有源代码，移植的关键工具是编译器，源代码中和硬件平台相关的东西越少越好（这里主要指使用了汇编，或做了针对自己平台的事，比如将指针指向特定地址然后操作），另一方面，如果该程序是基于某个操作系统（利用了操作系统提供的特殊服务，即API），要看自己的操作系统是否提供了相关服务。 下面简单列出一些我认为移植时需要考