開發板主板交叉編譯

Ⅰ 無線遠程監控系統的實現方式

採用單片機是大多數嵌入式系統設計時的首選方案。由於在片上集成有豐富的外設，具有良好的控制能力，單片機天生就是為嵌放式系統度身定做的，在嵌入式市場上占據了最大的份額。
基於單片機的設計方案一般適用於對數據處理要求不高，運算量不大的遠程監控系統。根據需要，單片機可以選用較為低端的4位機或8位機，如8051等，也可選用功能較強的專用晶元，如MSP430FE42X系列。單片機主要用於監測站端的系統控制。片外存儲器一般為RAM、EEPROM和Flash等存儲器；I/O設備一般為鍵盤、LCD等供設計調試用的人機交互介面；感測器一般為話筒、攝像頭、揚聲器和伺服馬達一類的設備。無線通信介面實現相對較為復雜。編解碼器是可取捨的，對於低速率數據一般沒有必要。根據系統的處理任務和信息的類別，編解碼器可選用不同的芯生， 如CMX639（用於音頻）或LD9320等，也可用編程邏輯器件實現。監測站軟體可直接通過C或匯編語言實現，也可在實時操作系統上開發應用軟體。對於低檔的4位或8位單片機，控制能力較低，系統簡單，一般採用直接編寫控製程序的方法。對於功能較強大，各設備間交互復雜的系統而言，大多數是利用操作系統來進行任務管理、設備交互，應用軟體只是完成上層的數據處理等工作。 眾所周知，DSP的數字處理方面能力較強，技術已經很成熟，能處理各種運算的通用、專用晶元也很多。以DSP為核心設計開發的監測站，可以完成高速率數據處理，保證系統實時性方面的要求。
這類設計方案一般適用於數據處理運算量比較大，實時性要求高而對控制能力要求相對較低的監控系統。與以單片機為基礎的監控系統不同的是，DSP除了作控制器以外，還可兼作數據計算、編/解碼之用。對於較復雜的編/解碼以及壓縮解壓運算（比如對圖像視頻數據的處理等）是否仍由DSP完成，須綜合考慮。若DSP在系統控制和實現傳輸協議方面負擔太重，則這部分運算需要由專門的處理晶元完成；若系統控制和傳輸協議較簡單，或根本沒有到上層協議棧，則這部分復雜的運算可由DSP完成。 顯然，這種設計方式吸取了單片機和DSP各自的優點：單片機的特點決定其擅長於控制，DSP的內部結構保證較強的數據處理能力。兩者的組合可實現一些相當復雜的系統功能，但由於系統中採用了兩個處理器，其間的信息交互是設計這類監測站時須著重考慮的問題。只有單片機和DSP之間較好地協同工作，才能充分發揮各自的優點；否則，由於兩者間的協調而耗費了大量資源，整體性能未必高於採用單一處理器的系統。實現單片機和DSP間通信協調的常用方法是採用雙口RAM。
有些DSP或單片機廠家為了擴大晶元的適用范圍，在原有基礎上進行擴展，相互間容入了對方的特點，使同一晶元在數據處理和控制方面同時具有較好的性能。比如Microchip公司推出的dsPIC，使客戶能方便地將單片機的功能轉移到DSP上，推出的產品有dsPIC30FXXX系列。由於DSP和MCU兩個功能模塊在同一晶元內實現，提高了系統的可靠性、降低了監測站的設計難度並節省印製板空間。這類晶元得到廣大用戶的青睞。基於MPU的設計實現方式
設計嵌入式產品的另一可選方案是採用基於微處理器的設計方式。與工業控制計算機相比，嵌入式微處理器具有體積小、重量輕、成本低、可靠性高等優點；同時，在該領域技術成熟、產品類型多、選擇空間大，滿足各種性能需求的處理器比較容易獲得。隨著採用RISC體系的高性能MPU（比如採用ARM構架的處理器晶元等）的出現，MPU在嵌入式領域中的地位經久不衰；但是，由於在設計監測站時，電路板上必須包括ROM、RAM、Flash、匯流排介面和各種外設等器件，系統的可靠性將有所下降，技術保密性差，實現難度也較大。
實時操作系統選擇和嵌入式實時軟體開發
已有的實時操作系統（RTOS）種類繁多，軟體結構各異，可適用於復雜程度不同的各種環境，包括循環查詢系統、前後台系統、實時多任務系統和多處理機系統等。具體實例有VxWorks、pSOS、QNX、Palm OS、Windows CE、lynx OS和嵌入式linux等。選擇適合監測站乃至整個無線遠程監控系統的RTOS的重要性是不言而喻的，它可能關繫到整個系統研製的成敗。選擇過程雜而又需要耐心：要了解各RTOS的特點和適用范圍，比較其間的區別，才能找到最為合適的一種。選擇比較時，需要考慮的因素主要有：
①RTOS能否支持在項目中使用的語言和微處理器；
②RTOS能否與ICE、編譯器、匯編器、連接器及源代碼調制器共同工作；
③RTOS是否支持設計中要用到的服務，如消息隊列、定時和信號量等；
④RTOS能否達到應用產品的性能需求，比如實時性需求；
⑤能否獲得產品開發時必要的組件，比如協議棧、能信服務、實時資料庫、Web服務等；
⑥RTOS是否能為公開出售的硬體提供設備驅動程序；
⑦使用RTOS是否免費；
⑧能否獲得目標代碼；
⑨獲得的技術支持有多少；
⑩對於需要授權的RTOS，授權方式是怎樣的。
嵌入式實時軟體的開發與傳統軟體的開發有許多相似之處，繼承了許多傳統軟體的開發習慣；但由於嵌入式實時軟體的功能和運行環境特殊，決定其與傳統軟體的開發有所區別。嵌入式實時軟體的開發使用交叉開發方式。所謂交叉開發是指，程序代碼的實現、編譯和連接的環境與對其進行調試和運行的環境不同。前者基於普通微機平台，後者則基於嵌入式系統的硬體平台。調試過程多是在有通信連接的宿主機與目標機的配合下進行的，開發完成後需要進行固化和固化測試。另外，開發過程還需要相應的開發工具，包括交叉編譯器、交叉調試器和一些模擬軟體。嵌入式應用系統以任務為基本執行單元，用多個並發的任務代替通用軟體的多個模塊，並定義了應用軟體任務間的介面。由於整個無線遠程監控系統的實時性能受RTOS和應用軟體的影響，所以，在軟體的需求分析階段就充分考慮其實時性要求。再加之嵌入式應用軟體對穩定性、可靠性、抗干擾等性能的要求都比較嚴格，所以嵌入式實時軟體的開發難度較大。
無線通信的設計實現 無線通信的設計相對於監測站而言較簡單，有許多現有的產品和通信系統可以利用，重點只是在於從多種實現方式中作出最優的選擇。
常用的實現方式有：利用現有的通信網路（GSM/GPRS、CDMA移動網等）和相應的無線通信產品；通過無線收發設備，如無線Modem，無線網橋等專門的無線區域網；利用收發集成晶元在監測站端實現電路板級與監控中心的無線通信。
利用現有網路實現監測站與監控中心的無線通信 現有的通信網路較多，按業務建網是3G以前通信網路的特點，無線網路也不例外。設計無線遠程監控系統可以借用的無線網路主要有：全球數字行動電話系統（GSM）、通用分組無線業務（GPRS）、採用碼分多址（CDMA）技術的移動網、蜂窩式數字分組數據（CDPD）系統。
GSM（Globem System for Mobile）是全球最主要的2G標准，能夠在低服務成本、低終端成本條件下提供較高的通信質量。就其業務而言，GSM是一個能夠提供多種業務的移動ISDN（Integrated Services Digital Network，綜合業務數字網路）。
GPRS（General Packet Packet Radio Service）在現有的GSM網路基礎上增加一些硬體設備和軟體升級，形成一個新的網路邏輯實體。它以分組交換技術為基礎，採用IP數據網路協議，提高了現有的GSM網的數據業務傳輸速率，最高可達170kb/s。GPRS把分組交換技術引入現有GSM系統，使得移動通信和數據網路合二為一，具有「極速傳送」、「永遠在線」、「價格實惠」等特點。
CDMA（Code Division Multiple Access）網路採用擴展頻譜技術，使用多種分集接收方式，使其具有容量大、通信質量好、保密性高和抗干擾能力強等特點。
CDPD（Cellular Digital Data）無線移動數據通信基於數字分組數據通信技術，以蜂窩移動通信為組網形式，是數據朎與移動通信的結合物。這種通信方式基於TCP/IP，系統結構為開放式，提供同層網路無縫連接和多協議網路服務。CDPD網路具有速度快、數據安全性高等特點，可與公用有線數據網路互聯互通，非常適合傳輸實時、突發性和在線數據。
對使監控中心與監測站間的無線通信能利用現有的網路，對於特定的無線網需用相應的接入設備。這類設備市面上有現成的產品可供選擇。接入GSM網路的通信模塊有西門子的SIEMENS TC35i，接入GPRS可用西門子的MC35GPRS模塊，接入CDMA網路的有華立H110 CDMA模塊和AnyDATA公司的CDMA Modem(DTS-800/1800)，遵循CDPD方式的無線數據機（Modem）有OmniSky和NovatelMinstrel。
利用現有的網路組建無線遠程監控系統，網路連接如圖1所示。其中無線接入模塊產品一般都提供有RS232作為外通信介面，有些天線是內置的。利用現有的網路覆蓋面廣和可漫遊等特點，使監測站和控制中心的位置不受距離的限制；但由於利用公網，安全性會有所降低。
通過專用無線收發設備建立無線區域網 這種設計實現方式結構簡單，且無須向網路運營商付費；利用專網，安全性高。無線傳輸以微波作傳輸媒體，根據調制方式的不同，可分為擴展頻譜方式和窄帶調制方式兩種。擴展頻譜方式系統的抗干擾能力和安全性高，對其它電子設備的干擾小。窄帶調制方式佔用頻帶少，頻帶利用率高；通常選擇專用頻段，需要申請；相鄰頻道間影響大，通信質量、通信可靠性無法保障。
採用專用無線收發設備建立無線區域網的拓撲結構如圖2所示。無線收發設備包括無線Modem和無線網橋等。無線Modem與監測站和控制中心之間採用RS232通信。若採用網橋為網路組建設備，網路拓撲結構將更為靈活，如圖3所示。其中在無線網兩端的有線網路是可取捨的，可以是乙太網、令牌環網或點對點網路等本地區域網。也可以城域網，甚至是網際網路，但使用公網時須考慮安全性和費用問題。
利用收發集成晶元在監測站端實現的無線通信 前兩種組網方式的一個特點是採用現有的網路系統和產品，無線通信部分不須專門開發，實現較為容易。但由於所購買的產品均是獨立器件，使整個系統特別是監測站一端結構復雜、體積龐大，往往在系統推廣時會帶來不利，且外購產品會增加系統的成本。若能將外購產品的功能與監測站集成在一起，在電路板級實現，將可以避免上述不利因素；但這會增加系統開發的難度，延長研製周期。須權衡利弊，根據項目組的開發實力和系統生命周期作最有利的選擇。
採用此方法設計監測站需要實現的部分只是圖1、2和3中的無線通信介面（可參看本文的網路版全文）。這部分的硬體實時框圖以及處理器、存儲器的關系大致如圖4所示。各個子模塊都有多種晶元可供選擇，比如射頻前端可用ML2751和RTF6900，實現調制/解調的有ML2722，擴頻、解擴可用LD9002DX2和Stel-2000A等。
控制中心的設計實現
控制中心的設計相對於監測站的設計開發來講較為簡單，硬體設計少，除了普通微機（或工作站、工控機）外，還需要網路接入設備（若無線通信採用自行設計的模塊實現，則須開發專用的無線網卡插入微機主板的預留匯流排插槽中）。控制中心的設計開發主要集中在應用軟體的設計開發上，一般是基於Windows和Unix等常用操作系統的。當前用於此類軟體開始、調試的工具較多，且功能強大，給控制中心軟體的設計帶來便利。
就軟體的實現形式而言，一般除了界面模塊外，其餘各個功能模塊均可設計成動態連接庫文件（.dll）。人機介面界面模塊可以為該無線遠程監控系統的實際應用進行定製，以滿足用戶在界面美觀、操作方便等方面的特殊要求。
採用C/C 語言在VC 開發環境下設計這樣的系統軟體涉及到的技術較多，包括內存管理、網路通信、多線程管理和資料庫編程，甚至ActiveX等。

