微控制器實時操作系統實踐5選擇IDE

選擇IDE

集成開發環境（IDE integrated development environment）有能力極大地影響開發。集成開發環境被設計成具有較小的學習曲線，並且通常提供一種簡單的方法來從現有的驅動程式和中間件建立解決方案。

在本章中，我們將討論如何選擇IDE，看看不同類型的IDE，並選擇一個IDE來創建你在本書所用的代碼包中發現的所有源代碼。

下麵是我們將涉及的主要議題的快速列表：

• 集成開發環境的選擇標準
• 平臺抽象的IDE
• 開放源代碼/免費IDE
• 專有的IDE
• 為本書選擇IDE

IDE選擇標準

有些工程師喜歡不使用IDE，而是把他們最喜歡的文本編輯器和命令行編譯器或鏈接器（如GCC或Clang）放在一起，手工製作一些makefiles，然後開始編碼。這也是一種完全有效的方法--它將帶來巨大的靈活性，減少對專有工具的依賴，當然應該考慮。

以下各節中的IDE列表並不意味著是詳盡的。列出這個清單是為了提供一些例子，說明可用的IDE的多樣性和每個IDE的不同焦點。下麵是一些快速考慮的要點：

• 語言支持： 並非所有的嵌入式MCU都是用C99（或彙編）編寫的；現在有許多語言選擇。

• 調試支持： 除非你打算每次都切換到不同的工具，否則調試是必要的。你的IDE應該有一些調試能力。許多IDE依靠GNU調試器（GDB）作為底層調試協議，這意味著它們應該與任何支持GDB介面的調試硬體相容。

• 線程感知的調試： 理想情況下，IDE應具有線程感知調試能力。記住，每個任務都有自己的堆棧。預設情況下，大多數調試功能只顯示與當前程式計數器相關的堆棧，當試圖分析任何當前未運行的任務時，這就成了問題。

• 設備支持： 挑選能夠瞭解設備中硬體寄存器的IDE（除非你不會用它進行調試）。

• 平臺操作系統： 即Windows、Linux或macOS--你總是可以運行一個虛擬機，但通常在你喜歡的操作系統上原生運行IDE會更方便。

• 成本： 包含獲取、使用等成本。

• 與其他工具的集成： 開發一個嵌入式系統有許多組成部分。擁有一個儘可能多的集成開發環境是有幫助的，但需要考慮的一些項目是目標硬體、測試夾具、調試硬體、RTOS固件、用戶固件、目標中間件、幫助配置硬體的輔助主機軟體（即STM32Cube）、幫助你分析和調試代碼的軟體（即靜態分析工具），以及測試框架。

• 易用性： 理想情況下，一DE將提供一個愉快的編碼環境，並通過自動交叉引用（如IntelliSense）使代碼創建更容易，從而提高生產率。

• 可用性：IDE將是可用的，完全支持的，並提供更新，以便在一個產品或項目的整個生命周期內充分利用新的硬體目標。對於長期項目來說，檢查你打算使用的IDE的歷史（和許可模式）是個好主意。如果集成開發環境只能通過訂閱來使用（沒有永久許可選項），可能有一天它就不再可用了。確保永久許可證始終在手，你就可以無限期地運行集成開發環境，並保證你始終能夠從源代碼中複製二進位文件。

• 生態系統： 大多數集成開發環境都不只包含集成開發環境本身。它們會有插件、中間件、論壇，有時還有整個開發者社區。

在接下來的章節中，我們將介紹幾個不同概念的IDE組。以這種方式對IDE進行分組並不特別死板，但它確實有助於對它們的動機和用例的預期進行框定。有時，一個IDE可以被歸入不止一個組別，這也是完全可以接受的。我們將用來對IDE進行分類的組別如下：

• 免費的MCU供應商IDE和以硬體為中心的IDE
• 平臺抽象的IDE
• 開放源代碼/免費IDE
• 專有的IDE

本章介紹的IDE實例是2019年的。雖然嵌入式系統固件開發工具的變化不像其他軟體學科那麼快，但預計隨著時間的推移，情況會有一些變化

