數字電源技術在這幾年可以說是炙手可熱，而其控制器通常使用由TI設計的C2000芯片。不過絕大多數電力電子的同學一定是對這款MCU又愛又恨，愛的是其強大的處理性能在電力電子控制領域簡直是游刃有余，具體可以參考下文。恨的是在C2000平臺上開發比較復雜的電力電子系統時非常費時費力，經常是寫算法十分鐘，查datasheet兩小時，好不容易run起來了還要解BUG兩小時，相信小伙伴們一定有類似的感受。這篇文章就來探討為什么會出現這樣的問題以及如何解決，希望能解決各位同仁遇到的痛點問題~，相信小伙伴們一定有類似的感受。這篇文章就來探討為什么會出現這樣的問題以及如何解決，希望能解決各位同仁遇到的痛點問題~

數字電源為什么一般用DSP控制，而不能用普通的單片機？

裸機開發實在是太慢

針對裸機與實時操作系統的對比討論已經很多，而搞電力電子的小伙伴可能不是很熟，所以這里針對電源開發應用再單獨討論討論。對于一些簡單的電源應用，往往只需要一個while大循環再加上中斷就能完成。但是隨著產品的不斷升級和功能復雜化，一個這種“傳統”的開發裸機已經逐漸變得愈發臃腫，往往我們會遇到的主要難點是，開發速度非常慢！非常慢！非常慢！其中的原因我想可以展開為以下幾點： 一是學習曲線非常陡峭。TI的硬件封裝api做得并不好，這就導致C2000平臺上出現大部分用戶寫代碼都是直接操作寄存器的奇觀，雖說直接操作寄存器顯得很高級，代碼效率也會比較高，但是代價就是開發速度相當慢。每次做不同的實驗的時候都需要重新閱讀datasheet，查看每一個寄存器配置成什么值代表什么意思，等到寫好了再調試又會花非常多的時間，據我所知，由于C2000架構的相對復雜性，僅僅是一個中斷的配置都能難倒不少人。stm32的封裝就做的很好，官方的HAL用起來用戶省心了不少，那么問題來了，TI什么時候能爭點氣呢？ 二是重復造輪子的情況非常普遍。不同人對于不同功能都有自己的函數實現，導致所有人的代碼互相不兼容，各自為陣。以我自己為例，我以前的開發流程是先配置寄存器，也就是導入一個看起來跟自己實現功能差不多的官方例程。每加一個新功能就導入一個例程，然后ctrl c ctrl v。寄存器配置完畢之后寫應用層函數，比如說為了實現串口控制，會寫串口字符的解析函數。我記得，串口的解析程序和發送程序我都寫了好多遍，個中酸爽，相信大家都有所體會。 三是可維護性是一個很大的問題。一般電力電子系統會對于環路計算的實時性要求非常高，所以會放在中斷中計算，然后其他任務放在大while中放一個狀態機判斷。一旦任務多了，任務之間的依賴錯綜復雜。此時在while大循環中就出現非常復雜的狀態機系統，此時系統的可維護性將會變得非常差，出現大家常說的屎山代碼，相信包括在我在內的任何人都不愿意看別人寫的狀態機代碼。而且這么復雜的狀態機系統如果不經過良好的時序優化，系統的實時性其實也會變得非常糟糕。 四是內存安全得不到有力保障。任何一個處理多個任務的系統都涉及不同任務對共享內存的訪問，電力電子控制也不例外。比如有些狀態機可能被主循環和ISR同時讀寫，就可能產生所謂“競爭”的問題。比如主循環正將狀態從A修改到B，這時ISR打斷主函數并將狀態從A修改到C并返回，然后主循環開始執行狀態B對應的代碼可是此時真正的狀態已經是C了，最終導致狀態機崩潰。這種問題特別難以調試，一旦出問題就很嚴重，遇到了可能只能燒香拜佛了。同步和競爭的概念可能對很多電力電子的小伙伴比較陌生，感興趣的同學可以參見：

如何告別以上這些痛苦呢？讓RTOS來拯救你。

實時操作系統

什么是實時操作系統

實時操作系統（Real-time operating system, RTOS），又稱即時操作系統，它會按照排序運行、管理系統資源，并為開發應用程序提供一致的基礎。實時操作系統與一般的操作系統相比，最大的特色就是“實時性”，如果有一個任務需要執行，實時操作系統會馬上（在較短時間內）執行該任務，不會有較長的延時。

以上只是概念，大家可能看得似懂非懂，沒關系，咱們掰開了來看RTOS憑啥能解決前面提到的痛點問題？

開發速度快