Ⅱ 什麼是嵌入式搞嵌入式是不是等於寫代碼

隨著信息化技術的發展和數字化產品的普及，以計算機技術、晶元技術和軟體技術為核心的嵌入式系統再度成為當前研究和應用的熱點，通信、計算機、消費電子技術（3C）合一的趨勢正在逐步形成，無所不在的網路和無所不在的計算（everything connecting, everywhere computing）正在將人類帶入一個嶄新的信息社會。一、嵌入式系統 嵌入式系統是以應用為中心，以計算機技術為基礎，並且軟硬體是可裁剪的，適用於對功能、可靠性、成本、體積、功耗等有嚴格要求的專用計算機系統。嵌入式系統最典型的特點是與人們的日常生活緊密相關，任何一個普通人都可能擁有各類形形色色運用了嵌入式技術的電子產品，小到MP3、PDA等微型數字化設備，大到信息家電、智能電器、車載GIS，各種新型嵌入式設備在數量上已經遠遠超過了通用計算機。這也難怪美國著名未來學家尼葛洛龐帝在1999年1月訪華時就預言，4~5年後嵌入式智能工具將成為繼PC機和Internet之後計算機工業最偉大的發明。 1.1 歷史與現狀 雖然嵌入式系統是近幾年才開始真正風靡起來的，但事實上嵌入式這個概念卻很早就已經存在了，從上個世紀70年代單片機的出現到今天各種嵌入式微處理器、微控制器的廣泛應用，嵌入式系統少說也有了近30年的歷史。縱觀嵌入式系統的發展歷程，大致經歷了以下四個階段： 無操作系統階段 嵌入式系統最初的應用是基於單片機的，大多以可編程式控制制器的形式出現，具有監測、伺服、設備指示等功能，通常應用於各類工業控制和飛機、導彈等武器裝備中，一般沒有操作系統的支持，只能通過匯編語言對系統進行直接控制，運行結束後再清除內存。這些裝置雖然已經初步具備了嵌入式的應用特點，但僅僅只是使用8位的CPU晶元來執行一些單線程的程序，因此嚴格地說還談不上"系統"的概念。 這一階段嵌入式系統的主要特點是：系統結構和功能相對單一，處理效率較低，存儲容量較小，幾乎沒有用戶介面。由於這種嵌入式系統使用簡便、價格低廉，因而曾經在工業控制領域中得到了非常廣泛的應用，但卻無法滿足現今對執行效率、存儲容量都有較高要求的信息家電等場合的需要。 簡單操作系統階段 20世紀80年代，隨著微電子工藝水平的提高，IC製造商開始把嵌入式應用中所需要的微處理器、I/O介面、串列介面以及RAM、ROM等部件統統集成到一片VLSI中，製造出面向I/O設計的微控制器，並一舉成為嵌入式系統領域中異軍突起的新秀。與此同時，嵌入式系統的程序員也開始基於一些簡單的"操作系統"開發嵌入式應用軟體，大大縮短了開發周期、提高了開發效率。 這一階段嵌入式系統的主要特點是：出現了大量高可靠、低功耗的嵌入式CPU（如Power PC等），各種簡單的嵌入式操作系統開始出現並得到迅速發展。此時的嵌入式操作系統雖然還比較簡單，但已經初步具有了一定的兼容性和擴展性，內核精巧且效率高，主要用來控制系統負載以及監控應用程序的運行。 實時操作系統階段 20世紀90年代，在分布控制、柔性製造、數字化通信和信息家電等巨大需求的牽引下，嵌入式系統進一步飛速發展，而面向實時信號處理演算法的DSP產品則向著高速度、高精度、低功耗的方向發展。隨著硬體實時性要求的提高，嵌入式系統的軟體規模也不斷擴大，逐漸形成了實時多任務操作系統（RTOS），並開始成為嵌入式系統的主流。 這一階段嵌入式系統的主要特點是：操作系統的實時性得到了很大改善，已經能夠運行在各種不同類型的微處理器上，具有高度的模塊化和擴展性。此時的嵌入式操作系統已經具備了文件和目錄管理、設備管理、多任務、網路、圖形用戶界面（GUI）等功能，並提供了大量的應用程序介面（API），從而使得應用軟體的開發變得更加簡單。 面向Internet階段 21世紀無疑將是一個網路的時代，將嵌入式系統應用到各種網路環境中去的呼聲自然也越來越高。目前大多數嵌入式系統還孤立於Internet之外，隨著Internet的進一步發展，以及Internet技術與信息家電、工業控制技術等的結合日益緊密，嵌入式設備與Internet的結合才是嵌入式技術的真正未來。 信息時代和數字時代的到來，為嵌入式系統的發展帶來了巨大的機遇，同時也對嵌入式系統廠商提出了新的挑戰。目前，嵌入式技術與Internet技術的結合正在推動著嵌入式技術的飛速發展，嵌入式系統的研究和應用產生了如下新的顯著變化： 新的微處理器層出不窮，嵌入式操作系統自身結構的設計更加便於移植，能夠在短時間內支持更多的微處理器。 嵌入式系統的開發成了一項系統工程，開發廠商不僅要提供嵌入式軟硬體系統本身，同時還要提供強大的硬體開發工具和軟體支持包。 通用計算機上使用的新技術、新觀念開始逐步移植到嵌入式系統中，如嵌入式資料庫、移動代理、實時CORBA等，嵌入式軟體平台得到進一步完善。 各類嵌入式Linux操作系統迅速發展，由於具有源代碼開放、系統內核小、執行效率高、網路結構完整等特點，很適合信息家電等嵌入式系統的需要，目前已經形成了能與Windows CE、Palm OS等嵌入式操作系統進行有力競爭的局面。 網路化、信息化的要求隨著Internet技術的成熟和帶寬的提高而日益突出，以往功能單一的設備如電話、手機、冰箱、微波爐等功能不再單一，結構變得更加復雜，網路互聯成為必然趨勢。 精簡系統內核，優化關鍵演算法，降低功耗和軟硬體成本。 提供更加友好的多媒體人機交互界面。 1.2 體系結構 根據國際電氣和電子工程師協會（IEEE）的定義，嵌入式系統是"控制、監視或者輔助設備、機器和車間運行的裝置"（devices used to control, monitor, or assist the operation of equipment, machinery or plants）。一般而言，整個嵌入式系統的體系結構可以分成四個部分：嵌入式處理器、嵌入式外圍設備、嵌入式操作系統和嵌入式應用軟體，如圖1所示。 圖1 嵌入式系統的組成 嵌入式處理器 嵌入式系統的核心是各種類型的嵌入式處理器，嵌入式處理器與通用處理器最大的不同點在於，嵌入式CPU大多工作在為特定用戶群所專門設計的系統中，它將通用CPU中許多由板卡完成的任務集成到晶元內部，從而有利於嵌入式系統在設計時趨於小型化，同時還具有很高的效率和可靠性。 嵌入式處理器的體系結構經歷了從CISC（復雜指令集）至RISC（精簡指令集）和Compact RISC的轉變，位數則由4位、8位、16位、32位逐步發展到64位。目前常用的嵌入式處理器可分為低端的嵌入式微控制器（Micro Controller Unit，MCU）、中高端的嵌入式微處理器（Embedded Micro Processor Unit，EMPU）、用於計算機通信領域的嵌入式DSP處理器（Embedded Digital Signal Processor，EDSP）和高度集成的嵌入式片上系統（System On Chip，SOC）。 目前幾乎每個半導體製造商都生產嵌入式處理器，並且越來越多的公司開始擁有自主的處理器設計部門，據不完全統計，全世界嵌入式處理器已經超過1000多種，流行的體系結構有30多個系列，其中以ARM、PowerPC、MC 68000、MIPS等使用得最為廣泛。 嵌入式外圍設備 在嵌入系統硬體系統中，除了中心控制部件（MCU、DSP、EMPU、SOC）以外，用於完成存儲、通信、調試、顯示等輔助功能的其他部件，事實上都可以算作嵌入式外圍設備。目前常用的嵌入式外圍設備按功能可以分為存儲設備、通信設備和顯示設備三類。 存儲設備主要用於各類數據的存儲，常用的有靜態易失型存儲器（RAM、SRAM）、動態存儲器（DRAM）和非易失型存儲器（ROM、EPROM、EEPROM、FLASH）三種，其中FLASH憑借其可擦寫次數多、存儲速度快、存儲容量大、價格便宜等優點，在嵌入式領域內得到了廣泛應用。 目前存在的絕大多數通信設備都可以直接在嵌入式系統中應用，包括RS-232介面（串列通信介面）、SPI（串列外圍設備介面）、IrDA（紅外線介面）、I2C（現場匯流排）、USB（通用串列匯流排介面）、Ethernet（乙太網介面）等。 由於嵌入式應用場合的特殊性，通常使用的是陰極射線管（CRT）、液晶顯示器（LCD）和觸摸板（Touch Panel）等外圍顯示設備。 嵌入式操作系統 為了使嵌入式系統的開發更加方便和快捷，需要有專門負責管理存儲器分配、中斷處理、任務調度等功能的軟體模塊，這就是嵌入式操作系統。嵌入式操作系統是用來支持嵌入式應用的系統軟體，是嵌入式系統極為重要的組成部分，通常包括與硬體相關的底層驅動程序、系統內核、設備驅動介面、通信協議、圖形用戶界面（GUI）等。嵌入式操作系統具有通用操作系統的基本特點，如能夠有效管理復雜的系統資源，能夠對硬體進行抽象，能夠提供庫函數、驅動程序、開發工具集等。但與通用操作系統相比較，嵌入式操作系統在系統實時性、硬體依賴性、軟體固化性以及應用專用性等方面，具有更加鮮明的特點。 嵌入式操作系統根據應用場合可以分為兩大類：一類是面向消費電子產品的非實時系統，這類設備包括個人數字助理（PDA）、行動電話、機頂盒（STB）等；另一類則是面向控制、通信、醫療等領域的實時操作系統，如WindRiver公司的VxWorks、QNX系統軟體公司的QNX等。實時系統（Real Time System）是一種能夠在指定或者確定時間內完成系統功能，並且對外部和內部事件在同步或者非同步時間內能做出及時響應的系統。在實時系統中，操作的正確性不僅依賴於邏輯設計的正確程度，而且與這些操作進行的時間有關，也就是說，實時系統對邏輯和時序的要求非常嚴格，如果邏輯和時序控制出現偏差將會產生嚴重後果。 實時系統主要通過三個性能指標來衡量系統的實時性，即響應時間（Response Time）、生存時間（Survival Time）和吞吐量（Throughput）： 響應時間 是實時系統從識別出一個外部事件到做出響應的時間； 生存時間 是數據的有效等待時間，數據只有在這段時間內才是有效的； 吞吐量 是在給定的時間內系統能夠處理的事件總數，吞吐量通常比平均響應時間的倒數要小一點。 實時系統根據響應時間可以分為弱實時系統、一般實時系統和強實時系統三種。弱實時系統在設計時的宗旨是使各個任務運行得越快越好，但沒有嚴格限定某一任務必須在多長時間內完成，弱實時系統更多關注的是程序運行結果的正確與否，以及系統安全性能等其他方面，對任務執行時間的要求相對來講較為寬松，一般響應時間可以是數十秒或者更長。一般實時系統是弱實時系統和強實時系統的一種折衷，它的響應時間可以在秒的數量級上，廣泛應用於消費電子設備中。強實時系統則要求各個任務不僅要保證執行過程和結果的正確性，同時還要保證在限定的時間內完成任務，響應時間通常要求在毫秒甚至微秒的數量級上，這對涉及到醫療、安全、軍事的軟硬體系統來說是至關重要的。 時限（deadline）是實時系統中的一個重要概念，指的是對任務截止時間的要求，根據時限對系統性能的影響程度，實時系統又可以分為軟實時系統（soft real-time-system）和硬實時系統（hard real-time-system）。軟實時指的是雖然對系統響應時間有所限定，但如果系統響應時間不能滿足要求，並不會導致系統產生致命的錯誤或者崩潰；硬實時則指的是對系統響應時間有嚴格的限定，如果系統響應時間不能滿足要求，就會引起系統產生致命的錯誤或者崩潰。如果一個任務在時限到達之時尚未完成，對軟實時系統來說還是可以容忍的，最多隻會降低系統性能，但對硬實時系統來說則是無法接受的，因為這樣帶來的後果根本無法預測，甚至可能是災難性的。在目前實際運用的實時系統中，通常允許軟硬兩種實時性同時存在，其中一些事件沒有時限要求，另外一些事件的時限要求是軟實時的，而對系統產生關鍵影響的那些事件的時限要求則是硬實時的。 嵌入式應用軟體 嵌入式應用軟體是針對特定應用領域，基於某一固定的硬體平台，用來達到用戶預期目標的計算機軟體，由於用戶任務可能有時間和精度上的要求，因此有些嵌入式應用軟體需要特定嵌入式操作系統的支持。嵌入式應用軟體和普通應用軟體有一定的區別，它不僅要求其准確性、安全性和穩定性等方面能夠滿足實際應用的需要，而且還要盡可能地進行優化，以減少對系統資源的消耗，降低硬體成本。 1.3 關鍵問題 嵌入式系統是將先進的計算機技術、半導體技術以及電子技術與特定行業的具體應用相結合的產物，因此必然是一個技術密集、資金密集、高度分散、不斷創新的知識集成系統，嵌入式系統的開發充滿了競爭、機遇與創新，需要解決好如下一些關鍵問題： 內核精巧 嵌入式系統的應用領域一般都是小型電子裝置，系統資源相對有限，因此對內核的要求相當高，較之傳統的操作系統來講要小得多，例如ENEA公司推出的OSE分布式嵌入式系統，整個內核只有5KB。 面向應用 嵌入式系統通常是面向用戶、面向產品、面向特定應用的。嵌入式系統中的CPU大多工作在為特定用戶群定製的環境中，具有低耗、體積小、集成度高等特點，在進行軟硬體設計時必須突出效率、去除冗餘，針對用戶的具體需求對系統進行合理的配置，方能達到理想的性能。 系統精簡 嵌入式系統中的系統軟體和應用軟體通常沒有明顯的區別，不要求其功能及實現上過於復雜，這樣一方面有利於控制系統成本，另一方面也有利於保證系統安全。 性能優化 嵌入式系統通常都要求有一定的實時性保障，為了提高執行速度和系統性能，嵌入式系統中的軟體一般都固化在存儲晶元或者處理器的內部存儲器件當中，而不是存貯在磁碟等外部載體中。由於嵌入式系統的運算速度和存儲容量存在一定程度上的限制，而且大部分系統都必須有較高的實時性保證，因此對軟體質量（特別是可靠性方面）有著較高的要求。 專業開發 嵌入式系統本身並不具備自主開發能力，用戶不能直接在其上進行二次開發。當系統完成之後，用戶如果需要修改其中某個程序的功能，必須藉助一套完整的開發工具和環境。嵌入式系統中專用的開發工具和環境通常是基於通用計算機上的軟硬體設備，以及各種邏輯分析儀、混合信號示波器等。 回頁首 二、嵌入式Linux Linux從1991年問世到現在，短短的十幾年時間已經發展成為功能強大、設計完善的操作系統之一，不僅可以與各種傳統的商業操作系統分庭抗爭，在新興的嵌入式操作系統領域內也獲得了飛速發展。嵌入式Linux（Embedded Linux）是指對標准Linux經過小型化裁剪處理之後，能夠固化在容量只有幾K或者幾M位元組的存儲器晶元或者單片機中，適合於特定嵌入式應用場合的專用Linux操作系統。 2.1 優勢 嵌入式Linux的開發和研究是操作系統領域中的一個熱點，目前已經開發成功的嵌入式系統中，大約有一半使用的是Linux。Linux之所以能在嵌入式系統市場上取得如此輝煌的成果，與其自身的優良特性是分不開的。 廣泛的硬體支持 Linux能夠支持x86、ARM、MIPS、ALPHA、PowerPC等多種體系結構，目前已經成功移植到數十種硬體平台，幾乎能夠運行在所有流行的CPU上。Linux有著異常豐富的驅動程序資源，支持各種主流硬體設備和最新硬體技術，甚至可以在沒有存儲管理單元（MMU）的處理器上運行，這些都進一步促進了Linux在嵌入式系統中的應用。 內核高效穩定 Linux內核的高效和穩定已經在各個領域內得到了大量事實的驗證，Linux的內核設計非常精巧，分成進程調度、內存管理、進程間通信、虛擬文件系統和網路介面五大部分，其獨特的模塊機制可以根據用戶的需要，實時地將某些模塊插入到內核或從內核中移走。這些特性使得Linux系統內核可以裁剪得非常小巧，很適合於嵌入式系統的需要。 開放源碼，軟體豐富 Linux是開放源代碼的自由操作系統，它為用戶提供了最大限度的自由度，由於嵌入式系統千差萬別，往往需要針對具體的應用進行修改和優化，因而獲得源代碼就變得至關重要了。Linux的軟體資源十分豐富，每一種通用程序在Linux上幾乎都可以找到，並且數量還在不斷增加。在Linux上開發嵌入式應用軟體一般不用從頭做起，而是可以選擇一個類似的自由軟體做為原型，在其上進行二次開發。 優秀的開發工具 開發嵌入式系統的關鍵是需要有一套完善的開發和調試工具。傳統的嵌入式開發調試工具是在線模擬器（In-Circuit Emulator，ICE），它通過取代目標板的微處理器，給目標程序提供一個完整的模擬環境，從而使開發者能夠非常清楚地了解到程序在目標板上的工作狀態，便於監視和調試程序。在線模擬器的價格非常昂貴，而且只適合做非常底層的調試，如果使用的是嵌入式Linux，一旦軟硬體能夠支持正常的串口功能時，即使不用在線模擬器也可以很好地進行開發和調試工作，從而節省了一筆不小的開發費用。嵌入式Linux為開發者提供了一套完整的工具鏈（Tool Chain），它利用GNU的gcc做編譯器，用gdb、kgdb、xgdb做調試工具，能夠很方便地實現從操作系統到應用軟體各個級別的調試。 完善的網路通信和文件管理機制 Linux至誕生之日起就與Internet密不可分，支持所有標準的Internet網路協議，並且很容易移植到嵌入式系統當中。此外，Linux還支持ext2、fat16、fat32、romfs等文件系統，這些都為開發嵌入式系統應用打下了很好的基礎。 2.2 挑戰 目前，嵌入式Linux系統的研發熱潮正在蓬勃興起，並且占據了很大的市場份額，除了一些傳統的Linux公司（如RedHat、MontaVista等）正在從事嵌入式Linux的開發和應用之外，IBM、Intel、Motorola等著名企業也開始進行嵌入式Linux的研究。雖然前景一片燦爛，但就目前而言，嵌入式Linux的研究成果與市場的真正要求仍有一段差距，要開發出真正成熟的嵌入式Linux系統，還需要從以下幾個方面做出努力。 提高系統實時性 Linux雖然已經被成功地應用到了PDA、行動電話、車載電視、機頂盒、網路微波爐等各種嵌入式設備上，但在醫療、航空、交通、工業控制等對實時性要求非常嚴格的場合中還無法直接應用，原因在於現有的Linux是一個通用的操作系統，雖然它也採用了許多技術來加快系統的運行和響應速度，並且符合POSIX 1003.1b標准，但從本質上來說並不是一個嵌入式實時操作系統。Linux的內核調度策略基本上是沿用UNIX系統的，將它直接應用於嵌入式實時環境會有許多缺陷，如在運行內核線程時中斷被關閉，分時調度策略存在時間上的不確定性，以及缺乏高精度的計時器等等。正因如此，利用Linux作為底層操作系統，在其上進行實時化改造，從而構建出一個具有實時處理能力的嵌入式系統，是現在日益流行的解決方案。 改善內核結構 Linux內核採用的是整體式結構（Monolithic），整個內核是一個單獨的、非常大的程序，這樣雖然能夠使系統的各個部分直接溝通，有效地縮短任務之間的切換時間，提高系統響應速度，但與嵌入式系統存儲容量小、資源有限的特點不相符合。嵌入式系統經常採用的是另一種稱為微內核（Microkernel）的體系結構，即內核本身只提供一些最基本的操作系統功能，如任務調度、內存管理、中斷處理等，而類似於文件系統和網路協議等附加功能則運行在用戶空間中，並且可以根據實際需要進行取捨。Microkernel的執行效率雖然比不上Monolithic，但卻大大減小了內核的體積，便於維護和移植，更能滿足嵌入式系統的要求。可以考慮將Linux內核部分改造成Microkernel，使Linux在具有很高性能的同時，又能滿足嵌入式系統體積小的要求。 完善集成開發平台 引入嵌入式Linux系統集成開發平台，是嵌入式Linux進一步發展和應用的內在要求。傳統上的嵌入式系統都是面向具體應用場合的，軟體和硬體之間必須緊密配合，但隨著嵌入式系統規模的不斷擴大和應用領域的不斷擴展，嵌入式操作系統的出現就成了一種必然，因為只有這樣才能促成嵌入式系統朝層次化和模塊化的方向發展。很顯然，嵌入式集成開發平台也是符合上述發展趨勢的，一個優秀的嵌入式集成開發環境能夠提供比較完備的模擬功能，可以實現嵌入式應用軟體和嵌入式硬體的同步開發，從而擺脫了"嵌入式應用軟體的開發依賴於嵌入式硬體的開發，並且以嵌入式硬體的開發為前提"的不利局面。一個完整的嵌入式集成開發平台通常包括編譯器、連接器、調試器、跟蹤器、優化器和集成用戶界面，目前Linux在基於圖形界面的特定系統定製平台的研究上，與Windows CE等商業嵌入式操作系統相比還有很大差距，整體集成開發環境有待提高和完善。 回頁首 三、關鍵技術 嵌入式系統是一種根據特定用途所專門開發的系統，它只完成預期要完成的功能，因此其開發過程和開發環境同傳統的軟體開發相比有著顯著的不同。 3.1 開發流程 在嵌入式系統的應用開發中，整個系統的開發過程如圖2所示： 圖2 嵌入式系統的開發流程 嵌入式系統發展到今天，對應於各種微處理器的硬體平台一般都是通用的、固定的、成熟的，這就大大減少了由硬體系統引入錯誤的機會。此外，由於嵌入式操作系統屏蔽了底層硬體的復雜性，使得開發者通過操作系統提供的API函數就可以完成大部分工作，因此大大簡化了開發過程，提高了系統的穩定性。嵌入式系統的開發者現在已經從反復進行硬體平台設計的過程中解脫出來，從而可以將主要精力放在滿足特定的需求上。 嵌入式系統通常是一個資源受限的系統，因此直接在嵌入式系統的硬體平台上編寫軟體比較困難，有時候甚至是不可能的。目前一般採用的解決辦法是首先在通用計算機上編寫程序，然後通過交叉編譯生成目標平台上可以運行的二進制代碼格式，最後再下載到目標平台上的特定位置上運行。 需要交叉開發環境（Cross Development Environment）的支持是嵌入式應用軟體開發時的一個顯著特點，交叉開發環境是指編譯、鏈接和調試嵌入式應用軟體的環境，它與運行嵌入式應用軟體的環境有所不同，通常採用宿主機／目標機模式，如圖3所示。 圖3 交叉開發環境 宿主機（Host）是一台通用計算機（如PC機或者工作站），它通過串口或者乙太網介面與目標機通信。宿主機的軟硬體資源比較豐富，不但包括功能強大的操作系統（如Windows和Linux），而且還有各種各樣優秀的開發工具（如WindRiver的Tornado、Microsoft的Embedded Visual C++等），能夠大大提高嵌入式應用軟體的開發速度和效率。 目標機（Target）一般在嵌入式應用軟體開發期間使用，用來區別與嵌入式系統通信的宿主機，它可以是嵌入式應用軟體的實際運行環境，也可以是能夠替代實際運行環境的模擬系統，但軟硬體資源通常都比較有限。嵌入式系統的交叉開發環境一般包括交叉編譯器、交叉調試器和系統模擬器，其中交叉編譯器用於在宿主機上生成能在目標機上運行的代碼，而交叉調試器和系統模擬器則用於在宿主機與目標機間完成嵌入式軟體的調試。在採用宿主機／目標機模式開發嵌入式應用軟體時，首先利用宿主機上豐富的資源和良好的開發環境開發和模擬調試目標機上的軟體，然後通過串口或者以網路將交叉編譯生成的目標代碼傳輸並裝載到目標機上，並在監控程序或者操作系統的支持下利用交叉調試器進行分析和調試，最後目標機在特定環境下脫離宿主機單獨運行。 建立交叉開發環境是進行嵌入式軟體開發的第一步，目前常用的交叉開發環境主要有開放和商業兩種類型。開放的交叉開發環境的典型代表是GNU工具鏈、目前已經能夠支持x86、ARM、MIPS、PowerPC等多種處理器。商業的交叉開發環境則主要有Metrowerks CodeWarrior、ARM Software Development Toolkit、SDS Cross compiler、WindRiver Tornado、Microsoft Embedded Visual C++等。 3.2 交叉編譯和鏈接 在完成嵌入式軟體的編碼之後，需要進行編譯和鏈接以生成可執行代碼，由於開發過程大多是在使用Intel公司x86系列CPU的通用計算機上進行的，而目標環境的處理器晶元卻大多為ARM、MIPS、PowerPC、DragonBall等系列的微處理器，這就要求在建立好的交叉開發環境中進行交叉編譯和鏈接。 交叉編譯器和交叉鏈接器是能夠在宿主機上運行，並且能夠生成在目標機上直接運行的二進制代碼的編譯器和鏈接器。例如在基於ARM體系結構的gcc交叉開發環境中，arm-linux-gcc是交叉編譯器，arm-linux-ld是交叉鏈接器。通常情況下，並不是每一種體系結構的嵌入式微處理器都只對應於一種交叉編譯器和交叉鏈接器，比如對於M68K體系結構的gcc交叉開發環境而言，就對應於多種不同的編譯器和鏈接器。如果使用的是COFF格式的可執行文件，那麼在編譯Linux內核時需要使用m68k-coff-gcc和m68k-coff-ld，而在編譯應用程序時則需要使用m68k-coff-pic-gcc和m68k-coff-pic-ld。 嵌入式系統在鏈接過程中通常都要求使用較小的函數庫，以便最後產生的可執行代碼能夠盡可能地小，因此實際運用時一般使用經過特殊處理的函數庫。對於嵌入式Linux系統來講，功能越來越強、體積越來越大的C語言函數庫glibc和數學函數庫libm已經很難滿足實際的需要，因此需要採用它們的精化版本uClibc、uClibm和newlib等。 目前嵌入式的集成開發環境都支持交叉編譯和交叉鏈接，如WindRiver Tornado和GNU工具鏈等，編寫好的嵌入式軟體經過交叉編譯和交叉鏈接後通常會生成兩種類型的可執行文件：用於調試的可執行文件和用於固化的可執行文件。 3.3 交叉調試 嵌入式軟體經過編譯和鏈接後即進入調試階段，調試是軟體開發過程中必不可少的一個環節，嵌入式軟體開發過程中的交叉調 ~

