返回工控網首頁
中國自動化學會專家谘詢工作委員會指定宣傳媒體
免費注冊 中華工控網 廣告服務 | 客服中心
xmz
新聞詳情

幾種Linux下嵌入式開發環境的簡單介紹

http://www.kadhoai.com.cn 2026-04-07 13:26:55

   做Linux嵌qian入ru式shi係xi統tong的de對dui常chang見jian的de幾ji種zhong嵌qian入ru式shi開kai發fa環huan境jing一yi定ding不bu會hui默mo生sheng，由you於yu主zhu要yao接jie觸chu網wang絡luo相xiang關guan產chan品pin的de一yi些xie係xi統tong設she計ji，因yin此ci，將jiang可ke能neng用yong到dao的de嵌qian入ru式shi開kai發fa環huan境jing簡jian要yao總zong結jie一yi下xia。主zhu要yao涉she及下麵的幾個東東：
   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萬wan個ge軟ruan件jian以yi外wai嗎ma？沒mei有you，那na麼me恭gong喜xi你ni，明ming天tian就jiu可ke以yi給gei老lao板ban交jiao工gong了le。當dang然ran，對dui於yu特te定ding的de軟ruan件jian，可ke能neng還hai是shi需xu要yao從cong源yuan碼ma來lai構gou建jian，不bu過guo同tong樣yang的de，我wo們men可ke以yi將jiang其qi生sheng成chengDeb包，然後將配置加到emDebian工具集中，同其它所有軟件一樣的選取和配置。
   emDebian的發展似乎不是想像的那麼好，現在主頁上的新聞更新還是去2004年的。
buildroot
   emDebian實際上並不一定適合於資源非常緊缺的超小型係統，比如隻有2M Flash的小型控製係統。另外發行版的軟件通常會以通用代碼來編譯，例如，為了盡可能在各種X86平台上都能夠安裝，大多數發行版通常會以i686甚至 i386代碼集來編譯軟件，可以使文件的通用性很強，但CPU的性能卻不能發恢到最好（這就是為什麼有時會看到一些廠商或愛好者發布PIII、PIV、 athlon等優化係統的原因），zheduiyuqianrushixitonglaishuoyebuhuishiyijianhaoshiqing。lingwai，meiyouyuanmadekongzhiquan，yixiexuyaodingzhidedongxiyehuibiandenanyishixian，yinci，congyuanmakaishigoujianrengranyoubiyao。
   嵌入式Linux開發中使用的CPU速度往往向對不會太高，因此，盡可能提高代碼的性能就非常必要。通常開發人員應該對該CPU的具體型號有一定的了解，以便啟用編譯器中對該型號的優化，以ARM為例，我們可以通過 -march=armv5te 和 -mtune=arm9tdmi 來對代碼在ARM9上的運行進行優化。有時這些優化體現出來的性能改善是比較大的，我曾對比過一些複雜算法的代碼優化前後的性能（執行速度），都有一定的提升。另外在PIV上測試過以i686和pentium4對一個語音編碼算法進行優化，運算速度居然提高了幾倍。
   這種幅度的提升可能隻是一個特例，這個算法有大量的複雜浮點運算，使用i386或 i686指令集和使用更先進的PIVzhilingjibianyichulaidejiqidaimaduiyutongyigeyunsuandejieshikenengcaiyongwanquanbutongdezhilinglaiwancheng，yincixingnengtishengjiaodajiubuzuweiqile。tongyangzhezhongdaima，zaiARM上通過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/binutilsdeng，danggongjulianbianyiwanchenghou，duimubiaoxitongxuyaodeyuanmadebianyiguochengyuzhujixitongdekaifagongjujijibenshangjiumeiyoushenmeguanxile。yinci，butongdezhujiruguonenggoutongguodiyibu，bianyiwanchenggongjulian，namebianyichulaidemubiaoxitongdezhixingdaimajiukeyijihubucunzaiyouyuxitongyinqidechayi。zheyang，kaifarenyuanjiukenengzaigezixihuandeLinux發行版上進行開發，而不必擔心出現什麼兼容性問題。
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 找到。
   uClinux之前僅是核心的一些補丁，後來發展成為一個包括核心、庫、應用程序、工具和編譯相關的配置文件的一個集成開發環境。與 buildroot不同的是，uClinux不編譯目標係統的工具集，也就是說，相應的編譯工具應該提前安裝好。如，對於arm來說，需要先安裝ARM交叉編譯器。uClinux的編譯器也需要一些補丁，其中比較重要的兩個方麵主要包括：
   用於生成FLT文件的補丁：由於MMU的關係，uClinux不支持ELF可執行文件，這個補丁主要包括bin2flt工具包和一個ld的wrapper腳本等，用於(透明於用戶)生成FLT文件；
