一個軟件工程師的軟硬件協同開發應對經驗淺談

我從事嵌入式業務已有很多年時間了，但還是不清楚“協同開發”是否是指管理人員夢想實現超高效項目開發進度的一種方式，還是說對于軟件開發人員而言是一種折磨?；蛟S它只是意味著軟件開發與硬件平臺設計齊頭并進吧。這除了意味著軟件人員的苦難之外，我真不清楚還意味著什么。

在嵌入式領域，經常要為正在設計中的電路板或芯片同時編寫軟件。有時是為Mentor Graphics或Cadence Design Systems等EDA廠商仿真環境中復雜的ASIC設計而編寫軟件。有時則是為Xilinx或Altera等公司功能強大的FPGA設計而編寫軟件。FPGA器件帶有與標準和定制IP模塊相連的嵌入式微處理器內核。還有的時候是為了可編程片上系統編寫軟件，這種可編程片上系統將可編程數字/模擬功能和微控制器完美集成在一起（如賽普拉斯的PSoC器件）。這些功能都非常強大，能實現難以置信的創新，但同時也會帶來痛苦，那就是硬件可能隨時發生變化，而軟件開發人員則難以招架。

我不是建議放慢創新步伐，而是說應該給軟件工程師一個喘氣的機會。但事實上剛好相反。硬件工具需要更好地與軟件IDE集成在一起才能加速產品上市進程。而設計人員需要更多工具和方法讓應用不受硬件變化的影響。我不是說向設計中添加或從中移除主要的通信模塊。如果您的真需要添加或移除主要通信模塊，那么您的軟件工程師真該找點別的事干了，因為這意味著硬件設計還根本沒就位呢。我這里說的變化都是設計周期較晚階段對于已定義的功能模塊進行的微小改變，比方說寄存器地址變動、比特位被重新定義、緩沖區大小改變等。這些“小變化”也會影響到軟件，進而可能造成產品缺陷，甚至在忘記硬件變化原因時還要對軟件進行長時間返工。

軟件工程師，現在到了我們奮起反擊的時候了！以下給出了針對目標不斷變化的情況如何靈活進行應用開發的三點建議。在開始新的項目之前，不要忘掉這些建議！

1 不要編寫HAL，要生成它！

我們需要的第一個變化就是讓硬件開發工具生成軟件接口，也就是通常所說的硬件適配層（HAL）。HAL應包括能可靠地初始化可編程硬件的啟動代碼，并提供API接口以支持系統的軟件控制。HAL不僅簡化了固件開發，還能將實施從接口中抽象出來。這就意味著硬件的微小變化不會對固件造成影響。

HAL中其實沒什么新概念，許多經驗豐富的設計人員已經明智指出，常量、函數和變量都應采用一致的、直觀的命名規范。不過，對于FPGA、CPLD和PSoC等可編程器件而言，我們還要將此規范進一步擴展，也就是HAL要由硬件設計工具生成，否則軟件工程師怎么才能確?？煽康慕涌谀?？

在固定或變化很少的環境中（比如說固定功能MCU或大規模ASIC項目），我們可將HAL視為一套獨立的API，可將其作為硬件設計變化的一部分進行修改。不過，對于現代化的可編程器件而言，硬件一天會變化好幾次。手動HAL維護與當前情況根本不相匹配，肯定會在實施階段出現錯誤，更別說要對軟件工程師帶來多大痛苦和折磨了！我認為，HAL自動生成應為任何可編程平臺的必備要求。

圖1：PSoC Creator工作區域抓屏，其中我們看到采用FanController模塊和一對比較器（Comp_Hi）和（Comp_Lo）的系統控制器設計所用的API文件（HAL）。

2 集成自己最喜歡的IDE

可編程器件為創新帶來了巨大機遇，但往往設計硬件所需的工具會對正常軟件開發實踐造成影響。工程師往往不得不使用簡單、功能欠佳的工具，而且不能與現有的流程很好地結合。