免費的MCU供應商IDE和以硬體為中心的IDE

如今，較大的MCU製造商通常會提供一個免費的IDE，以幫助降低潛在開發者的門檻。從歷史上看，這些IDE除了提供一個編譯器外，並沒有提供更多的東西，而且如果你每天使用它們，一般來說是很糟糕的。然而，在過去的幾年裡，由於晶元製造商試圖將自己與競爭對手區分開來，已經出現了向更高質量的供應商提供的IDE的轉變。有時，它們集成了額外的功能，可以幫助配置硬體和/或供應商提供的驅動程式，這在硬體開發、最初的板卡啟動和早期的固件開發中是很有幫助的，因為硬體外設正在被鍛煉並與系統的其他部分集成。

由於這些工具並不是硬體製造商的核心業務，它們經常會被臨時改變。這使得供應商的集成開發環境對於長期運行的項目來說是一個危險的選擇。

幾乎是為了證明這一點，STM在寫這本書的時候改變了他們的IDE產品。所有的例子都需要被導入到新的軟體中： STM32CubeIDE。
由於我們將使用STM32單片機作為我們的目標，我們將看看STM提供的IDE（在寫作時，這是STM32CubeIDE）。對於每個不同的MCU供應商，你可以考慮他們專有的IDE--例如，如果你在NXP MCU上開發，你可能會考慮MCUXpresso。

STM32CubeIDE

在STM的案例中，同一MCU供應商提供了多個IDE。在收購Atollic之後，STM將Atollic TrueStudio的完全定製版與STMCubeMX應用程式一起推出，從而形成了STM32CubeIDE。儘管Atollic TrueStudio仍然可用，但它已被廢棄，不建議用於新設計。

以下是STM32CubeIDE的快速統計數據：

平臺抽象化的IDE

越來越複雜的MCU、對設備功能不斷膨脹的期望以及不斷縮小的開發周期，促使許多軟體工具公司專註於創建高於硬體的抽象，其目的是使複雜設備的開發更加容易和快速。最成功的平臺和抽象往往在上市幾年後就有了自己的生命。Mbed和Arduino都有廣泛的用戶社區，有許多用戶創建的網站和博客專門用於每個平臺。

因為平臺的一致性對於易用性是最重要的，所以實現通常會包括許多註重易用性的功能，有時會犧牲性能和良好的設計實踐。例如，一些硬體目標將為諸如PWM輸出等暴露一個API，即使底層MCU硬體沒有支持該功能的外設。這在許多不同的硬體目標上創造了更快的原型開發經驗，因為API將無縫地把功能映射到軟體程式中。然而，設備性能會因此受到負面影響。有時，程式員甚至沒有意識到在他們所做的簡單的API調用之下，正在進行複雜的權衡。

有許多不同的因素決定了圍繞一個平臺的項目是否是一個好主意。

在以下情況下，在一個平臺之上進行設計可能是好的：

• 該平臺幾乎包含了你所需要的一切： 如果平臺已經有了所有的主要部分，那麼就沒有什麼不確定性；所需要的只是一些特定領域的代碼。
• 你預定的目標設備有一個符合你確切要求的開發板： 這導致的不確定性比試圖添加許多缺失的子電路並將其與現有的平臺代碼適當整合要少。
• 團隊中的大多數工程師已經對該平臺有很深的經驗： 深厚的經驗意味著他們已經增加了類似於項目所需的任何定製的能力

在一個平臺之上進行設計，在以下情況下可能是不好的：

• 很少有團隊成員對所需的平臺有經驗： 有些平臺比其他平臺更複雜--沒有第一手經驗的人可能是有風險的。
• 打算使用的MCU還沒有被平臺所支持： 在一個平臺上添加MCU支持通常有許多輔助要求，這些要求對你的項目沒有任何價值。對於一個非常簡單的項目來說，在現有的複雜平臺上增加對一個新設備的支持，比在裸機上或用最小的供應商提供的庫來創建項目需要更多的努力。
  黑- 盒調試很困難： 隨著嵌入式工程師離硬體越來越遠，理解系統的行為方式變得越來越困難，特別是當有多層其他人的代碼（OPC）需要挖掘的時候。

