一、避免MCU或編程語言干擾設計

? ? ? ?作為經驗豐富的嵌入式系統的開發人員，既有大型系統的經驗(波音777飛行控制)又有小型單人項目(筆記本電腦熱風扇控制)經驗，應避開單臺機器或語言的具體利弊，將更多的時間花在應用程序設計和構建上，并且獨立于語言和CPU內核。這方面部分來自于對類似系統的工作，只是“再用于“下一個項目(雖然要求完全不同，并且切換到了微控制器)。我也參與過由幾個獨立的設備組成的系統，每個設備都有自己的程序和微控制器，各部分經常在不同的子項目之間來回使用：某個子項目中的編碼器可能是另一個項目的測試器，或當完成自己的子項目的編碼后，會投入另一個子項目，以幫助完成項目。缺乏基于系統的設計方法會覺得這些情況很困難，難以按照計劃完成。通過獨立的系統設計可避免機器依賴性，讓設計復用和基于團隊的設計不僅成為可能，而且加大了成功機會(如以后的增加要求)。

　　最近的一個項目是我更加疑慮，幾乎每次都是，必須使設計適應(有時根本就是)所選的語言和機器。我們已經以某個系統架構和設計開始，只是按一般方式考慮了集成微控制器及其外圍設備，我們只關注我們需要什么并不關心它是如何實現的，至少我們是這么認為的。我們選擇了一些非常專業外設的新器件，并且開始編碼時，發現需要花費大量的時間來了解如何構建硬件，以及如何根據需求最好地利用。當我們發現好的方式來利用設備的某特征時，設備的此特點通過代碼嵌入了系統級設計。我們已不再堅持我們的系統，不得不讓機器和具體操作改變了系統設計。于是只好停下來檢查問題和實施方案，通過系統重新設計分離出依賴機器的“修復”，然后將“修復”融入系統四周的“包裝”中。

　　當設計某個應用時(甚至單一微控制器)，以調溫器為例，有一個創建好了的系統級視圖，描述了硬件和實施某種方式的應用程序。該視圖用于多種用途，例如，可作為與高層管理人員或另一個小組進行交流的工具(不希望知道所有細節)，如自動化測試人員。如果僅將其視為“視圖”而不是系統設計，并且實施不是從系統設計自上而下，而是將其用作起點，則問題就出現了。考慮圖1所示的溫控系統。

?

　　顯示系統相對簡單，卻反映了許多嵌入式產品設計。在“溫度傳感”部分包含溫度輸入，其輸出進入主系統“控制邏輯”部分。“控制邏輯”的其它輸入是標記“用戶輸入”的部分，代表人機接口，大概設置了恒溫器的溫度調節。“控制邏輯”部分根據這些輸入確定了如何命令供暖、通風和空調(HVAC)系統，以保持恒溫器設定的溫度，將這些命令發送到“熱與冷命令”部分。最后一個部分是“顯示輸出”，將當前系統狀態傳遞到用戶。當前系統狀態的一部分是恒溫設置，另一部分是最新的溫度讀數，最后部分是正在執行的命令，以迫使溫度返回恒溫設置(即加熱、冷卻和/或打開或關閉風扇)。

　　正如前面所述，這是一個直接和相對簡單的應用，非常簡單以至于不需要考慮系統，而是很自然地跳到實施(我相信大多數讀者甚至可以說出最喜歡的微控制器供應商的型號)。可以是用于次級市場的高端PC游戲圖形系統的墻恒溫器或溫度管理裝置。用于墻恒溫器的微控制器的具體實施基本不需用于圖形系統。重點是，無論設計顯得多么簡單，都有很好的理由先設計系統，然后實現它。將其盡量設計成適合通常應用。

開始時，需要考慮理想的系統設計，然后生成layers，在理想的系統和實際實施之間構建wrappers(有時是雜亂的)。“控制邏輯”部分作為框圖的核心是有充分理由的-因為它是系統的內核。周圍的每個部分都服務于“控制邏輯”部分，要根據需要提供“服務”。