用於支持XIP(Execute In Place)的補丁：這個補丁需要對gcc進行一些小的修改；支持XIP主要是為了解決小內存環境中運行的問題。
   XIP不一定適用於每種應用環境，對於內在要求特別嚴格的係統來說（空間第一位，如手機要求使用片內RAM），可以通過將核心和應用程序編譯為XIP支持，然後直接在Flash上運行，內存僅用於運行時數據；而對於性能要求為主的係統（如高速網絡處理器），則不能因為節省一點空間而使用XIP將程序直接在Flash上運行，這樣可能會降低指令的讀取速度而影響係統性能（但仍然可以使用 XIP，使程序的多個實例在內存中共享代碼空間，以後詳細說）； + FLT可執行文件支持動態鏈接庫(目前僅m68k支持，參見 uCdot: Shared libraries under uClinux mini-HOWTO)的補丁；
   uClinux的編譯過程大致是，首先，通過可視配置界麵（menuconfig/xconfig）選取Vendor和board（實際上是選擇了一些配置文件和產品相關的文件），然後根據選擇構造一個適用於target的開發環境，如生成頭文件和需要的庫文件（uClibc、glibc或uC-libc 以及其它一些庫），然後編譯核心、庫、應用程序，最後將所有的輸出安裝到romfs目錄中，根據需要生成目標平台需要的映像文件（如： romfs.img、linux.bin、rootfs.gz等）
   由於一些過程細節被隱藏起來，uClinux現在的編譯過程方便到隻需要配置一下(make menuconfig)，然後 make 就可以直接獲得最終輸出。不過這反倒成為一些初學者學習的一個麻煩，本文完成後，根據對本文的反饋，將進一步對uClinux進行詳細介紹。
   總的來說，目前的uClinux是一套主要用於無MMU核（但不限於此）的嵌入式Linux集成環境，也是一個非常好的 Linux from scratch 的示例。拋開其MMU相關的補丁，uClinux也可以作為一套用於包含MMU係統的集成開發環境，Snapgear 就是一個很好的例子。實際上，我們可以從官方的uClinux源碼就可以直接編譯一個支運行於X86的uClinux。
