隨著32位多核處理器應(yīng)用逐漸走熱，設(shè)計者正面臨著新的挑戰(zhàn)，  業(yè)內(nèi)指出面向角色(actor-oriented)的圖形化方法是更適合嵌入式軟件設(shè)計的工具。NI  的LabVIEW嵌入式開發(fā)模塊是LabVIEW圖形化編程環(huán)境的一款全新附加模塊，通過這個軟件和圖形化系統(tǒng)設(shè)計的理念，原先無法利用到嵌入式編程的工程師們都可以進(jìn)入32位微處理器的領(lǐng)域之中。通過LabVIEW中附加的狀態(tài)圖、控制圖表、信號處理庫函數(shù)等這一完整的工具來設(shè)計它們的應(yīng)用，以解決各種問題。本文對該開發(fā)工具進(jìn)行了介紹。

　　隨著嵌入式系統(tǒng)變得越來越復(fù)雜，設(shè)計者正面臨著新的挑戰(zhàn)：隨著基于32位微控制器(MCU)的嵌入式系統(tǒng)的成本向16位系統(tǒng)逐步接近，在許多應(yīng)用中8位和16位微控制器正逐步讓位給擴展性更佳，性能更好的32位片上系統(tǒng)(SoC)。此外，由于單純通過CPU的性能提升來增加整個系統(tǒng)的性能已經(jīng)不是一種持久的發(fā)展趨勢了，所以主要的處理器制造商已經(jīng)轉(zhuǎn)向了多架構(gòu)。從Dell在幾個月前推出的多處理器的臺式計算機，就可以看到這種趨勢。從消費者和用戶的觀點上來看，處理性能的提升是一樣的。但是，從一個嵌入式系統(tǒng)開發(fā)者的觀點來看，設(shè)計將變得更加復(fù)雜，因為您必須了解如何在多處理器環(huán)境下開發(fā)和分割您的應(yīng)用。根據(jù)十年前的估計，嵌入式系統(tǒng)的平均代碼量為10萬行。到2001年，這個數(shù)字實際已經(jīng)超過了100萬，而現(xiàn)在的數(shù)字估計為500萬。

　　現(xiàn)在我們將視線轉(zhuǎn)移到當(dāng)前嵌入式系統(tǒng)的開發(fā)工具上來，隨著復(fù)雜度的逐漸上升，現(xiàn)在傳統(tǒng)工具很難降低編程工作的復(fù)雜度，嵌入式領(lǐng)域需要另一種方法來應(yīng)對這些挑戰(zhàn)。挑戰(zhàn)不僅是工具方面的，還有解決問題的途徑：基于文本編程的嵌入式應(yīng)用開發(fā)在將來不可能解決這些問題。這已經(jīng)是許多業(yè)內(nèi)的共識;Edward  Lee博士是加州大學(xué)伯克利分校嵌入式研究方面的者，他指出現(xiàn)在嵌入式系統(tǒng)的開發(fā)手段如基于文本編程和面向?qū)ο蟮墓ぞ叨茧y以用來構(gòu)建嵌入式實時系統(tǒng)，因為面向?qū)ο蠛茈y直觀地表達(dá)時間和平行性(parallelism)，而時間和平行性或并行(concurrency)在現(xiàn)在的嵌入式系統(tǒng)中是必不可少的。Lee博士提出面向角色(actor-oriented)的圖形化方法是更適合嵌入式軟件設(shè)計的工具。

　　雖然嵌入式系統(tǒng)的挑戰(zhàn)越來越嚴(yán)峻，但是現(xiàn)在已經(jīng)有了許多解決的方向。許多供應(yīng)商采取了將底層工具的設(shè)計抽象出來的辦法。這種方法每前進(jìn)一步，都會吸引更多的用戶。另一個方向是可以更徹底地解決面臨的挑戰(zhàn)，也就是向基于平臺的工具轉(zhuǎn)移，它能夠更好地表達(dá)整個系統(tǒng)，而減少與特定硬件的相關(guān)性，這使得更多的軟件設(shè)計容易理解并被重復(fù)使用，而從基于文本的工具向圖形化工具的轉(zhuǎn)移則可以直觀地表達(dá)系統(tǒng)，并解決系統(tǒng)的挑戰(zhàn)。圖形化系統(tǒng)設(shè)計(Graphical  System  Design)的理念就是源于這些趨勢。通過簡化嵌入式編程的復(fù)雜性，它降低了對領(lǐng)域在嵌入式設(shè)計流程中各個步驟的要求;同時提供了從設(shè)計、原型到部署的一條捷徑，使得工程師和科學(xué)家們可以更快速地進(jìn)行重復(fù)設(shè)計。