　　應自“溫度傳感器”部分開始。其理由是獲得當前/瞬時溫度，并以一致的格式提供出來。從“控制邏輯”的角度來看，其作用是“獲取溫度”，并以格式化的值(xxx.xx攝氏度)返回當前溫度值。溫度傳感器部分的硬件wrappers將包括實施中任何需要用來將原溫度傳感輸入“翻譯”成預期格式的攝氏度。這可能意味著需要考慮獲得新讀數的最佳時間，如果溫度讀數中有太多的噪音(無論何種原因)，應添加過濾算法，并且如果溫度硬件出現故障，應采用決策邏輯。重點是，“溫度傳感器”部分的輸出是什么，而且傳遞到“控制邏輯”應為理想的溫度，所有的噪音，實際隱藏的細節都應很容易的由wrapper代替。

　　如果設計需要從系統中三個不同的點測量三個溫度值(對于計算機箱內的計算機很普遍)怎么辦?處理這三個溫度是控制邏輯問題(例如，何時多路輸出也將受到控制)?如果是這樣，從1個溫度轉換到3個溫度首先意味著“溫度傳感器”部分要更新，以提供3個溫度和為每個溫度實施創建的wrappers(允許多種類型的輸入)，然后控制邏輯也因為多個輸出而更新。這可能意味著三個不同的“GetTemperature_n”服務或需要更新服務以確定是識別哪個溫度的參量。

　　如果三個溫度僅僅用于加權以得到一個“更真實”的系統溫度，控制邏輯不需要改變，只需將含wrappers的溫度傳感塊以統一格式輸入這三個溫度，然后通過一個wrappers來對這三個溫度進行加權，生成控制邏輯所需的單一溫度。這種方法易于包含來自不同的溫度輸入(例如，圖形處理器的二極管結測量和連接到PCB的模擬熱敏電阻)，因為wrappers將系統邏輯與硬件隔離開。

　　讓我們以兩個不同的實現例子驗證這個論點：一個用于墻恒溫器，另一個是顯卡上的溫度控制子系統。首先對于墻恒溫器，如圖2所示，假定使用基于8051的賽普拉斯PSoC3設備。“溫度傳感器”部分的硬件由連接到ADC(16位Δ-Σ轉換器)的熱敏電阻組成。“用戶輸入”部分的硬件由5個常開按鍵開關組成，一邊連接到電路接地端，另一邊連接到含內部上拉電阻的5輸入數字端口。“熱和冷命令”模塊的硬件部分包括三個功率場效應管，由配置為開漏低輸出的3輸出端口驅動。最后，“顯示輸出”塊的硬件實現是串行字符液晶顯示器，能夠根據需要顯示字母數字字符串。

?

　　對于第2個應用，即顯示卡，將用戶輸入從離散開關變為I2C基于寄存器的從接口(由主CPU而不是人類直接控制)，并將串行LCD顯示變為SPI-從控制顯示器(使用一系列的寄存器和指令，可能是安裝在主計算機外殼前面板上的遠程變頻顯示，未安裝到顯卡上)。溫度輸入和HVAC命令保持不變。圖3顯示了早期實施的變化，假定使用基于8051的賽普拉斯PSoC3設備。

?

　　用戶輸入的兩種實現均可服務于“GetThermostatSetting”、“IsHeaterEnabled”、“IsCoolerEnabled”和“IsFanOn”。對于第一個墻恒溫器應用，“用戶輸入”將數字端口包裝到所列的服務中，當設備被調用時，提供端口的實時讀數(一種可能的實施)。對于另一個應用，基于I2C從機的實現，相同的服務將來自I2C主機寫入的寄存器的最新值返回到“控制邏輯”部分，也許經常返回也許僅在上電時返回。并且這些實現還有很多其它特點，包括用作切換鍵的墻上按鈕開關而不是瞬間讀數，甚至在“用戶輸入”部分的wrappers深層進行邊沿觸發異步處理。

　　綜合上述的關鍵是：系統設計隱藏了硬件細節;硬件和實施細節被系統設計包裝并隱藏。通過外端設計(即代碼)的實施細節，可以保護這些應用實現時避免分裂，可以做到個性化的設計，權衡利弊，保證項目成功交付，并仍然能夠提供可復用性和組設計。不要讓賣方牽引注意力——先設計系統，然后加強保護系統設計實現細節不被抄襲。