Scratchbox
   Scratchbox 的故事要從buildroot講起（這不一定是scratchbox開發者的故事，隻是依據我個人的認識）。buildroot可(ke)以(yi)從(cong)頭(tou)開(kai)始(shi)，先(xian)構(gou)造(zao)編(bian)譯(yi)器(qi)和(he)基(ji)本(ben)開(kai)發(fa)環(huan)境(jing)，然(ran)後(hou)根(gen)據(ju)用(yong)戶(hu)配(pei)配(pei)置(zhi)構(gou)造(zao)一(yi)個(ge)適(shi)用(yong)於(yu)目(mu)標(biao)平(ping)台(tai)的(de)根(gen)文(wen)件(jian)係(xi)統(tong)。這(zhe)個(ge)文(wen)件(jian)係(xi)統(tong)可(ke)以(yi)有(you)許(xu)多(duo)用(yong)法(fa)，例(li)如(ru)，做(zuo)為(wei)initrd或通過NFS輸出給目標係統使用。為了減少交叉編譯軟件帶來的麻煩，可以配置buidroot創建一套目標係統的編譯環境（Gcc、binutils、lib等），這樣用戶可以通過這個基本文係統在目標係統上直接本地編譯軟件。如果目標係統性能足夠的話，buildrootderenwudaocijiujibenjieshule。duiyuqianrushixitongdekaifazhelaishuo，zaimubiaoxitongshangzhijiebianyidaimaquebuyidingdounenggoushixian，yinweiduoshuqingkuangxia，womendemubiaopingtaichuliqixingnengbingbuhuinamegao，zheyang，womenjiubudebumianduiyigeliangnandexuanze： 繼續通過buildroot編譯其它的軟件，性能會高許多，但每個軟件都需要進行交叉編譯相關的改造；
   在目標平台上編譯軟件，對於隻有幾十或幾百兆的低性能核來說，編譯一個核心可能會讓你等上半天的時間；
   有沒有好的辦法解決性能和交叉編譯的問題呢？先分析一下通過buildroot交叉編譯不能解決的問題。Buildroot隻zhi在zai一yi定ding程cheng度du上shang對dui目mu標biao平ping台tai進jin行xing了le模mo擬ni，但dan仍reng有you一yi些xie是shi無wu法fa實shi現xian的de，例li如ru，當dang目mu標biao平ping台tai不bu同tong於yu主zhu機ji平ping台tai時shi，不bu能neng生sheng成cheng並bing運yun行xing目mu標biao平ping台tai的de中zhong間jian代dai碼ma。這zhe樣yang，許xu多duo通tong過guoautotools （autoconf/automake）配置的軟件就可能會出現問題。例如，configure 腳本有時會生成一些中間代碼，並試圖運行以確認開發環境中是否存在某個庫文件或頭文件，對於在X86上編譯基於uClibc X86目標平台代碼可能不會出現問題，但如果目標平台是X86以外的平台，編譯就可能會中斷；又如，configure腳本確認編譯器是否工作，會試圖編譯一個包含空的主程序的代碼並運行，實際一個可運行於目標平台的 a.out 確實生成了，也可以正常運行於目標平台，但是這個測試會因為 a.out 被運行在主機係統上而錯誤的中斷。這些問題一些被 buildroot 通過補丁或複雜的 configure 參數解決了，某些中間執行文件，則通過HOSTCC（主機上的CC）來生成並運行以生成最終文件。目前buildroot包含的軟件或多或少都會有一些這樣的補丁，而且開發者一旦深入到對軟件的定製，就會不停的被這些問題所困擾。
   Scratchbox相比於buildroot有幾方麵的改進：
   運行於 chroot 的環境，完全獨立於主機，編譯過程將基本與主機係統無關（並且scratchbox修改了一些庫，使得普通用戶可以chroot到編譯環境中，並且多個用戶可以同時使用一套Scratchbox開發套件和完全獨立的用戶資源）；
   透過qemu模擬運行或sbrsh解決中間執行文件或類似configure測試文件運行的問題；
對(chroot後)的係統進行修定，達到足以欺騙大多數軟件的效果，這並不是指的讓軟件可以不進行改造就可以 交叉 編譯，而是使軟件 誤認為 這就是在目標平台上編譯；
   不過 Scratchbox 目前還隻能編譯 ARM 和 x86 的代碼，不能支持 buildroot 所支持的 ppc、mips等。
   本文不詳述每一種環境，因此各個軟件都隻是點到為止(雖然可以講得更詳細一些，但這些內容還是獨立出來比較好一些），不過這裏還是引入一個很簡單的示例，根據 scratchbox 網站上的文檔，安裝完成後，進行簡單配置就可以使用了（Debian用戶的安裝可以更簡單，因為該站提供Deb包，直接apt-get就行了）。通過 /scratchbox/login 登入開發環境，通過sb-menu配置一個基於 ARM 的環境（其中 Select CPU-transparency method 選qemu不要先sbrsh），然後寫一個 helloword.c，編譯並運行之。 通過ldd可以看到，在沒有任可改動的情況下，順利的生成了ARM ELF，但在 scratchbox 裏卻可以在X86的主機上正常的運行！ 

[sbox-redice: ~] > gcc -o hello hello.c

[sbox-redice: ~] > file hellohello: 

ELF 32-bit LSB executable, ARM, version 1 (ARM),

 for GNU/Linux 2.0.0,dynamically linked (uses shared libs),

 not stripped[sbox-redice: ~] > 

./hellohelo world![sbox-redice: ~] >
相關新聞
編輯精選
工控原創
版權所有 工控網 Copyright©2026 Gkong.com, All Rights Reserved