年輕的實時嵌入式工程師的職業發展會因為早期在平臺上投入太多的時間和精力而受到嚴重阻礙。由於所有這些額外的複雜性，在實時系統中是否能可靠地達到最後期限，存在著額外的風險和不確定性。挖掘複雜的代碼庫來試圖追蹤複雜的間歇性錯誤可能是真正的挑戰。如果沒有堅實的底層知識基礎可供利用，這種挑戰就會變得更大。

ARM Mbed Studio

ARM Mbed是以物聯網為重點的平臺，它提供了非常大的中間件庫和跨越許多不同硬體供應商的一致的開發環境。最初，Mbed平臺只通過網站提供，但他們現在增加了Mbed Studio--可用於Windows和macOS的離線IDE。

以下是ARM Mbed Studio的快速統計資料：

由於Mbed是面向平臺的，因此可以用Mbed IDE設置項目，然後導出到各種離線IDE，如ARM Keil uVision，或基於makefile的項目，導入到Eclipse和Visual Studio Code。如果你的項目需要所包含的中間件提供的功能，而且實現得很好，那麼不需要重新發明輪子就可以嚴重節省時間。

Arduino IDE

Arduino平臺是一個極其普遍的平臺，有巨大的硬體和軟體的生態系統。一般來說，Arduino集成開發環境用於向新人介紹電子學和編程，它使用嚴格的結構化庫，為用戶編寫草圖暴露了C/C++的API。Arduino的目標是使非編程人員能夠快速和容易地製作原型。因此，它儘可能多地將底層硬體的細節隱藏在庫中。

以下是Arduino IDE的快速統計：

還有許多非Arudino提供的IDE，可以用來為Arduino平臺編程。有些會有額外的功能，並暴露出更多底層的C/C++實現。

開放源碼/免費IDE

自從IBM創建了Eclipse基金會來推廣一源的、高度可擴展的IDE以來，許多基於Eclipse的IDE已經涌現出來。我們將在本節中看一下兩個這樣的IDE。近年來，微軟開始大力關註開源項目，創建了免費的、開源的Visual Studio Code文本編輯器，本節也會介紹。

用於STM32的AC6系統工作平臺（S4STM32）

AC6是一家咨詢公司，它貢獻了基於Eclipse的IDE，針對STM32 MCU。System Workbench增加了對基於STM的發現板的一些支持，以幫助快速建立項目。AC6還提供了適用於Linux的System Workbench，如果你正在開發多核器件（來自STM32MP1系列）的應用，它可能會很有用。

以下是STM32的AC6系統工作平臺的快速統計：

Eclipse CDT和GCC

你也可以選擇從頭開始推出自己的基於Eclipse的IDE。Eclipse CDT是C/C++開發的事實上的標準。您還需要提供一個編譯器。ARM 提供了一個完整的 GCC 站點，用於從 Windows、Linux 和 macOS 向 ARM Cortex-M 設備進行交叉編譯。可以在 https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm 找到它。

以下是Eclipse CDT的快速統計資料：

對於那些不喜歡Eclipse集成開發環境的人來說，存在另一種替代方案，而且越來越受歡迎： Visual Studio Code。

微軟Visual Studio Code

2015年，微軟發佈了Visual Studio Code，這是一個文本編輯器，提供添加擴展的能力。雖然這在錶面上聽起來相當簡單，但有足夠的擴展來提供一個非常值得尊敬的IDE體驗，包括IntelliSense和完整的調試能力。如果你已經習慣了基於Visual Studio的IntelliSense和調試，那麼這個環境就會非常熟悉。

以下是Visual Studio Code的快速統計數據：

與Eclipse CDT類似，Visual Studio Code需要安裝GCC，以及一個擴展。為了讓Visual Studio正確設置，請按照以下步驟進行：