Ⅲ 嵌入式中的移植是什麼意思，移植系統呢

與其它操作系統相比，Linux最大的特點：它是一款遵循GPL的操作系統，我們可以自由
地使用、修改、和擴展它。正是由於這一特色，Linux受到越來越多人士的青睞。於是，
一個經常會被探討的問題出現了，即關於Linux系統的移植。對於操作系統而言，這種移
植通常是跨平台的、與硬體相關的，即硬體系統結構、甚至CPU不同。下面就讓我們來看
看在Linux系統移植方面，我們都需要做些什麼。
一、Linux系統移植的兩大部分
對於系統移植而言，Linux系統實際上由兩個比較獨立的部分組成，即內核部分和系
統部分。通常啟動一個Linux系統的過程是這樣的：一個不隸屬於任何操作系統的載入程
序將Linux部分內核調肢兄慧入內存，並將控制權交給內存中Linux內核的第一行代碼。載入程
序的工作就完了，此後Linux要將自己的剩餘部分全部載入到內存（如果有的話，視硬體
平台的不同而不同），初始化所有的設備，在內存中建立好所需的數據結構（有關進程
、設備、內存等）。到此為止Linux內核的工作告一段落，內核已經控制了所有硬體設備
。至於操作和使用這些硬體設備，則輪到系統部分上場了。內核載入根設備並啟動init
守護進程，init守護進程會根據配置文件載入文件系統、配置網路、服務進程、終端等
。一旦終端初始化完畢，我們就會看到系統的歡迎界面了。小結一下：
(1)內核部分初始化和控制所有硬體設備（嚴格說不是所有，而是絕大部分），為內存
管理、進程管理、設備讀寫等工作做好一切准備。
(2)系統部分載入必需的設備，配置各種環境以便用戶可以使用整個系統。
二、系統移植所必需的環境
在進一步敘述之前，我們有必要提一下做系統移植所必需的環境。
首先，需要一個新版本的gcc。對於一個准備系統移植的程序員而言，「新」到什麼
程度應該心裡有數。做跨平台編譯，gcc也許是最好的選擇。另外，Linux內核依賴許多
gcc特有的特性，非它不可。如果你已經會使用gcc並實地操練過多回，那你只需要再進
一步鞏固一下跨平台編譯的操作即可。兩種編譯環境是可用的：非目標平台上的Linux或
目標平台上的非Linux系統，除非你的開發平台過於特殊，否則你一定能夠找到你能用的
gcc。
其次，編譯鏈接庫是必需的，而且必須是目標平台的編譯鏈接庫。通常這歷答是一個枯
燥、繁瑣、又絲毫沒有成就感的過程。幸運的話，會有現成的鏈接庫可以用。否則，你
需要自己用gcc建立它。
最後，需要目標平台的所有文檔，越多越好。如果有一定的開發支持/模擬環境，L
oader（載入程序）則最好，這些可以幫助你減少移植過程中浪費在瑣事上的時間。
三、Linux系統移植
接下來我們從內核和系統兩個方面描述一下移植中的關鍵。
(1) 內存移植
Linux系統採用了相對來說並不是很靈活的單一內核機制，但這絲毫沒有影響Linux
系統的平台無關性和可擴展性。Linux使用了兩種途徑分別解決這些問題，很乾凈利落，
絲毫不拖泥帶水，而且十分清晰易懂。分離硬體相關代碼和硬體無關代碼，使上層代碼
永遠不必關心低層換用了什麼代碼，如何完成了操作。不論對x86上還是在Alpha平台上
分配一塊內存，對上層代碼而言沒什麼不同。硬體相關部分的代碼不多，占總代碼量的
很少一部分。所以對更換硬體平台來說，沒有什麼真正的負擔。另一方面，Linux使用內
核機制很好地解決了擴展的問題，一堆代碼可以在需要的時候輕松地載入或卸下，象隨
身聽，需要的時候帶上，不需要時則鎖在抽屜里。
Linux內核可以視為由五個功能部分組成：進程管理（包括調度和通信）、內存管理
、設備管理、虛擬文件系統、網路。它們之間有著復雜的調用關系，但幸運的是，在移
植中不會觸及到太多，因為Linux內核良好的分層結構將硬體相關的代碼獨立出來。何謂
硬體相關，何謂無關？以進程管理為例，對進程的時間片輪轉調度演算法在所有平台的Li
nux中都是一樣的，它是與平台無關的；而用來在進程中切換的實現在不同的CPU上是不
同的，因此需要針對該平台編寫代碼，這就是平台相關的。上面所講的五個部分的順序
不是隨便排的，從前到後分別代表著它們與硬體設備的相關程度。越靠前越高，後面的
兩個虛擬文件系統和網路則幾乎與平台無關，它們由設備管理中所支持塵森的驅動程序提供
底層支持。因此，在做系統移植的時候，需要改動的就是進程管理、內存管理和設備管
理中被獨立出來的那部分即硬體相關部分的代碼。在Linux代碼樹下，這部分代碼全部在
arch目錄下。
如果你的目標平台已經被Linux核心所支持的話，那麼你是幸運的，因為已經沒有太
多的工作讓你去做。只要你的交叉編譯環境是正確的，你只需要簡單的配置、編譯就可
以得到目標代碼。否則，需要你去編寫，或修改一些代碼。只需修改平台相關部分的代
碼即可。但需要對目標平台，主要是對CPU的透徹理解。在Linux的代碼樹下，可以看到
，這部分的典型代碼量為：2萬行左右C代碼和2千行左右的匯編（C代碼中通常包含許多
偽匯編指令，因此實際上純C代碼要少很多），這部分工作量是不可小看的。它包含了對
絕大多數硬體的底層操作，涉及IRQ、內存頁表、快表、浮點處理、時鍾、多處理器同步
等問題，頻繁的埠編程意味著需要你將目標平台的文檔用C語言重寫一遍。這就是為什
么說目標平台的文檔極其重要。
代碼量最大的部分是被核心直接調用的底層支持部分，這部分代碼在arch/xxx/ker
nel下(xxx是平台名稱)。這些代碼重寫了內核所需調用的所有函數。因為介面函數是固
定的，所以這里更象是為硬體平台編寫API。不同的系統平台，主要有以下幾方面的不同
：
進程管理底層代碼：從硬體系統的角度來看，進程管理就是CPU的管理。在不同的硬
件平台上，這有很大的不同。CPU中用的寄存器結構不同，上下文切換的方式、現場的保
存和恢復、棧的處理都不同，這些內容主要由CPU開發手冊所描述。通常來說，CPU的所
有功能和狀態對於Linux不一定有意義。實現時，需要在最小的開發代價和最好的系統性
能之間加以權衡。
* BIOS介面代碼：這一名稱似乎並不太准確，因為它沿用了PC一貫的叫法。但在不致引
起混淆的情況下我們還是這么叫它。在通用平台上，通常有基本輸入輸出系統供操作系
統使用，在PC上是BIOS，在SPARC上是PROM，在很多非通用系統上甚至並沒有這樣的東西
。多數情況下，Linux不依賴基本輸入輸出系統，但在某些系統里，Linux需要通過基本
輸入輸出系統中得到重要的設備參數。移植中，這部分代碼通常需要完全改寫。
* 時鍾、中斷等板上設備支持代碼：即使在同一種CPU的平台上，也會存在不同的板上外
設，異種CPU平台上更是如此。不同的系統組態需要不同的初始化代碼。很典型的例子就
是MIPS平台，看看arc/mips/的代碼，與其它系統比較一下就知道。因為MIPS平台被OEM
得最廣，在嵌入式領域應用最多（相對其它幾種CPU而言）。甚至同一種MIPS晶元被不同
廠家封裝再配上不同的晶元組。因此要為這些不同的MIPS平台分別編寫不同的代碼。
* 特殊結構代碼：如多處理器支持等。其實每一種CPU都是十分特殊的，熟悉x86平台的
人都知道x86系列CPU著名的實模式與虛模式的區別，而在SPARC平台上根本就沒有這個概
念。這就導致了很大的不同：PC機上的Linux在獲得控制權後不久就開始切換到虛模式，
SPARC機器上則沒有這段代碼。又如電源管理的支持更是多種多樣，不同的CPU有著不同
的實現方式（特殊的電源管理方式甚至被廠商標榜）。在這種情況下，除非放棄對電源
管理的支持，否則必須重寫代碼。
還有一部分代碼量不多，但不能忽視的部分是在arch/xxx/mm/下的內存管理部分。
所有與平台相關的內存管理代碼全部在這里。這部分代碼完成內存的初始化和各種與內
存管理相關的數據結構的建立。Linux使用了基於頁式管理的虛擬存儲技術，而CPU發展
的趨勢是：為了提高性能，實現內存管理的功能單元統統被集成到CPU中。因此內存管理
成為一個與CPU十分相關的工作。同時內存管理的效率也是最影響系統性能的因素之一。
內存可以說是計算機系統中最頻繁訪問的設備，如果每次內存訪問時多佔用一個時鍾周
期，那就有可能將系統性能降低到不可忍受。在Linux系統里，不同平台上的內存管理代
碼的差異程度是令人吃驚的，可以說是差異最大的。不同的CPU有不同的內存管理方式，
同一種CPU還會有不同的內存管理模式。Linux是從32位硬體平台上發展起來的操作系統
，但是現在已經有數種64位平台出現。在64位平台上，可用內存范圍增大到原來的232倍
，其間差異可略窺一斑了。鑒於這部分代碼的重要性和復雜性，移植工作在這里變得相
當謹慎。有些平台上甚至只是用最保守的內存管理模式。如在SPARC平台上的頁面大小可
以是多種尺寸，為了簡單和可靠起見，SPARC版的Linux只是用了8K頁面這一種模式。這
一狀況直到2.4版才得以改善。
除了上面所講的之外，還有一些代碼需要考慮，但相對來說次要一些。如浮點運算
的支持。較完美的做法是對FPU編程，由硬體完成浮點運算。但在某些時候，浮點並不重
要，甚至CPU根本就不支持浮點。這時候就可以根據需求來取捨。
對於內核移植的討論到此為止。實際上，還有一些移植工作需要同時考慮，但很難
說這是屬於內核范疇還是屬於驅動程序范疇，比如說顯示設備的支持，和內核十分相關
，但在邏輯上又不屬於內核，並且在移植上也更像是驅動程序的開發。因此不在這里討
論。
(2)系統移植
當內核移植完畢後，可以說所有的移植工作就已經完成大半了。就是說，當內核在
交叉編譯成功後，載入到目標平台上正常啟動，並出現類似VFS: Can抰 mount root fi
le system的提示時，則表示可以開始系統移植方面的工作了。系統移植實際上是一個最
小系統的重建過程。許多Linux愛好者有過建立Linux系統應急盤的經驗，與其不同的是
，你需要使用目標平台上的二進制代碼生成這個最小系統。包括：init、libc庫、驅動
模塊、必需的應用程序和系統配置腳本。一旦這些工作完成，移植工作就進入聯調階段
了。
一個比較容易的系統部分移植辦法是：先著手建立開發平台上的最小系統，保證這
套最小系統在開發平台上正確運行。這樣可以避免由於最小系統本身的邏輯錯誤而帶來
的麻煩。由於最小系統中是多個應用程序相互配合工作，有時出現的問題不在代碼本身
而在系統的邏輯結構上。
Linux系統移植工作至少要包括上述的內容，除此之外，有一些看不見的開發工作也
是不可忽視的，如某個特殊設備的驅動程序，為調試內核而做的遠程調試工作等。另外
，同樣的一次移植工作，顯然符合最小功能集的移植和完美移植是不一樣的；向16位移
植和向64位移植也是不一樣的。
在移植中通常會遇見的問題是試運行時鎖死或崩潰，在系統部分移植時要好辦些，
因為可以容易地定位錯誤根源，而在核心移植時確實很讓人頭疼。雖然可以通過串口對
運行著的內核進行調試，但是在多任務情況下，有很多現象是不可重現的。又如，在初
始化的開始，很多設備還沒法確定狀態，甚至串口還沒有初始化。對於這種情況沒有什
么很好的解決辦法，好的開發/模擬平台很重要，另外要多增加反映系統運行狀態的調試
代碼；再者要吃透硬體平台的文檔。硬體平台廠商的專業支持也是很重要的。
還有一點很重要：Linux本身是基於GPL的操作系統，移植時，可以充分發揮GPL的優
勢，讓更多的愛好者參與進來，向共同的目標前進。

