如何使用LabVIEW開(kāi)發(fā)基于32位處理器的嵌入式系統？

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

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

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

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

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

將設計方法學(xué)直接應用于實(shí)現

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

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

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

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

開(kāi)發(fā)與目標無(wú)關(guān)的代碼

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