• 要安裝GCC for Cortex-M，請到https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm。
• 要安裝JLink工具（用於連接到調試探針），請訪問https://www.segger.com/downloads/jlink。
• 要安裝cortex-debug擴展，請到https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug。

到目前為止，我們所涉及的所有IDE都是免費的（在某些情況下是開源的）。下一節包括那些要花錢的、基本上是閉源的IDE。為什麼會有人想要這樣的東西呢，你問。繼續閱讀，看看這些解決方案能提供什麼。

專有的集成開發環境

付費的專有IDE曾經是MCU交叉編譯應用程式的標準，現在開始被免費的、開放源碼的解決方案所取代。然而，僅僅是免費選項的存在並不能立即使付費選項被淘汰。專用集成開發環境的賣點是，它們提供最廣泛的設備支持，並要求開發者給予最少的關註。

設計成開箱即用，付費專業級解決方案的名聲是為開發者節省時間。這些時間的節省通常有三種主要形式：設置MCU的統一環境、統一的調試環境和供應商提供的中間件，在多個MCU供應商之間通用。

現在啟動和運行MCU比以往任何時候都要容易，但一旦項目進展到開始定義RAM和ROM中的特定記憶體區域或在基於Quad-SPI的快閃記憶體中添加額外的可執行空間，就需要一些額外的配置。最好的專業集成開發環境會提供一些幫助（通過圖形用戶界面），這使得這些配置比需要深入研究散點文件和基於彙編的啟動代碼要容易一些（儘管這些都是需要掌握的優秀技能！）。

與通過GUI快速配置MCU的能力類似，專業級IDE的調試器支持通常也是非常直接的，一般僅限於從下拉列表中選擇調試器，並可能對一些設置進行微調。

如果你閱讀了不同的MCU可能擁有的所有選項，那麼同一MCU並不適合你進行的每一個項目，這一點可能並不奇怪。能夠在MCU系列（甚至是供應商）之間快速移動，同時保持一個統一的界面是一個很好的優勢。然而，被鎖定在基於平臺的方法中，硬體介面開始被定義（以及固件API），也可能是限制性的（即Arduino或MBed硬體定義）。

使用一個成熟的公司編寫的中間件，可以使你擺脫面向硬體的平臺只關註日光下的外設的傾向。它將重點從訪問一個特定平臺的引腳轉移到訪問適當抽象的MCU外設。這種區別是微妙的，但在涉及到設計靈活性時卻相當重要。寫得好的中間件將提供一致的MCU外設抽象，以及更複雜的中間件。

付費工具的缺點是貨幣成本，這需要根據開發時間、勞動力和延遲產品發佈的機會成本進行評估。你知道通過使用中間件而不是重新發明固件輪子可以節省多少時間嗎？擁有一個對你選擇的任何處理器都能穩定工作的IDE所獲得的時間量又是多少呢？一些基本的投資回報率（ROI）的計算，將現金支出與開發人員的時間的誠實和準確估計進行比較，通常會使中等複雜項目的天平傾向於購買中間件。當然，這是在假設有現金可以購買軟體工具的情況下。

ARM/Keil uVision

Keil最初在20世紀80年代為8位8051架構開發了首批C語言編譯器之一。該公司轉而支持其他內核，並最終被ARM收購。他們目前為ARM Cortex-M設備提供最有效的編譯器之一（Clang/LLVM）。uVision IDE的免費版本是可用的，但僅限於32KB的代碼空間。集成開發環境的各種層級有多種許可選項（如永久的、基於訂閱的等等）。代碼模塊是通過軟體包添加的，這簡化了項目的快速設置。一個功能非常全面的中間件堆棧可作為頂級產品，它為不同的實時操作系統提供了抽象，併在所有支持的MCU之上提供了統一的API。

以下是uVision的快速統計數據：

FreeRTOS任務感知調試不可用--Keil uVision對他們自己的免費提供的CMSIS RTX RTOS有精心的支持。uVision MDK中的代碼編輯器也該改頭換面了。

與Keil uVision類似，IAR Embedded Workbench是另一個長期存在的嵌入式工作的IDE。