Ⅳ 編譯基於linux內核2.6的驅動一定要在電腦上用2.6內核的操作系統嗎

RH9 ？那你的升級還不如直接去作一個 LFS 。

內核驅動是要匹配內核版本的，而且要匹配小版本，2.6.9 、2.6.11 .2.6.2x （忘了具體版本）都有介面修改。最近內核介面變化非常大，很多驅動介面變動的都要修改驅動才能支持。

如果你真的想用 RH 升級，給你的升級路線是：
升級 moles-init-tools -> 升級內核
不過這樣你的系統可能會有問題，一般用應該沒問題，但驅動編譯可能會過不去，或者就算編譯成功，測試成功，也不能保證可以在別人的機器上使用。（因為編譯驅動是和內核版本以及 gcc 版本相關的）
這樣的話，你可能需要升級 glibc -> gcc ->binutils -> glibc -> gcc （這兩個是在新環境重新編譯）-> 重新編譯內核 -> 升級或者重新編譯基礎軟體環境 -> 重新編譯全部系統。
大概全自動腳本協助的狀態下（也就是說排除操作時的時間損耗，找資料的時間損耗）。大概需要 48 小時 - 72 小時吧。機器性能特別好，也需要大概 36 小時以上，之後因為你的 Linux 環境已經升級，你所有想安裝的軟體都要自己編譯安裝。

