我的DSP專案在一步步深入，經過一輪輪的計算和選型，最終控制器做成了STM32F1與F28335組合體，ARM和DSP分管不同的功能，晶片間進行通訊。這篇文章給大家對比一下在程式設計環節上，STM32系列和DSP系列的區別。

一、IDE

STM32系列屬於ARM架構，最常用的IDE應該是MDK了（除MDK外，也有IAR，ST也推出針對STM32的IDE）。MDK的優點是功能的完整和齊全，從包管理器（支援多間廠商的ARMMCU的庫檔案下載，各種常用的中介軟體，以及RTOS等），到模擬器（JLINK、ULINK等等），以及編輯器、偵錯程式一應俱全。

但MDK的優點也止乎於止了，讓人吐槽的地方多不勝數：編輯器的功能停留於20年前、偵錯程式的功能有限、ARMCC的死板... ...我對MDK的依賴也僅止乎於它對模擬器的支援了。網上有很多例子用VSCode、EditPlus之類的高階編輯器加外掛，再搭配GCC來寫微控制器程式，但這些做法在我看來（我也嘗試過），就是缺少了對模擬器的支援，除錯程式的時候非常的不方便，所以我放棄了。

DSP用的IDE就是CCS了，CCS是一個基於Eclipse的IDE。一旦基於Eclipse，這IDE就一定逃不開啟動緩慢的缺點。相比MDK，CCS的專案管理、程式碼編輯器功能上略強，但很過分的是CCS的某些基本操作如註釋程式碼你只能用快捷鍵，在編輯選單中你找不到註釋程式碼的按鈕，也找不到任何快捷鍵的說明，會不會用全憑你對Eclipse的熟悉程度或者依靠搜尋引擎... ...

CCS沒有MDKV5的包管理器，在這點上MDK贏CCS九條街。

但在偵錯程式功能上，CCS就真的比MDK強很多了。首先是對變數的監測數量和反應上都優於MDK，另外程式斷點的數量上也明顯多於MDK（這兩點可能與模擬器有很大關係，畢竟我用的STM32模擬器和DSP模擬器不是同一檔次的東西），另外CCS可以很輕鬆的對某個變數的數值變化進行實時跟蹤，也能直觀的完成實時圖表的展示，非常方便。

二、庫檔案

庫檔案的作用基本就是把微控制器的暫存器地址用巨集來表示，再把一些時鐘、外設的初始化、配置、回撥用C函式組織起來，讓開發者能相對簡單利用微控制器的資源。我印象中STM32的庫檔案是微控制器界第一次掀起討論熱潮的底層函式，以往的51、AVR一般只有標頭檔案，而不會做成C函式庫的形式。使用庫檔案後，開發效率當然比直接操作暫存器高，但也帶來了程式效率下降、程式碼空間增大的問題，但STM32的主頻、FLASH、RAM相比51、AVR提高得太多，以至於基於庫檔案的開發也成為現在的主流。

我見過也用過幾個品牌的Cortex M微控制器，就庫檔案而言，ST是最用心搞的。以前的標準庫已經可以讓程式基本用不到彙編的語句了，現在主推的HAL庫野心更大，雖然帶來了程式效率下降、程式碼空間增大的問題，但隨著新的效能更強的微控制器系列推出，我相信HAL庫會成為主流。

DSPC2000的庫檔案相比ST的庫檔案差距就比較明顯了，與NXP的差不多吧，程式中要用到很多巨集，巨集也是直接使用匯編語句，抽象程度不高。另外C2000的標頭檔案中對暫存器大量使用結構體和聯合體進行表達，讓開發者必須老老實實的看完手冊才能程式設計，如果能夠再做一層中間函式就非常優秀了。相對而言，ST的庫檔案即使看不透暫存器的操作，但單憑中間函式的定義與說明都可以讓開發者容易地上手。

三、模擬器

模擬器這東西對於微控制器的開發而言，我認為是不可缺少的。單憑串列埠輸出除錯字串，一是麻煩，二來對於複雜的程式不容易定位問題。

Cortex M的模擬器現在是很便宜了，我以前用過Jlink，現在更多用所謂的Jlink OB，也就是SW除錯方式的模擬器，也就二三十元的價格，壞了連維修的想法都沒有。

DSPC2000的模擬器價格就感人了，國產都要上百，不過配合CCS後，在功能、效能上也比MDK+JLINK要強不少。