大多數協同設計環境都是從硬件設計工具演變而來，這些工具多年來一直支持ASIC和FPGA或CPLD流程。隨著嵌入式CPU越來越普及，為工具產品組合添加軟件開發功能的需求變得非常明顯，這樣，一種工具就能支持軟硬件兩個領域，但對兩個領域各自而言又都不夠理想。在此情況下，工程師就會在兩個領域都會減少特性選擇，甚至喪失特性選擇。

解決方案不是讓工具廠商提供業界領先的調試器，將其捆綁到硬件設計工具中，就宣布成功，然后奇怪軟件工程師怎么還在不停地抱怨。為以硬件為中心的工具添加源代碼編輯器并調試特性，這并不能真正解決問題，因為工具仍沒有集成到用戶的流程中。源控制接口、軟件測試套件、自動化構建等是目前開發人員每天都要接觸的工作，將硬件設計工具集成到他們的日常工作中才是真正的挑戰。

正確的做法根本不是集成調試器、編輯器或整個IDE，而是要讓軟件開發人員從項目一開始就能在自己真正喜歡并使用的傳統IDE開發環境中開展工作。硬件設計人員或許仍需要工具中的軟件特性來創建并運行小型測試程序，但真正的應用開發應當始終在工程師首選的IDE中進行。

如果想要滿足這一要求，一個辦法就是要能夠將項目從一個工具導出到另一個工具。舉例來說，賽普拉斯的PSoC Creator能夠將PSoC設計直接導入到Keil μVision工具中。在許多可編程系統中，“硬件”事實上是作為數據塊提供，能在啟動時被編程到器件中，以創建配置好的器件。對于軟件而言，它僅僅是數據，因此導出設計只需硬件工具為目標產品生成項目文件，再用HAL源文件和初始化代碼植入即可。應用隨后就能在硬件頂層上進行構建，而且不會干擾現代化環境中使用的自動化測試和源控制系統。

圖2：PSoC Creator的“IDE 導出”GUI。本對話框用來創建和更新用于應用開發的Keil μVision項目。

當然，對于動態的硬件平臺而言，一次性導出不是完整的解決方案，還必須提供無縫更新設計的特性，而且不會破壞應用。對于支持庫的IDE來說，更新過程很簡單，因為設計可被拆分為應用項目和配置庫，這就能將應用完全隔離開來，而且能讓包含配置數據和HAL的硬件庫在設計變化時自動更新。

圖3：以上導出的系統控制器項目在Keil μVision中打開，可用于應用開發。

3 超越軟件范疇的調試

設計人員所需的第三個特性就是改進調試。在現代化器件中，“處理器”的定義不僅限于CPU的寄存器和指令集。處理器芯片集成了各種額外的片上功能，比如說常見的通信模塊和標準接口，此外還包括無所不在的定時器和計數器，以及為軟件提供數字接口的模擬功能，有時也包括定制邏輯和可切換的路由功能等。這種可定制性說到底正是我們最初選擇協同設計的原因所在。調試器如果只支持CPU，就會讓軟件開發人員非常失望。我們需要圍繞硬件認真解決以下問題：硬件啟動了嗎？時鐘啟動并穩定了嗎？外設在正常工作嗎？通信模塊是否生成中斷？能否發送和接收數據？能否在內部總線上正常工作？

如果這聽起來就夠嚇人的話，我還沒說到從調試器改變硬件呢，這其實是讓人的角色在迫害者和受害者之間轉變。我需要符號化外設硬件的存取方式，這樣我就能監控和控制影響應用的狀態變化。

當然，符號信息必須從硬件工具中生成，就好像上述HAL一樣。通過簡單添加這一點，調試過程就變得更加簡單，功能也更加強大了。之所以說更簡單，是因為我們不再需要一直查詢文檔去尋找并確認調試器中要注意哪些關鍵寄存器的地址了。而之所以說更強大，是因為現在它能支持更為復雜的調試。除了快速獲得外設模塊狀態快照之外，有時我們還能從調試器控制功能塊，無需編寫代碼以編程方式重建情境就能了解情境工作的具體情況。