操作系統是一個統一的平臺，也就是下圖中的內核部分，上層的組件層同樣重要。組件層對物理外設實現了硬件驅動程序，并以API的形式暴露給上層應用層。這樣的好處非常明顯。首先，用戶只需調用簡單（可讀性好）的函數就能實現想要的功能，再也不用跟底層寄存器打交道了，極大地縮短了開發周期。其次，降低開發難度。系統可以幫程序員省去大量時間思考軟件架構，只要保證調度和執行的完整性。甚至不需要特別處理，就可以做到很多事情。免去了，很多意外造成的跑飛。更重要的，統一的平臺架構使得用戶之間的代碼可以共享，從此告別在造輪子這件事情上反復花時間的時代。試想，不久的將來，你可能可以在C2000上運行python程序，這是不是很有意思！

保證系統實時性

實時操作系統天生就是給多任務設計的。對于復雜的電源系統也會涉及到多任務工作。比如各種系統狀態判斷，狀態監控，與上位機或者是FPGA通訊的程序，又或者需要使用到人機交互的處理程序等等。這么多程序中可能還會涉及到大量需要延遲等待的情形，使得任務實現變得異常復雜且難調試。甚至可能需要復雜的狀態機設計才有可能完成，這對程序員的素質要求還是非常高的。 而當使用RTOS，效果就四個字，無腦操作。多個任務設定優先級，優先級最高的優先執行，執行完畢之后等待，調度器自動切換到其他任務繼續執行。并且調度器能夠將任務切片并在不同任務之間進行輪轉，避免單一任務過分消耗系統資源，將任務均衡地分配到各個時間片中，使得整個系統的總體運行效率最高。

保證內存安全性

RTOS設計了一整套“同步機制”避免多個任務對內存的“競爭問題”，這些機制包括互斥鎖，旗語，臨界區段等等，確保多個任務有序對共享內存進行訪問。用戶只需要調用這些函數即可，完全不需要管其實現細節，簡單又好用，再也沒有莫名其妙程序跑飛的煩惱！

尷尬的現狀

說完這么多優點，但現狀卻是讓人非常尷尬。

缺乏基于C2000的靠譜好用的RTOS

RTOS在嵌入式領域發展的比較好，比如著名的freeRTOS，以及國內自主開發的RT-Thread。但是由于搞嵌入式的人往往很少搞電力電子，這就導致嵌入式的操作系統很少有專門給C2000芯片做移植的，同時設計的時候也沒有考慮電力電子應用的特殊性。目前有一些非官方的移植，但是功能有限，年久失修，開發者已經跑路。有興趣的童鞋可以嘗試。

https://github.com/IvanZuy/freertos_c28x

缺乏針對C2000的定制化設備框架

在電力電子領域，外設硬件的操作有自身獨特的復雜性。比如PWM不可能僅僅滿足于配置周期、占空比這種常規配置。還需要相位、死區、影子裝載、外部ADC采樣觸發等等靈活配置，而這卻是目前主流RTOS所空缺的。

TI開發的RTOS

作為C2000的親媽，TI自然是老早就基于C2000實現了自己的一套RTOS，然而這套工具可謂是非常難用以至于到現在都沒有被市場所接受，主要原因是

1、系統開源但不開放。TI-RTOS的C代碼使用xdc格式進行分裝。xdc格式閱讀代碼體驗較差，比較反人類。首先部分源代碼不是直接提供而是通過xdc tool生成的，所以代碼的透明性很差。其次經過xdc分裝的代碼很難追蹤，有些符號在代碼中的名字和鏈接之后的名字不一樣。這給代碼閱讀和調試造成了非常大的困難，簡直無處著手。由此可見，TI-RTOS經過xdc封裝之后，是一個開源但不開放的系統，完全是被CCS控制的，用戶可以獲得源碼但是完全沒有辦法在OS層面進行改動，只能在ti提供的api之上進行改動。 2、搶占功能有限。為保證實時性，RTOS通常是搶占（preempt）系統，即任務是可以被打斷并在不同任務之間輪轉的。TI-RTOS缺少在中斷中對進行線程上下文切換的機制，這意味著線程內部必須有主動掛起的操作才能搶占，否則將運行到底，不具備真正意義上的多任務搶占的功能。這是TI-RTOS的一個硬傷。 3、維護非常非常差。因為用戶有限，TI-RTOS對C2000的支持和維護非常差。筆者在TMS32028379D平臺下測試了TI-RTOS的幾個例程，發現很多例程（比如swi和task）無法運行直接跑飛。只有hello這一個例程可以正常運行。可見TI-RTOS對C2000根本不像親兒子，簡直就是撿來的孩子。

RT-Thread

