隨著32位多核處理器應用逐漸走熱，設計者正面臨著新的挑戰， 業內專家指出面向角色（actor-oriented）的圖形化方法是更適合嵌入式軟件設計的工具。NI 的LabVIEW嵌入式開發模塊是LabVIEW圖形化編程環境的一款全新附加模塊，通過這個軟件和圖形化系統設計的理念，原先無法利用到嵌入式編程的工程師們都可以進入32位微處理器的領域之中。通過LabVIEW中附加的狀態圖、控制圖表、信號處理庫函數等這一完整的工具來設計它們的應用，以解決各種問題。本文對該開發工具進行了介紹。
　　隨著嵌入式系統變得越來越復雜，設計者正面臨著新的挑戰：隨著基于32位微控制器（MCU）的嵌入式系統的成本向16位系統逐步接近，在許多高級應用中8位和16位微控制器正逐步讓位給擴展性更佳，性能更好的32位片上系統（SoC）。此外，由于單純通過CPU的性能提升來增加整個系統的性能已經不是一種持久的發展趨勢了，所以主要的處理器制造商已經轉向了多核心架構。從Dell在幾個月前推出的多處理器核心的臺式計算機，就可以看到這種趨勢。從消費者和用戶的觀點上來看，處理性能的提升是一樣的。但是，從一個嵌入式系統開發者的觀點來看，設計將變得更加復雜，因為您必須了解如何在多處理器環境下開發和分割您的應用。根據十年前的估計，嵌入式系統的平均代碼量為10萬行。到2001年，這個數字實際已經超過了100萬，而現在的數字估計為500萬。
　　現在我們將視線轉移到當前嵌入式系統的開發工具上來，隨著復雜度的逐漸上升，現在傳統工具很難降低編程工作的復雜度，嵌入式領域需要另一種方法來應對這些挑戰。挑戰不僅是工具方面的，還有解決問題的途徑：基于文本編程的嵌入式應用開發在將來不可能解決這些問題。這已經是許多業內專家的共識；Edward Lee博士是加州大學伯克利分校嵌入式研究方面的領先者，他指出現在嵌入式系統的開發手段如基于文本編程和面向對象的工具都難以用來構建嵌入式實時系統，因為面向對象很難直觀地表達時間和平行性（parallelism），而時間和平行性或并行（concurrency）在現在的嵌入式系統中是必不可少的。Lee博士提出面向角色（actor-oriented）的圖形化方法是更適合嵌入式軟件設計的工具。
　　雖然嵌入式系統的挑戰越來越嚴峻，但是現在已經有了許多解決的方向。許多供應商采取了將底層工具的設計抽象出來的辦法。這種方法每前進一步，都會吸引更多的用戶。另一個方向是可以更徹底地解決面臨的挑戰，也就是向基于平臺的工具轉移，它能夠更好地表達整個系統，而減少與特定硬件的相關性，這使得更多的軟件設計容易理解并被重復使用，而從基于文本的工具向圖形化工具的轉移則可以直觀地表達系統，并解決系統的挑戰。圖形化系統設計（Graphical System Design）的理念就是源于這些趨勢。通過簡化嵌入式編程的復雜性，它降低了對領域專家在嵌入式設計流程中各個步驟的要求；同時提供了從設計、原型到部署的一條捷徑，使得工程師和科學家們可以更快速地進行重復設計。
　　盡管市場上的工具都在向圖形化的方向轉變，但由于它們是針對特定領域特定應用的工具，所以仍舊受到自身的限制，而這是不足以解決行業將要面臨的挑戰的。事實上，現在的嵌入式系統市場與八十年代早期的臺式計算機市場有很多相似之處，其中的一個特點就是非常分散?，F在市場所需的是一種完全的圖形化編程語言，提供足夠的靈活性和功能，以滿足更廣泛應用的需求。因此，圖形化系統設計的關鍵因素是圖形化編程。
　　將設計方法學直接應用于實現
　　自1986年誕生以來，LabVIEW圖形化編程語言已經開始簡化了系統的復雜性，并在同一個平臺上提供采集、分析和顯示等功能，在使用計算能力對處理過程自動化的同時，允許在研發原型，制造和測試過程中對軟硬件的重用，彌補了原先因為原型、制造和測試三個步驟間因工具不同而造成的這一鴻溝。在所有涉及到數據采集和控制的領域里，LabVIEW圖形化方式都已經成為標準的開發工具。從那時開始，我們就一直向這個編程環境添加功能上的改進，現在LabVIEW在已有的定時循環結構上新加了硬件定時功能，它是一種表示時間和并行的語義?，F在，我們就可以通過點擊來設置操作系統優先級，延時，循環速率等等；回想在文章前面所提到的向多處理器轉移的趨勢，現在我們可以憧憬使用可擴展的直觀圖形化編程，來開發應用，并將處理過程分配到不同的處理器上。
　　新的NI LabVIEW嵌入式開發模塊（LabVIEW Embedded Development Module，）是LabVIEW圖形化編程環境的一款全新附加模塊，通過這個軟件和圖形化系統設計的理念，原先無法利用到嵌入式編程的工程師們都可以進入32位微處理器的領域之中。通過LabVIEW中附加的狀態圖、控制圖表、信號處理庫函數等這一完整的工具來設計它們的應用，以解決各種問題。
　　領域專家－在某個科學或工程領域的專家，但不一定是嵌入式的程序員－一般使用不同的模型或工具解決他們學術上或工程上的問題。例如，開發引擎控制單元（ECU）的工程師可能使用狀態圖來對引擎控制單元的功能進行圖形化的描述。這位工程師可能是一個控制理論方面的專家，但是卻可能沒有任何嵌入式或C編程方面的經驗。直到現在，嵌入式應用的實現仍然需要深入了解關于嵌入式編程工具，如C語言等方面的知識。因此，很多領域專家要實現他們的解決方案，甚至只是簡單的驗證一個概念仍然要依賴專門的嵌入式開發人員。這個存在于領域專家和嵌入式程序員之間的鴻溝，使得開發時間增加，而且容易在系統中引入錯誤。
　　LabVIEW嵌入式開發模塊在設計和實現間的鴻溝之上架起了一座橋梁。領域的專家現在可以使用相同環境快速地設計算法，對定制的設計進行原型設計，將他們的解決方案在所選的目標上實現，并進行調試——所有這些過程都是通過圖形化方式實現的。
　　開發與目標無關的代碼
　　嵌入式目標本身要求程序員在編寫代碼之前對目標有深入的了解。程序需要知道板卡上各種關于內存映射和寄存器的信息，才能在板卡上執行他們的代碼。另外，大部分代碼是專為某一特定目標編寫的。這樣，在一塊板卡上使用不同的微處理器或是不同的外圍設備，可能就需要重新編寫大部分已有的代碼，或是完全從頭開始。這意味著最終產品的擴展性方面是有缺陷的。
　　
　　圖1：LabVIEW 開發界面
　　但是，使用LabVIEW嵌入式開發模塊，工程師和科學家們不需了解最終的目標，就可以進行代碼開發，因為軟件生成的是LabVIEW應用的ANSI C代碼，而不是針對某個特定目標的二進制代碼。LabVIEW嵌入式方式是一個開放的框架，它可以整合任意的第三方工具鏈，將生成的C代碼、LabVIEW實時庫函數和板卡支持程序包（BSP）編譯成為針對某一目標并能在這個目標上運行的二進制代碼。BSP是一種作為C代碼與板上外圍硬件接口的底層代碼。因此，如果板卡需要升級，工程師可以簡單地將不同的BSP鏈接到LabVIEW中，在現有的圖形化代碼上作一小部分改動就可以完成。