賴春雷
英飛凌技術支援中心 高級工程師
在前一期我們提到了ModusToolbox™對生態的理解。 我們反覆地提到,ModusToolbox™希望構建一個開放的應用生態。
開放的目的,是為了接納更多的可能性,促進成果的融合。 開放的本質,是為了減少ModusToolbox™和用戶的重複勞動。 開放的結果,則是帶來了可高度自定義的開發環境。
下面我們就來深入瞭解下,ModusToolbox™是如何為其生態願景而付諸努力的。
Oct . 2023
分享至
在前一期我們提到了ModusToolbox™對生態的理解。 我們反覆地提到,ModusToolbox™希望構建一個開放的應用生態。
開放的目的,是為了接納更多的可能性,促進成果的融合。 開放的本質,是為了減少ModusToolbox™和用戶的重複勞動。 開放的結果,則是帶來了可高度自定義的開發環境。
下面我們就來深入瞭解下,ModusToolbox™是如何為其生態願景而付諸努力的。
圖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™當中的更多細節,也歡迎你在評論區分享你的使用體會。
下期還有更多精彩,我們不見不散!
如需瞭解更多資訊,請點擊:
掃描二維碼, 關注英飛凌官微尋找更多應用或產品資訊
文章來源:英飛凌官微