IAR Embedded Workbench

一般來說，IAR嵌入式工作台與Keil uVision有非常相似的功能集。主要的區別是，IAR沒有納入模塊化軟體包的高級能力。先進的調試功能在IAR中相對於uVision更容易獲得和直觀一些。代碼編輯器同樣令人失望。

下麵是IAR嵌入式工作平臺的快速統計：

現在我們已經涵蓋了老牌的產品，我們將進入最近的產品，首先是Rowley CrossWorks。

羅利CrossWorks

Rowley Crossworks是一個比Keil和IAR價格略低的入門級產品。中間件是與IDE分開授權的。FreeRTOS意識到的基於任務的調試在IDE中是不可用的；相反，對CrossWorks任務庫（CTL）RTOS解決方案的支持是可用的。

以下是CrossWorks的快速統計數據：

接下來是一個由以調試硬體聞名的公司創建的IDE： SEGGER Embedded Studio。

SEGGER Embedded Studio

SEGGER--我們將要使用的調試探頭的製造商--也提供許多軟體產品，包括他們自己的IDE（和RTOS）。它可以免費用於非商業用途，沒有任何限制。他們也有一個完整的中間件堆棧，與IDE分開授權。FreeRTOS意識到的調試可以直接在IDE中使用，並有適當的插件。

以下是Embedded Studio的快速統計數據：

SysProgs Visual GDB

Visual GDB實際上並不是一個IDE。它是Microsoft Visual Studio和Visual Studio Code的插件。它已經存在了相當長的一段時間（從2012年開始）。Visual GDB的主要目的是提供一致的UI（Visual Studio）來與支持GDB的調試器和GNU make工具進行交互。它的主要目標用戶是那些熟悉Visual Studio開發環境並希望在其嵌入式工作中繼續使用該環境的程式員。

下麵是Visual GDB的快速統計：

Visual GDB提供了與圖形化配置工具--STM Cub--以及Arduino項目的集成，所以從不同的開發框架遷移可能會更容易一些。

選擇本書中使用的IDE

現在我們已經對幾個不同的IDE進行了分類，是時候考慮哪一個將被用於本書剩餘部分所涉及的示例代碼了。為了保持低成本的主題，以減少進入的門檻，我們將把重點放在不需要任何金錢投資的IDE上--任何可供非專業人員免費使用的東西（沒有時間或代碼限制）都可以考慮。這就立即排除了Keil uVision、IAR Embedded Workbench和SysProgs Visual GDB。Keil有免費版本，代碼限制在32KB，但我們可能很快就用完了，這取決於我們選擇在例子中包含多少中間件。

由於本書有很大一部分內容涉及用J-Link探針進行調試，我們希望有一持J-Link或GDB的IDE。在完美的世界里，IDE也會支持任務感知的FreeRTOS調試，實時變數觀察，等等。正如我們將在下一章看到的那樣，FreeRTOS內核感知調試並不是什麼大問題，因為SEGGER Ozone包括這種能力。

最後，集成開發環境應該是多平臺的，以促進任何有膽量的人的採用。鑒於這一系列標準，我們只剩下有限的選擇，如圖所示：

那麼，我們可以從這個表格和前面的觀察中得出哪些要點呢？

• Eclipse CDT是潛在的候選方案，但由於與其他一些解決方案相比需要額外的設置，所以它略顯不理想。
• VS Code是可擴展的代碼編輯器（開箱即用），與Eclipse類似。將需要額外的插件。
• STM32But IDE承諾提供專業級的調試能力和多任務RTOS感知調試。
• SEGGER Embedded Studio承諾提供與STM32CubeIDE非常相似的功能集。
  我們將使用STM32CubeIDE進行代碼示例。由於STM32CubeIDE也包含了STM32系列MCU的代碼生成器，讓我們來看看使用代碼生成工具的一些優勢，以及要做的權衡。

考慮STM32Cube

