ModusToolbox™講堂 | 第四課開放的生態，熟悉的味道

賴春雷

英飛凌技術支持中心

高級工程師

在前一期我們提到了ModusToolbox™對生態的理解。我們反覆地提到，ModusToolbox™希望構建一個開放的應用生態。開放的目的，是為了接納更多的可能性，促進成果的融合。開放的本質，是為了減少ModusToolbox™和用戶的重複勞動。開放的結果，則是帶來了可高度自定義的開發環境。下面我們就來深入了解下，ModusToolbox™是如何為其生態願景而付諸努力的。

使用熟悉的IDE進行工作

每當選用一個新的產品，這往往代表著你又要適應一遍新的開發流程，這總是讓人望而卻步。用戶都希望使用自己熟悉的IDE和開發流程進行工作，作為一款推崇開放和可自定義的軟體產品，ModusToolbox™自然無法拒絕這個需求。所以，是的，ModusToolbox™允許你繼續使用你熟悉的IDE來進行開發。通常而言，你有如下兩種方式。

導出到其它IDE

在前一期我們簡單介紹過Project Creator，但其實它還隱藏了一個小彩蛋：獨立運行它和在Eclipse IDE中調用它時，它的運行邏輯是不同的。Project Creator在獨立運行時，會開啟導出到其他IDE的選項入口，以方便你在新建例程時就直接導出到一些第三方IDE中使用。

圖01

在Eclipse IDE中調用Project Creator時，它的行為如圖01。可見，圖中的Target IDE是灰色不可選的狀態，並限定為Eclipse IDE。這個限制是自然的，因為我們是在Eclipse IDE中調用它，故它當前只應為Eclipse IDE服務。

圖02

而獨立運行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工程。

圖03

如圖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所示。

圖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™當中的更多細節，也歡迎你在評論區分享你的使用體會。

下期還有更多精彩，我們不見不散！

如需了解更多信息，請點擊：