賴春雷
英飛凌技術支援中心 高級工程師
在前一期我們提到了ModusToolbox™對生態的理解。 我們反覆地提到，ModusToolbox™希望構建一個開放的應用生態。
開放的目的，是為了接納更多的可能性，促進成果的融合。 開放的本質，是為了減少ModusToolbox™和用戶的重複勞動。 開放的結果，則是帶來了可高度自定義的開發環境。
下面我們就來深入瞭解下，ModusToolbox™是如何為其生態願景而付諸努力的。
19
Oct . 2023
ModusToolbox™講堂 | 第四課 開放的生態，熟悉的味道
分享至
使用熟悉的IDE進行工作
圖01
每當選用一個新的產品，這往往代表著你又要適應一遍新的開發流程，這總是讓人望而卻步。
使用者都希望使用自己熟悉的IDE和開發流程進行工作，作為一款推崇開放和可自定義的軟體產品，ModusToolbox™自然無法拒絕這個需求。
所以，是的，ModusToolbox™允許你繼續使用你熟悉的IDE來進行開發。 通常而言，你有如下兩種方式。
匯出到其它IDE
在前一期我們簡單介紹過Project Creator，但其實它還隱藏了一個小彩蛋：獨立運行它和在Eclipse IDE中調用它時，它的運行邏輯是不同的。 Project Creator在獨立運行時，會開啟匯出到其他IDE的選項入口，以方便你在新建例程時就直接匯出到一些第三方IDE中使用。
圖02
在Eclipse IDE中調用Project Creator時，它的行為如圖01。 可見，圖中的Target IDE是灰色不可選的狀態，並限定為Eclipse IDE。 這個限制是自然的，因為我們是在Eclipse IDE中調用它，故它當前只應為Eclipse IDE服務。
圖03
而獨立運行Project Creator時，它的行為如圖02所示。 此時，Target IDE的下拉框是可以選擇的，這表示它可把選中的例程生成給指定IDE使用，即生成為該IDE可以打開的工程。 這一設計也是自然的，因為此時的Project Creator是獨立運行的，所以它並不受制於Eclipse IDE，從而可以為受支援的IDE進行工程的創建。
“IAR Embedded Workbench”和“ARM MDK”是常用的導出選項。 你甚至可以選擇“None / Command line”，即不匯出到任何的IDE，而採用更底層的編輯和編譯方式。
有使用者可能會疑惑，支持導出到多種第三方的IDE，對ModusToolbox™本身有什麼好處？ 長此以往，ModusToolbox™生態是否會被架空，使用者是否會逐步拋棄ModusToolbox™？
其實不是這樣的。 如你所見，得益於這個良好的導出功能，Project Creator中提供的例程只需要開發一次，即可導出到多個IDE中使用。 換言之，只需要一次開發，即可讓ModusToolbox™中的產品立即在多個開發平臺中運行，相當於讓這些產品立即上線多個開發平臺。
這不僅降低了用戶的學習成本，對ModusToolbox™而言也降低了的開發難度、縮短了開發週期，還讓友商的IDE擁有了更多的可選資源。 由此可見，開放的生態，能讓各方都從中獲益，這可謂是開放生態設計體系的一大勝利。
使用Visual Studio Code編輯器
從前面可知，Project Creator本身已經可以把工程導出為Visual Studio Code工程。 然而，對於Visual Studio Code這類通用的輕量編輯器級IDE，其實還有更好的辦法來使用它。
Visual Studio Code支援直接打開資料夾，我們可以借助這個特性，使用它來直接編輯Project Creator為Eclipse IDE生成的工程，而無需先把工程匯出為Visual Studio Code工程。
圖04
如圖03，這就是Visual Studio Code直接編輯ModusToolbox™的Eclipse IDE工程的演示。 可以看到，目錄結構都是Eclipse IDE工程的結構，但我們卻是在Visual Studio Code中編輯它。
Visual Studio Code在代碼編輯與審閱方面有更多的優勢，可以説明你快速編寫和更改代碼。 但因為ModusToolbox™自帶的Eclipse IDE有官方的優化和整合，所以後續的編譯和燒錄的部分，回到Eclipse IDE中操作則會更合適。 所以將兩者結合起來會產生1+1>2的效果。
這種有機結合Visual Studio Code和Eclipse IDE的開發形式，本身也是開放生態設計體系的一部分。 順從於開放性的要求，ModusToolbox™只提供工具和介面，而極少提供範式和模式。 可以說，範式和模式本身，也是使用者可以並必須補足的。
於是，使用者的想像力和創造力，不僅可傾注在開發工作上，也可傾注在開發工具本身。 這一現象拓寬了開放生態設計體系的邊界和含義，是開放生態設計體系的又一大勝利。 與此同時，使用者對開發工具使用形式的創新，也將反哺用戶的開發工作，讓開發更加高效、創作更具熱情。
使用熟悉的類UNIX命令行環境
很多讀者都喜歡使用Windows系統來進行開發。 誠然，Windows是一個面向GUI而生的系統，很多優秀的可視化編輯器等工具都是基於Windows提供的，所以Windows在進行可視化的代碼編輯時有很多優勢。
但進行一些深入的分析和調試時，命令行環境是無法避開的，準確來說，是類UNIX的命令行環境。
因為類UNIX系統的歷史地位，其所奠定的範式和規範影響深遠，並且嵌入式設備的開發和GNU套件生態也存在千絲萬縷的關係，導致嵌入式開發或多或少會依賴類UNIX的命令行環境及GNU工具鏈。
這與其說是一個限制，不如說是一個優點：因為這個歷史的特殊性，嵌入式設備的從業人員也必然對類UNIX的命令行環境及GNU工具鏈比較熟悉，所以如果能為他們提供類UNIX的操作環境，將為他們減少很多學習成本。
鑒於此，ModusToolbox™自帶了一個命令行環境，名為modus-shell。 modus-shell是基於Cygwin集成而來的，他在Cygwin的核心工具集之外增加了自己的工具，並重新定義了文件系統映射。
如果你聽說過Cygwin，那你一定知道，Cygwin是一個在Windows平臺上運行的類UNIX模擬環境，Cygwin的主要目的是通過重新編譯，將POSIX系統（例如Linux、BSD，以及其它Unix系統）上的軟體移植到Windows上。
關於modus-shell的更多資訊，請參見ModusToolbox Tools Package User Guide。
你可以在Eclipse IDE中通過Terminal選項卡直接使用modus-shell，也可以通過開始功能表獨立運行它，如圖04所示。
借助modus-shell，你能在Windows平台上獲得完整的類似UNIX環境的體驗。 它不是虛擬機，所以無需複雜的設置，你即可在Windows上同時享受到Windows本身的便利和類UNIX命令行環境的優勢，在這兩者之間無縫切換，擺脫虛擬機帶來的複雜的隔離。 相比單獨使用Windows或類UNIX系統，這種將兩者鬆散耦合的方式會更有效地幫助到使用者。
看似一個簡單的集成，其實背後是開放生態設計體系的再一大勝利。 不信你看，你隨處可見類UNIX環境的移植、GNU軟體的跨平臺應用，但你鮮有看到Windows環境和工具在其它操作系統上的大規模移植和應用。
順從於開放性的要求，一個開放的生態應該是自由且可分享的，也應該能很容易被分享和傳播。
“自由且可分享”是先驗的，它使得使用者對類UNIX環境形成粘性，進而讓使用者感到熟悉和放心，於是使用者會要求在更多開發作業環境中獲得類UNIX的體驗，這包括ModusToolbox™。
“能很容易被分享和傳播”則是后驗的，它使得ModusToolbox™能較為容易地集成modus-shell這個類UNIX環境，從而使得ModusToolbox™能按使用者熟悉的慣例提供給使用者使用，哪怕是在Windows等其它操作系統。
所以，開放生態設計體系或主動或被動地促成了ModusToolbox™集成modus-shell這一結果; 同時，這也是ModusToolbox™身處開放生態、服務於開放生態的體現。
總結
開放的生態，無論是出於主觀的訴求，還是客觀的需要，它最終都是為了給使用者“找回熟悉的味道”。
而ModusToolbox™作為開放生態理念的踐行者，它正在當仁不讓地付諸努力，為了給使用者“找回熟悉的味道”。
當然，ModusToolbox™的這份堅持，絕不僅僅體現在文章提到的這兩點。 歡迎讀者挖掘隱藏在ModusToolbox™當中的更多細節，也歡迎你在評論區分享你的使用體會。
下期還有更多精彩，我們不見不散！
如需瞭解更多資訊，請點擊：
掃描二維碼， 關注英飛凌官微尋找更多應用或產品資訊
文章來源：英飛凌官微