　　盡管市場上的工具都在向圖形化的方向轉(zhuǎn)變，但由于它們是針對特定領(lǐng)域特定應(yīng)用的工具，所以仍舊受到自身的限制，而這是不足以解決行業(yè)將要面臨的挑戰(zhàn)的。事實上，現(xiàn)在的嵌入式系統(tǒng)市場與八十年代早期的臺式計算機市場有很多相似之處，其中的一個特點就是非常分散?，F(xiàn)在市場所需的是一種完全的圖形化編程語言，提供足夠的靈活性和功能，以滿足更廣泛應(yīng)用的需求。因此，圖形化系統(tǒng)設(shè)計的關(guān)鍵因素是圖形化編程。

　　將設(shè)計方法學(xué)直接應(yīng)用于實現(xiàn)

　　自1986年誕生以來，LabVIEW圖形化編程語言已經(jīng)開始簡化了系統(tǒng)的復(fù)雜性，并在同一個平臺上提供采集、分析和顯示等功能，在使用計算能力對處理過程自動化的同時，允許在研發(fā)原型，制造和測試過程中對軟硬件的重用，彌補了原先因為原型、制造和測試三個步驟間因工具不同而造成的這一鴻溝。在所有涉及到數(shù)據(jù)采集和控制的領(lǐng)域里，LabVIEW圖形化方式都已經(jīng)成為標(biāo)準(zhǔn)的開發(fā)工具。從那時開始，我們就一直向這個編程環(huán)境添加功能上的改進(jìn)，現(xiàn)在LabVIEW在已有的定時循環(huán)結(jié)構(gòu)上新加了硬件定時功能，它是一種表示時間和并行的語義?，F(xiàn)在，我們就可以通過點擊來設(shè)置操作系統(tǒng)優(yōu)先級，延時，循環(huán)速率等等;回想在文章前面所提到的向多處理器轉(zhuǎn)移的趨勢，現(xiàn)在我們可以憧憬使用可擴展的直觀圖形化編程，來開發(fā)應(yīng)用，并將處理過程分配到不同的處理器上。

　　新的NI LabVIEW嵌入式開發(fā)模塊(LabVIEW Embedded Development  Module,)是LabVIEW圖形化編程環(huán)境的一款全新附加模塊，通過這個軟件和圖形化系統(tǒng)設(shè)計的理念，原先無法利用到嵌入式編程的工程師們都可以進(jìn)入32位微處理器的領(lǐng)域之中。通過LabVIEW中附加的狀態(tài)圖、控制圖表、信號處理庫函數(shù)等這一完整的工具來設(shè)計它們的應(yīng)用，以解決各種問題。

　　領(lǐng)域-在某個科學(xué)或工程領(lǐng)域的，但不一定是嵌入式的程序員-一般使用不同的模型或工具解決他們學(xué)術(shù)上或工程上的問題。例如，開發(fā)引擎控制單元(ECU)的工程師可能使用狀態(tài)圖來對引擎控制單元的功能進(jìn)行圖形化的描述。這位工程師可能是一個控制理論方面的，但是卻可能沒有任何嵌入式或C編程方面的經(jīng)驗。直到現(xiàn)在，嵌入式應(yīng)用的實現(xiàn)仍然需要深入了解關(guān)于嵌入式編程工具，如C語言等方面的知識。因此，很多領(lǐng)域要實現(xiàn)他們的解決方案，甚至只是簡單的驗證一個概念仍然要依賴專門的嵌入式開發(fā)人員。這個存在于領(lǐng)域和嵌入式程序員之間的鴻溝，使得開發(fā)時間增加，而且容易在系統(tǒng)中引入錯誤。

　　LabVIEW嵌入式開發(fā)模塊在設(shè)計和實現(xiàn)間的鴻溝之上架起了一座橋梁。領(lǐng)域的現(xiàn)在可以使用相同環(huán)境快速地設(shè)計算法，對定制的設(shè)計進(jìn)行原型設(shè)計，將他們的解決方案在所選的目標(biāo)上實現(xiàn)，并進(jìn)行調(diào)試——所有這些過程都是通過圖形化方式實現(xiàn)的。

　　開發(fā)與目標(biāo)無關(guān)的代碼

　　嵌入式目標(biāo)本身要求程序員在編寫代碼之前對目標(biāo)有深入的了解。程序需要知道板卡上各種關(guān)于內(nèi)存映射和寄存器的信息，才能在板卡上執(zhí)行他們的代碼。另外，大部分代碼是專為某一特定目標(biāo)編寫的。這樣，在一塊板卡上使用不同的微處理器或是不同的外圍設(shè)備，可能就需要重新編寫大部分已有的代碼，或是完全從頭開始。這意味著終產(chǎn)品的擴展性方面是有缺陷的。