【正文】 匯編器（AS），連接器（LD）以及匯編連接后二進制文件格式的定義，它為GCC提供底層的支持；Newlib為GCC提供函數(shù)庫。編譯的過程是：首先將這三部分的補丁打上，然后按照Binutils，Newlib和GCC的順序進行編譯。這樣編譯完成之后得到的就是交叉編譯器。（4）VMware 工作站：提供Linux和Windows之間的通信。 目標機環(huán)境本課題目標機開發(fā)環(huán)境使用的是遼寧省嵌入式軟件技術(shù)工程研究中心開發(fā)的NEURTEMSMCF5307開發(fā)套件，用于面向以Motorola Coldfire 5307處理器和RTEMS操作系統(tǒng)為核心的目標平臺的嵌入式系統(tǒng)開發(fā)。該套件由以下幾個部分組成：（1）基于Motorola ColdfireTM 5307處理器的開發(fā)板；（2）開放源代碼的操作系統(tǒng)RTEMS，包括針對本開發(fā)板的開放源代碼的BSP；（3）開放源代碼的配置引導(dǎo)軟件Firework，完成目標系統(tǒng)配置，映象下載和flash擦寫的功能；（4）運行于PC/Linux系統(tǒng)上的軟件開發(fā)調(diào)試環(huán)境。NEURTEMSMCF5307開發(fā)套件不但提供了一個穩(wěn)定的嵌入式系統(tǒng)平臺，還能夠為以下開發(fā)提供強有力的支持：（1）面向Motorola Coldfire 5307處理器的嵌入式系統(tǒng)開發(fā)；（2）在運行于以Motorola Coldfire 5307處理器為核心的嵌入式硬件平臺上的RTEMS操作系統(tǒng)上進行應(yīng)用程序開發(fā)；（3）在NEURTEMSMCF5307開發(fā)套件所提供的源代碼基礎(chǔ)上進行快捷的嵌入式系統(tǒng)的定制。其中，RTEMS操作系統(tǒng)包括開發(fā)板NEU5307DevBoard的BSP，提供了UART驅(qū)動、LCD驅(qū)動、觸摸板驅(qū)動、定時器驅(qū)動和NE2000以太網(wǎng)控制器驅(qū)動等。東北大學(xué)碩士學(xué)位論文 第四章 關(guān)鍵技術(shù)的設(shè)計與實現(xiàn)第四章 關(guān)鍵技術(shù)的設(shè)計與實現(xiàn) 事件消息機制設(shè)計實現(xiàn) GUI與OS之間通信UI與OS之間的通信方式，是整個UI通信的基礎(chǔ)。常見的有：消息隊列。例如嵌入式領(lǐng)域中比較著名的Microwindows，Minigui等，他們的通信機制都是建立在消息隊列之上，包括消息的定義、消息的傳遞和消息的處理等。管道。例如引擎功能強大的QT，它用于不同的客戶之間在同一地址空間內(nèi)部或者不同的進程之間通信的QCOP協(xié)議，就是基于管道實現(xiàn)的。SOCKET。幾乎所有采用C/S模式的UI在Client和Server之間通信時都采用SOCKET，包括QT、Minigui等。 GUI 內(nèi)部對象之間通信的設(shè)計實現(xiàn) 內(nèi)部對象之間通信機制整體設(shè)計在大多數(shù)GUI工具中，通常為可能觸發(fā)的每種行為定義一個回調(diào)函數(shù)，這個回調(diào)函數(shù)是一個指向函數(shù)的指針。這種做法，會使得處理函數(shù)指針、句柄出現(xiàn)“滿天飛”的現(xiàn)象，大大增加了系統(tǒng)的復(fù)雜度和不安全性，以及應(yīng)用開發(fā)和調(diào)試的難度。在本文中，提出一種事件消息通信機制來代替這種繁雜的函數(shù)指針，不僅能夠?qū)崿F(xiàn)同樣的功能，而且這種機制還允許事件消息可以攜帶任意類型、任意數(shù)量的參數(shù)，而且完全是安全的，不會引起系統(tǒng)的崩潰。在這種機制中，事件消息通常是當(dāng)對象改變它們的狀態(tài)時發(fā)出的，這就是一個對象在需要與其它對象通信時所需要做的一切，它并不知道是否有其它對象在另一端接收該消息。從這個意義上來說，這種機制實現(xiàn)了真正的信息封裝，確保了對象可以被當(dāng)作一個獨立的軟件構(gòu)件來使用。而事件處理函數(shù)可以被用于接收信號，它們通常是類中的成員函數(shù)。一個事件處理函數(shù)并不知曉是否有一個消息與自己相聯(lián)系，同樣，包含有該處理函數(shù)的對象也對通信機制一無所知，它們也可以作為一個獨立的軟件構(gòu)件。用戶可以按照需要將許多事件消息與一個事件處理函數(shù)相聯(lián)系，一個消息也可以按需要被聯(lián)系到很多不同的處理函數(shù)。甚至還可以將一個消息直接與另一個消息相聯(lián)系，這樣當(dāng)?shù)谝粋€消息被發(fā)出后立刻發(fā)出第二個信號。： 本GUI Toolkit事件消息通信機制原理圖Figure Principles of EventMessage munication mechanism 消息轉(zhuǎn)換中心消息轉(zhuǎn)換部分主要負責(zé)消息格式的轉(zhuǎn)換，具體工作就是將操作系統(tǒng)送來的硬件消息轉(zhuǎn)換成GUI內(nèi)部定義的統(tǒng)一的消息格式。操作系統(tǒng)送來的消息格式定義為設(shè)備編號、控制數(shù)據(jù)信息和附加信息，GUI內(nèi)部統(tǒng)一的消息格式為消息類型、發(fā)送者和附加信息。由于內(nèi)部對象發(fā)出的消息是按規(guī)定的消息格式填寫的，所以消息的轉(zhuǎn)換主要是針對外部消息而言的。在介紹其主要工作原理圖之前，需要先介紹一下GUI Toolkit的一個重要的全局數(shù)據(jù)結(jié)構(gòu)：對象注冊鏈表。它記錄著整個GUI在運行期間所有的對象。還是由于工控的從簡要求和初步開發(fā)的粗糙性，該對象主要有指窗口和控件兩種，并且沒有實現(xiàn)組合控件，所以該記錄表是個二維鏈表，結(jié)構(gòu)以窗口為主鏈，每個窗口內(nèi)所有的控件作為副鏈；并且該鏈表是個動態(tài)鏈表，它的節(jié)點隨窗口、控件的創(chuàng)建或者消亡而增加或者減少。以鼠標點擊為例，：計數(shù)器驅(qū)動鼠標驅(qū)動觸摸板驅(qū)動鍵盤驅(qū)動……m1 m2 m3 m4 m5 … RTEMS內(nèi)核消息轉(zhuǎn)換模塊窗口注冊鏈表窗口M1控件注冊鏈表控件M2序號 發(fā)送者 參數(shù)部分原數(shù)據(jù)部分M3設(shè)備類型規(guī)則一規(guī)則二 消息轉(zhuǎn)換中心原理圖Figure Principles of Message Transform Centerm1,m2,m3,m4,m5：由設(shè)備驅(qū)動程序發(fā)送的消息，由RTEMS消息管理器發(fā)送到消息格式轉(zhuǎn)化中心格式的轉(zhuǎn)換。該消息的格式為：struct {（1）設(shè)備類型；（2）觸發(fā)類型（鼠標單擊、雙擊、左擊、右擊，鍵盤擊鍵，計算器超時等）；（3）Union{點擊點坐標值；鍵值；其它；}}；M1，M2：如果查找到的窗口控件不是當(dāng)前窗口或者獲得焦點的控件，那么MM2就是窗口切換、控件焦點切換的消息。M3：經(jīng)由消息轉(zhuǎn)換中心轉(zhuǎn)換成的標準格式的GUI內(nèi)部消息，其主要有三部分組成：消息類型號、發(fā)送者和參數(shù)部分。消息類型號共256個，其中0號是空消息，1～30號是系統(tǒng)消息，31～255是GUI內(nèi)部消息；發(fā)送者部分是對象ID；剩余部分是靈活的參數(shù)部分，由應(yīng)用程序自己定義使用。規(guī)則一：這是在窗口鏈表種查找包含當(dāng)前坐標點的窗口所依據(jù)的規(guī)則。窗口鏈表的維護原則主要有：（1）整個鏈表中只有一個節(jié)點是Active的，即GUI系統(tǒng)中有且只有一個是當(dāng)前窗口；（2）狀態(tài)是Active的節(jié)點位于鏈表首部，便于查找，提高查找速度，因為當(dāng)前active的窗口，是當(dāng)前消息目標的概率最大；（3）鏈表中越靠前的位置，顯示層面上越靠上層，所以在插入節(jié)點時，采用首部插入的方法。所以根據(jù)窗口鏈表的維護原則，規(guī)則一的目標就是從鏈表首部開始，找到第一個包含該坐標值的節(jié)點。若此節(jié)點是當(dāng)前窗口，則不發(fā)送消息M1；否則，發(fā)送消息M1，M1的處理程序會進行窗口切換，調(diào)整焦點窗口和窗口鏈表中節(jié)點的順序。規(guī)則二：這是在控件鏈表中查找包含當(dāng)前坐標點的控件所依據(jù)的規(guī)則?？丶湵淼木S護原則主要有：（1） 整個鏈表中只有一個節(jié)點是獲得當(dāng)前節(jié)點；（2） 每個節(jié)點有唯一的焦點序列號；規(guī)則二的目標就是從控件鏈表首部開始，查找第一個包含該坐標值的節(jié)點。若找不到包含該坐標值的控件，或者控件不是當(dāng)前獲得焦點控件，則發(fā)送消息M2，M2的處理程序會進行焦點切換。以鼠標的點擊這個用戶消息的轉(zhuǎn)換過程為例：當(dāng)用戶點擊鼠標后，鼠標驅(qū)動程序會獲得鼠標的點擊狀態(tài)（左擊、右擊還是雙擊）、鼠標的點擊坐標值以及校正值，并根據(jù)這些數(shù)據(jù)填充消息發(fā)送到RTEMS系統(tǒng)消息管理器，該消息管理器將這個消息轉(zhuǎn)發(fā)到消息轉(zhuǎn)換中心，中心根據(jù)系統(tǒng)送來的消息中的設(shè)備類型判斷出是鼠標，然后根據(jù)鼠標點擊的坐標值去查找窗口注冊鏈表，依據(jù)查找規(guī)則一查出窗口，如果該窗口不是當(dāng)前窗口，發(fā)送M1消息；然后在查出的窗口的控件注冊鏈表中依據(jù)查找規(guī)則二查找包含該坐標點的控件，如果存在包含該坐標點的控件，并且該控件不是當(dāng)前獲得焦點的控件，那么發(fā)送M2消息，然后根據(jù)窗口控件信息填充發(fā)送者部分信息；如果找不到，那么發(fā)送者部分信息填寫的是窗口信息；原消息的數(shù)據(jù)信息填充消息的參數(shù)部分；至此，消息的轉(zhuǎn)換完成。 消息管理維護中心消息管理維護中心是保證消息封裝和系統(tǒng)安全性的核心部分。用戶交互的輸入和GUI內(nèi)部的消息在轉(zhuǎn)換成統(tǒng)一的消息格式之后，都將送到此處進行處理，并進行相應(yīng)的功能事件調(diào)用。管理維護中心是GUI消息通信機制的大管家，中樞所在，它實現(xiàn)了本通信機制最大的特點：消息發(fā)送者不知道消息的接收者有多少，是誰，位于何方，消息發(fā)出后會引起什么樣的后果，只管在合適的時機將正確的消息發(fā)出即可；作為消息邏輯上的接收者，事件處理部分也不知道觸發(fā)自己的消息來自何處，是何種消息，只管按要求執(zhí)行即可；這種機制不僅正確的、安全的實現(xiàn)了應(yīng)用開發(fā)者定義的兩者之間的邏輯關(guān)系，還使得兩者猶如隔河相望，霧中對視，互不相見，真正實現(xiàn)消息的完全封裝。所以該消息管理維護中心的設(shè)計關(guān)鍵是如何解決調(diào)用事件即類實例接口的問題，即不能出現(xiàn)句柄的傳遞，類A實例調(diào)用類B的接口，不出現(xiàn)顯式調(diào)用，而改以消息發(fā)送和消息處理的形式來將兩者聯(lián)系起來。這種設(shè)計方法不僅提高了系統(tǒng)運行得安全性，并且對應(yīng)用程序開發(fā)的調(diào)試部分也有很大幫助。例如：類A的m事件，類B進行自己的n事件處理時，調(diào)用了A的m事件；這樣如果B的n事件對用戶是透明的，當(dāng)用戶發(fā)現(xiàn)A的m事件被調(diào)用之后，用戶可能根本搞不清在什么地方調(diào)用了A的m事件，這會給用戶編程和調(diào)試帶來很大困難，有可能造成深層風(fēng)險；如果采用了上述機制，那么在B的n事件調(diào)用A的m事件時，它不能直接操縱A實例的句柄來調(diào)用m事件，而是把這個調(diào)用作為消息發(fā)送給A，請求調(diào)用m事件，這樣，對用戶而言，不管有多少個類似上述的隱式調(diào)用，他在找A的m事件調(diào)用的時候，只要該實例接收到的消息即可。消息管理維護中心主要的數(shù)據(jù)結(jié)構(gòu)實現(xiàn)是一個復(fù)雜的定長數(shù)組加雙重鏈表的結(jié)構(gòu)，其中數(shù)組的長度為GUI系統(tǒng)預(yù)定義的256種消息類型，數(shù)組附帶的雙重鏈表，以發(fā)送者信息為主鏈，對應(yīng)的消息處理為副鏈，在GUI系統(tǒng)整個的生命期中，維護著GUI系統(tǒng)動態(tài)的消息機制。消息管理中心主要數(shù)據(jù)結(jié)構(gòu)的維護原則是：創(chuàng)建規(guī)則：在系統(tǒng)啟動時候建立，同時插入一些系統(tǒng)預(yù)定義的消息和消息處理。插入規(guī)則：在對象創(chuàng)建時對象本身預(yù)定義的消息和消息處理的連接以及用戶通過消息處理中心提供的API接口函數(shù)connect()定義的消息和消息處理的連接，插入到經(jīng)過查找規(guī)則找到的對應(yīng)位置上，實現(xiàn)消息處理中心的動態(tài)維護。刪除規(guī)則：在對象消亡時，需要刪除掉該對象作為發(fā)送者的消息鏈，和作為消息鏈上消息處理者的節(jié)點，或者用戶通過消息處理中心提供的API接口函數(shù)disconnect()解除的某個特定的消息節(jié)點。YYYYN取類型部分數(shù)組定位=30鏈表尾處理函數(shù)調(diào)用取發(fā)送者信息主鏈尾空消息匹配副鏈尾調(diào)用事件處理函數(shù)模塊結(jié)束NNNNNY 消息處理的程序流程圖Figure Flow chart of Message Processing查找規(guī)則：根據(jù)消息號在數(shù)組中進行定位，如果是空消息或者系統(tǒng)消息，直接調(diào)用處理程序；否則，進一步根據(jù)發(fā)送者信息去查找主鏈，主鏈匹配之后，逐個調(diào)用副鏈的消息處理。消息管理維護中心就是根據(jù)上述規(guī)則，動態(tài)維護上述數(shù)據(jù)結(jié)構(gòu)。其主要任務(wù)就是解析送到的消息，找到對應(yīng)的事件處理并調(diào)用，維護系統(tǒng)預(yù)定義和應(yīng)用開發(fā)者定義的邏輯關(guān)系。 GUI Toolkit Client/Sever模式下通信的設(shè)計實現(xiàn)在傳統(tǒng)的Client/Sever結(jié)構(gòu)中，例如X windows的Client/Sever結(jié)構(gòu)，所有和設(shè)備相關(guān)的工作，都是由服務(wù)器完成的，其中包括圖形引擎中最重要的繪圖。所有客戶端的繪圖工作，不管是畫點還是畫線，都是通過 Socket 將請求傳遞到服務(wù)器，然后由服務(wù)器完成實際的繪圖工作，這樣就會導(dǎo)致系統(tǒng)效率低，速度慢?？紤]到嵌入式系統(tǒng)和工控領(lǐng)域?qū)崟r性的要求，本GUI Toolkit在設(shè)計上對傳統(tǒng)的C/S結(jié)構(gòu)進行了改動，沒有采用Socket通信機制，而是采用Message queue消息隊列來實現(xiàn)。這樣做的原因有：（1） RTEMS由于在單處理機上是單進程多任務(wù)系統(tǒng)，其在單處理機系統(tǒng)上不支持Socket通信機制；（2） 本開發(fā)小組改進了C/S間同步通信方法，減少了數(shù)據(jù)通信量，適合消息隊列實現(xiàn)。傳統(tǒng)的C/S結(jié)構(gòu)處理同步問題的原則就是：所有與設(shè)備相關(guān)的工作，主要是所有客戶端的繪圖工作，都要在服務(wù)器端進行處理。這樣就加大了Sever端進程和所有Client端進程之間的數(shù)據(jù)通信量，這樣使用以數(shù)據(jù)傳輸量大為特點的Socket機制進行通信合適，但是這會帶來整個GUI系統(tǒng)的速度和工作效率的下降，進而影響整個系統(tǒng)的實時性。經(jīng)過本小組全體人員多次的討論，決定對其同步機制的原則進行改進，具體改進如下：（1） 在客戶端開放與設(shè)備相關(guān)的工作，即繪圖都是由客戶自己完成的，服務(wù)器的任務(wù)只是告訴客戶端，什么時候能輸出，輸出的區(qū)域是什么等等。這樣就能大大提高繪圖的效率，保證系統(tǒng)的實時性。（2） 服務(wù)器利用信號量來控制各客戶程序誰有權(quán)對屏幕繪制，降低進程間通信量：當(dāng)服務(wù)器希望一個客戶程序不要向屏幕繪制時，就向它發(fā)送停止繪制信號；當(dāng)讓其繪制時，則發(fā)送允許繪制信號。從而實現(xiàn)了各客戶端的屏幕繪制同步。（3） 單獨的客戶端內(nèi)也設(shè)置內(nèi)部信號，進行剪切域之間繪制切換的控制；（4） 單獨的客戶端的繪制工作不能被打斷，這個由繪圖類（Painter類）的獨特設(shè)計實現(xiàn)。本GUI Toolkit就是采用這種改進Client/Sever模式支持多線程任務(wù)，其Sever端和多個client端采用RTEMS多線程結(jié)構(gòu)實現(xiàn)，這樣無論是在出現(xiàn)消息阻塞還是出現(xiàn)大數(shù)據(jù)量傳輸?shù)臅r候，多線程結(jié)構(gòu)都能在一定程度上保證RTEMS操作系統(tǒng)的實時性。線程之間通信采用Message queue消息隊列進行消息傳遞，在有大數(shù)據(jù)量的時候，采用共享內(nèi)存的方法進行數(shù)據(jù)傳輸。