STM32CubeIDE是兩個組件的合併--IDE和STMCubeMX圖形化配置和代碼生成工具，用於STM32 MCU。CubeMX組件可以在開發周期的幾個不同點上發揮作用。讓我們來談談開發周期的相關階段，確定CubeMX如何幫助，以及如何權衡。

器件選擇

大多數現代MCU可以選擇將外設映射到幾個不同的引腳。然而，每個引腳通常在幾個不同的外設之間共用。因此，在引腳受限的設備上，有可能出現所需的外設可用（存在於MCU上）但無法訪問（能夠被映射到一個物理引腳）的情況。硬體設計人員可以快速評估STM32 MCU的各個型號是否能突破特定應用所需的外設組合。能夠快速、準確地在多個晶元上進行這些評估，可以大大節省時間。通常情況下，設計者在做出這樣的決定之前，需要對每個晶元的數據手冊進行密切的瞭解。CubeMX絕對不能替代適當的盡職調查，但它確實有助於快速縮小潛在器件的範圍。

STM32 MCU上的每個外設都可以單獨關閉，這可以節省電力。隨著目前電池供電（和能量收集）的物聯網設備的激增，儘量減少功耗是熱門話題。另一種降低功耗的方法是以較低的頻率為晶元計時。CubeMX允許工程師快速計算出晶元在特定配置下的耗電量。在為一個項目調查潛在的MCU時，速度和準確性都很重要。通過在CubeMX中輸入外設/時鐘配置來獲得準確的功耗估算，比瀏覽數據手冊和從頭開始創建電子錶格要快得多。

硬體啟動

硬體啟動是指首先啟動定製設計的硬體並對其進行某種程度的驗證。與開發/評估板相比，定製硬體通常有許多不同之處（畢竟是定製的！）。一個可能不同的領域是時鐘硬體。STM32的時鐘樹是相當複雜的--單一的時鐘源為許多不同的子系統供電。時鐘頻率會被乘法器和除法器沿途修改。CubeMX包含圖形化嚮導，幫助正確配置STM32時鐘樹，並生成初始化代碼，使晶元快速啟動和運行。

還需要早期的固件工作來驗證硬體的運行。仔細檢查MCU是否可以被配置為訪問電路板上所有需要的片外電路，這始終是好主意。通常情況下，快速評估硬體的可行性符合每個人的最佳利益，而不是等到固件的所有方面都完全成熟。

當需要利用STM32 MCU上的複雜外設時，CubeMX可以用來快速設置從內部外設到MCU外部引腳的引腳映射。它還包含簡單的、菜單驅動的界面，用於選擇外設的配置方式。初始化代碼會自動生成，它使用STM的硬體抽象層（HAL）驅動程式。相關的外設中斷也是為用戶配置和存根的。這使得嵌入式工程師能夠儘快地通過驗證。

在所有的硬體被驗證後，將是添加額外的固件層（中間件）的時候了，這些固件將生活在低級別的驅動程式和應用固件之間。

中間件設置

STM多年來與許多不同的中間件供應商合作，使他們的客戶能夠更直接地引入額外的功能。例如，FreeRTOS原件可以通過CubeMX的幾個下拉菜單來選擇。FAT文件系統可以被設置，還有TCP/IP協議棧、JPEG圖像庫和Mbed TLS。不要搞錯了，這個工具不會像一個精通的程式員那樣進行高級配置，但作為一個最低限度，它為評估不熟悉的庫提供了一個堅實的開始。一些工程師可能會發現最初的配置直接符合他們的要求，這意味著有更多的時間來關註他們解決方案的其他部分。

所以，現在我們已經選擇了一個設備，驗證了硬體，並建立了一些中間件堆棧，現在一定是時候繼續對最終的應用程式進行編碼了！嗯......不完全是。使用所有這些提供的代碼會有一些問題，讓我們來看看。

中代碼生成的權衡

雖然所有這些功能在理論上聽起來很不可思議，但開發人員對CubeMX及其在現實世界中的應用有不同的感受。這些擔憂和權衡大多涉及該工具如何融入工作流程；其他時候，挑戰來自於可用性問題。