RT-Thread誕生于2006年，是一款以開源、中立、社區化發展起來的物聯網操作系統。RT-Thread主要采用 C 語言編寫，淺顯易懂，且具有方便移植的特性（可快速移植到多種主流 MCU 及模組芯片上）。RT-Thread把面向對象的設計方法應用到實時系統設計中，使得代碼風格優雅、架構清晰、系統模塊化并且可裁剪性非常好。目前已經做到通過wrapper兼容freertos和uC/OS，提供posix接口，同時兼容Arduino。在內核層面提供各種hook方便用戶定制。 總之就是傻瓜操作，兼容并包，而且是中國創造。基于此我們選擇了基于RT-thread進行開發適配于C2000的RTOS。

目前已實現的效果

兼容控制臺使用命令行控制

通過串口，我們可以實現類似命令行的工具，可以非常方便監控系統狀態并且操縱外設，啟動任務

比如輸入如下指令就可以設置pwm占空比、相位、死區等等

pwm probe                     - probe pwm by name
pwm enable                        - enable pwm channel
pwm disable                       - disable pwm channel
pwm get                           - get pwm channel info
pwm set            - set pwm channel info
pwm phase                  - set pwm phase
pwm dead_time          - set pwm dead time

對硬件層做了充分的抽象

以GPIO為例，在此對比了傳統的寫寄存器的方式和采用封裝后的程序調用方式。

// 操作寄存器版本的代碼實現
EALLOW;
GpioCtrlRegs.GPAPUD.bit.GPIO0 = 0;   // Enable pullup on GPIO0
GpioCtrlRegs.GPAMUX1.bit.GPIO0 = 0;  
GpioCtrlRegs.GPADIR.bit.GPIO0 = 1;
GpioDataRegs.GPADAT.bit.GPIO0 = 1;
EDIS;
// 封裝之后的代碼實現
#define LED0_PIN    GET_PIN(A, 0)
rt_pin_mode(LED0_PIN, PIN_MODE_OUTPUT);
rt_pin_write(LED0_PIN, PIN_HIGH);

從可讀性來看，標準化的函數接口看起來一目了然。

再比如ePWM模塊，ePWM可謂是C2000的一大法寶，優化設計的驅動也將發揮ePWM的全部實力，為此，我們針對C2000平臺定制了專門的設備框架，可以靈活控制周期、占空比、相位、死區等等。比如設置pwm的周期和占空比可以通過如下代碼，代碼將變得清晰易讀，并且可以快速移植。

rt_device_control(&pwm1,PWM_CMD_SET_PERIOD, 10000);//設置周期為10us
rt_device_control(&pwm1,PWM_CMD_SET_DUTY, 0.5);//設置占空比為50%

結合Kconfig實現高度靈活配置

也可以通過Kconfig（一種類似圖形界面的配置工具）來詳細配置每一個寄存器，此時每一個選項都是以文字說明，以交互式的方式直接提示給用戶，免去用戶查詢datasheet的痛苦，非常方便。

搶占式任務調度

我們用一種非常巧妙的機制在C2000中實現了在中斷環境下的上下文切換，實現了真正意義上的搶占式多任務調度，解決了TI-RTOS懸而未決的一個重大難題。

幾乎無開銷的中斷響應

熟悉RTOS的小伙伴可能會覺得在電源系統這種實時性要求這么高的場合是否使用RTOS會影響系統中斷的延遲。這是由于RTOS的某些關鍵操作需要關閉全局中斷，這可能影響關鍵中斷的響應速度。目前測試結果顯示rt-thread關閉全局中斷的時間最長不超過1us（測試條件：5個線程，100Hz SYSTICK，CPU 200MHz，TMS320F28379），幾乎不會對關鍵中斷（比如PWM）響應造成影響。后續我們會進一步對內核進行改進，使得系統關鍵操作只關閉部分而非全局中斷，確保部分重要中斷可以獲得**0延遲（與裸機完全相同）**的響應速度。所以這一點大家不必擔心，使用我們開發的系統可以做到幾乎或者是零延遲！

未來工作

目前已經完成了內核移植（針對C2000的特殊架構定制化了部分內核代碼），完成了GPIO、UART、ePWM驅動，未來在持續更新ADC、Timer等外設的驅動。更進一步，我們將會把RTOS進程到Simulink的代碼生成工具里面，實現圖形化編程和一鍵代碼生成。與Simulink自帶的C2000支持包不同，我們的代碼生成工具基于RTOS的框架，生成的是人類可以閱讀和調試的代碼，從樣機到產品，代碼一步到位，無需手動移植！我們還會針對C2000芯片移植各種自動化工具，比如自動生成cmd文件，自動生成CCS工程文件，讓各種重復勞動都成為歷史。