嵌入式開發需要的不僅僅是處理器

圖1，編譯器技術的影響。HI-TECH C編譯器在採用與不採用Omniscient Code Generation(OCG)技術時的對比。

嵌入式系統工程師們總花很多時間，試圖找到最適合應用的完美元件；可惜的是，現有元件總是缺少其他元件所具備的一項或多項重要功能，因而在設計時總是要權衡利弊而無法實現完美。絕大多數情況下，完美元件只是一個夢想...

針對處理器和微控制器的選擇標準變得更加複雜。只考慮處理器核心在執行任務時的速度和效率能否符合期待是不夠的；處理器性能與其他因素息息相關，包括整合程度、支援處理器核心的週邊、採用的開發工具、要執行的任務、工程師的技巧以及系統成本等等。圖1中的幾個範例顯示了在不改變處理器核心的前提下，採用不同編譯器所帶來的不同效果。

因此，對工程人員而言，理想的元件除了具有正確的電子特性和整合週邊外，必須能在短時間內執行複雜運算，且與工程人員慣用的開發平台相容，並符合預期成本，以便工程師導入應用專案。遺憾的是，這種理想的元件是不切實際的。

持續變化的需求

一個典型專案會因多種因素變得複雜，比如開發進度表、可用資源以及開發前項目的明確程度等。若在專案開始前缺乏規劃，可能會導致設計人員在專案進行中不斷衍生出新的功能和成本需求；因此透過制定更完善、更詳細的規範，來描述專案中的硬體和軟體需求可維護專案進行的方向。

計劃和追蹤專案，攸關於專案能否按時完成，但在這個不斷變化的世界裡，不太可能預測到所有實際出現的變化，例如競爭對手以更低的價格推出功能優異的競爭產品、突發的經濟危機等。諸如此類的例子多不勝數，唯一不變的事實是需求正在不斷變化。

適應變化

減少變化既然已不可能，不如適應不斷發生的變化，因此傾向選擇採用可程式化元件的趨勢。透過軟體的變化來實現，顯然比透過修改印刷電路板(PCB)或更換零組件來的容易多了，在產品發布後甚至還能更新韌體以升級功能，或透過對應用程式客製化以實現產品的多樣化。

但是，要獲得設計上的彈性就必然要付出代價。可程式化的解決方案通常比功能固定的硬體解決方案更加昂貴。除此之外，開發環境的複雜性正日漸增加，這點也會反應在成本上。舉例來說，TechInsights最近一項研究表明，目前開發趨勢不僅要在單個設計中採用多個處理器，而且要在同一設計中採用多個不同的處理器。

上述趨勢加重了嵌入式系統工程師的負擔，因此實際一點的作法是透過標準化單一處理器核心，滿足設計人員大多數的設計需求，若不同供應商的元件皆配備標準核心，則設計人員可視應用需要，更換不同元件。然而，選擇微控制器所涉及的因素遠不止一個處理器核心這麼簡單。

完整的開發平台

根據有限的需求來標準化特定處理器核心是不錯的策略，但事實證明，沒有一個架構能滿足所有要求。根據對工程師的調查發現，開發工具在選擇的標準中排名最高。

在工程人員僅熟悉1個或少數幾個開發環境的限制下進行選擇，如何縮短學習週期，並發揮工程技巧和能力以進一步優化設計是必要的。進一步來說，開發人員應考慮這個生態系統內所支援的產品範圍，以及能否在不影響整個生態系統的情況下更換零組件，比如編譯器、元件或處理器核心、週邊、軟體資料庫等等。

無論是採用32位元微控制器為主要控制器的開發應用，還是採用小型8位元週邊微控制器執行系統基本的電源管理，開發環境都應保持不變。如果需要將目前使用的16位元微控制器升級為性能更高的32位元微控制器時，週邊的功能差異也不能太大。

選擇元件需要考慮的另一因素是，出現新產品後能否重複使用現有程式碼。約有90%的工程師會重複使用以前的程式碼，其中大部分程式碼均為內部開發。大多數工程師使用C或C++進行嵌入式開發，這使韌體從8位元升為32位元或者從32位元降至16位元微控制器的過程變得異常困難，如果最初開發程式碼時並未考慮元件間的轉換，問題將更加凸顯。因此，包括資料庫、硬體工具和元件系列在內的開發生態系統應該儘量實現這種無縫轉換。

其他選擇標準包括是否提供與整個元件系列保持大體一致的參考應用文件、能否支援並回覆工程師對應用元件的問題，並能持續透過服務窗口轉達客戶需求的變化給設計團隊，也都是需要考慮的因素。

總結

變化是永恆的。應對變化的最好策略是迎接變化並做好規劃。標準化有助於降低和適應需求變化帶來的影響。不過，需要標準化的不只是處理器核心，而是整個開發生態系統。針對應用設計的選擇標準還應包括以下因素：
●軟體開發環境。
●開發生態環境中，性能和成本皆相容的元件範圍。
●不同產品週邊之間的相容性。
●在生態系統中支援的硬體開發工具。
●應用文件的一致性。
●服務窗口所提供的支援以及通暢的溝通管道。
●最重要的是，能否在生態系統內部轉移以適應變化，並重複使用現有程式碼和IP。

(本文作者為Microchip Technology Inc.產品行銷及應用總監)