從可用性的角度來看，CubeMX通常工作得很好；其他時候，它生成的無效代碼根本無法按預期工作。這似乎是它剛發佈時的問題。偶爾會有一些版本會產生一些甚至無法編譯的項目。然而，作為一低限度，它一直為較新的STM32設備上的高級外設的配置提供一個很好的參考點。

工程師們在將CubeMX集成到他們的工作流程中時，所面臨的挑戰是任何生成與用戶代碼緊密耦合的代碼的實用程式的典型。最初，該工具可以用來創建一個大型的代碼庫，可以快速站起來，並提供所需功能的很大一部分。然而，隨著項目的進展，調整幾乎是不可避免的；保持定製的用戶代碼與自動生成的CubeMX代碼分開可能會變得很麻煩。你可能會發現自己處於一個複製-粘貼的迴圈中，不斷地將工作代碼從一個外圍複製到另一個。這是一種在我們行業中泛濫的做法。嵌入式固件工程師亟需打破複製粘貼的無限迴圈。第12章 "創建良好抽象架構的技巧 "涵蓋了在採用這些類型的工作流程時要做哪些權衡。它也有一些關於如何設置你的代碼庫以實現長期增長而不是腐爛的建議。

綜上所述，我們的例子中使用的部分代碼將使用STMCubeMX生成的代碼作為起點來實現。STM32 HAL在業界被廣泛使用，所以任何曾經對STM32進行過編程的人都可能對它很熟悉。請記住，本書中的示例代碼是為了讓人容易掌握。它旨在強調如何實現RTOS的概念，而不是作為未來添加的可擴展的基礎。使用接近STM32 CubeMX生成的代碼的主要意圖是使你更容易開始自己的實驗。

設置IDE

STM32CubeIDE需要安裝，並且需要導入源碼庫，以便編譯和運行下麵幾章的示例代碼。

安裝STM32CubeIDE

要安裝STM32CubeIDE，請遵循以下兩個簡單的步驟：

• 從https://www.st.com/en/development-tools/stm32cubeide.html 下載STM32CubeIDE。
• 使用預設選項安裝它。

現在STM32CubeIDE已經安裝完畢，我們需要導入源代碼樹。讓我們看看如何做到這一點。

將源碼樹導入到STM32CubeIDE中

安裝完STM32CubeIDE後，你需要把源碼樹導入到Eclipse工作區。工作區是Eclipse的術語，是相關項目的集合：

由於STM32CubeIDE是基於Eclipse IDE的，如果你過去使用過Eclipse，你會發現下麵的說明很熟悉。

• 從https://github.com/PacktPublishing/Hands-On-RTOS-with-Microcontrollers，下載或克隆GitHub的存儲庫：

• 最好的做法是保持庫的路徑簡短，沒有空格；也就是說，c:\projects。

• 示例中使用的基本git路徑是c:\projects\packBookRTOS。

• 打開STM32CubeIDE。

  • 導入整個Repo：
  • 轉到菜單： 文件｜導入。
  • 選擇General | Existing Projects Into Workspace | Next。瀏覽並選擇包含repo的文件夾，（c:\projects\packBookRTOS），選擇後應該與下麵類似：
  • 點擊完成。下一步 "按鈕總是灰色的。
    

• 此時，項目資源管理器面板將顯示所有導入的章節（下麵的截圖只顯示第5章 "選擇IDE "和第6章 "實時系統的調試工具 "的代碼，因為它們是目前唯一編寫的例子）：

• 為了確保一切安裝正確，右擊Chapter5_6並選擇Build。控制台視窗中的輸出應該類似於下麵：

祝賀你！你現在應該可以構建Chapter5_6了！你現在應該可以構建本書所包含的FreeRTOS實例項目了!

你可能已經註意到，Eclipse項目所包含的文件夾與磁碟上的組織方式並不完全相同（也就是說，Drivers和Middleware並不是文件系統中Chapter5_6的子文件夾）。這樣做的目的是為了允許跨項目/章節重覆使用共同的代碼。這個概念將在第12章 "創建良好抽象架構的技巧 "中更深入地闡述。