不過注意，RH9 自帶的 gcc 是 3.x （好象是 3.2 ），現在 gcc 是 4.3 。其中加強了語法檢查，以及別的東西。glibc 也跨過多個版本（RH9 好幾年前的，真想不起來他是什麼版本了。反正非常古老），可以說現在的程序介面，已經和過去不同了。
你用 RH9 開發，現在來說應該只有你自己的機器可以運行，換到別人的機器上，那就需要把別人的機器改回 RH9 （這在新計算機上面是不可能的，不兼容很多硬體的），並且根據你的升級去升級軟體，才能使用。

當然，這里有個除非，除非你開發的驅動不是用在你當前的計算機上面，而是通過交叉編譯而運行在另外一個系統上面，這樣的話，只要你的交叉編譯環境版本正確，那就沒問題（不過我還是質疑這個交叉編譯用的 gcc 和 binutils 能否在你的機器上面編譯出來＆運行。）
--------------------
RH4 是什麼？比 RH9 還老的版本？
還是 RHEL 4 ？這個也不新。

理論上在開發板上面載入是和當前系統無關的，但你需要一個能在當前系統上面運行的交叉編譯環境，用這個交叉編譯環境來編譯一個在你的目標 CPU、主板上目標內核兼容的驅動程序。

這個是嵌入式開發的基礎知識，如果你連這個都不會，暫時不要看 Linux 驅動開發，先去看看「交叉編譯程序」相關的信息。

因為 arm 上面的 CPU 指令架構與 x86 完全不同，所以這兩個內核版本不同沒有關系，只要是針對 arm 的內核&架構編寫的驅動，並且用交叉編譯器編譯為 arm 的二進制指令，就能使用。