交換此信息的典型方法就是讓IDE使用由硬件工具生成的XML文件。ARM CMSIS-SVD（軟件接口標準——系統視圖描述）標準就是一個很好的例子。它是基于XML的硬件描述，旨在讓調試器支持高度集成的微控制器。CMSIS是一種面向ARM Cortex微控制器的HAL的標準定義，得到了眾多廠商的廣泛采用。SVD擴展主要針對硬件描述，如寄存器、存儲器、外設等，讓從事可編程系統開發的人員真正地大獲裨益。

圖4：這是一小段XML，介紹了賽普拉斯PSoC Creator調試器有關CAN實施中一個寄存器的情況。CAN_CSR_ERR_SR寄存器的地址、大小和描述均已定義，在寄存器中有5個字段，定義了名稱、大小和存取權限。

共享硬件定義的一個重要因素就是能夠定義外設寄存器，進而言之，則能提供面向寄存器中字段的存取權限，從而確保調試器認真對待讀/寫可修改的位。硬件給我們提供clear-on-read位和zero-to-toggle位以及各種其它晶體管能夠感應但是軟件很難應付的狀態處理接口。只有對硬件進行良好的機器生成定義，我們才能保證用戶在外設模塊上調試寄存器或個別位時不至于浪費時間，或導致意外結果。

有了可編程硬件的高級視圖，我們不僅能檢查狀態寄存器和錯誤狀態，還能實現更多功能。舉例來說，如果硬件支持寄存器控制的開關，能實現外設I/O到器件引腳的靈活路由，那么軟件開發人員就能從調試器操控器件的內部布線！有些人聽到這里可能感覺有些嚇人，不過如果SVD信息正確生成，那么我們就能限制允許的變化，確?！鞍踩摹本庉?，比如說數字信號上的多路復用器通道選擇或兩個物理引腳之間的模擬輸入切換。

硬件工具為軟件開發人員生成調試信息，有望顯著縮短應用開發時間。不僅如此，重要的是，我們還有機會在早期檢測出硬件設計錯誤，因為軟件開發人員發現混亂和代碼重寫的不正常情況下更有可能發現意料之外的行為。

面向可編程器件的完整產品

現在，“完整產品”的概念已得到充分地理解和廣泛地接受，也成了成功的重要因素。只有最佳的工具或最出色的芯片已經不夠了。我們今天使用的可編程解決方案形式多樣：可能是全定制的ASIC，其在高度專業化的解決方案中集成了ARM內核和多個IP模塊；也可能是更加通用的平臺，其集成了可編程芯片和設計工具，諸如Altera和賽靈思推出的FPGA解決方案，或賽普拉斯半導體公司推出的PSoC器件等。雖然這些環境千差萬別，但都面臨著同樣的問題——不能將硬件修改有效地遷移到軟件領域，從而影響應用開發。

我認為，這個問題的根源在于項目中使用的硬件設計工具和IDE采用了狹隘的方法。像我這樣的軟件狂人（開玩笑）總喜歡把所有問題都歸咎于硬件工具和工程師，但事實上硬件工具和軟件工具集都太過偏向于他們特定的領域了。很難見到二者添加了我以上提到的特性，因為這些特性跟其各自的客戶好像沒什么關系。我相信這種局面正在發生變化，PSoC Creator等產品支持在可編程硬件上進行器件配置同時還集成第三方IDE（如ARM的Keil μVision IDE）的工具會不斷發展。在工程師首選的IDE中實現應用開發，同時讓工具獲得獨有的強大信息并控制硬件平臺，這顯然是更高效進行產品開發、加速產品上市進程的必由之路。與此同時，減少對工程師的折磨也不失為一件大好事！