GD32VF103與STM32F103性能對比

• GD32VF103與STM32F103性能對比
• 對比方式
• 測試結果
• • STM32F103
  • GD32VF103
  • 順便附上STM32F411的測試結果
  • 結論
  • • 歸算到同主頻
• --

GD32VF103與STM32F103性能對比

最近入手一個Sipeed的LonganNano，上面的芯片是GD32VF103CBT6，riscv架構的內核，主頻達到108MHz。

等等，F103 ？？很難不讓人想到STM32F103，宣傳說GD32VF103的內核比Cortex-M3性能好，但到底好多少呢？我要好好測一下。

對比方式

我弄這個LonganNano開發板其實是為我自己寫的一個RTOS提供riscv支持的，然后順便做一個速度測試，測試的方式毫無疑問，比線程的調度速度。

測試的方法是:
創建兩個線程A和B和兩個二值信號量a，b。
A線程等待信號量a，等到信號量后向信號量b釋放信號量；
B線程等待信號量b，等到信號量后向信號量a釋放信號量。
然后讓第三個線程釋放某個信號量(a或者b), 線程A和線程B之間就開始互相調度起來了, 此時空閑線程就沒有執行的機會了。

詳細的代碼在https://gitee.com/H0x9DEFA478/H_TS.git.
其內部的例程就是線程調度速度的測試代碼。

測試結果

STM32F103

先上老前輩的測試結果:

芯片條件: stm32f103 72MHz Flash使能預取ARM編譯器V5配置條件:阻塞鏈表數量vH_TS_BlockThreadListNum==1占位線程數量Stress_IsExtThread==0-O3優化+時間優化 -O0優化Thread(Stress_IsTestISR==0) avg:19122.60/100ms 5.23us avg:11200.14/100ms 8.93usSVC_ISR(Stress_IsTestISR!=0) avg:16534.39/100ms 6.05us avg:9994.09/100ms 10.0us

還是上個好看的表格把

--O3優化+時間優化-O0優化

線程觸發	avg:19122.60/100ms 5.23us	avg:11200.14/100ms 8.93us
線程調用SVC，然后由SVC釋放信號量	avg:16534.39/100ms 6.05us	avg:9994.09/100ms 10.0us

編譯器優化開滿的情況下每次調度耗時不到7us

GD32VF103

芯片條件: gd32vf103cbt 108MHz 配置條件:阻塞鏈表數量vH_TS_BlockThreadListNum==1占位線程數量Stress_IsExtThread==0Ofast優化 Og優化Thread(Stress_IsTestISR==0) avg:36144.78/100ms 2.77us avg:34336.73/100ms 2.91usSVC_ISR(Stress_IsTestISR!=0) avg:26381.21/100ms 3.79us avg:25270.41/100ms 3.96us*后面us為單位的為每次調度所用的時間 100000us/cnt* --O3優化+時間優化-O0優化

線程觸發	avg:36144.78/100ms 2.77us	avg:34336.73/100ms 2.91us
線程調用ecall，然后由異常釋放信號量	avg:26381.21/100ms 3.79us	avg:25270.41/100ms 3.96us

順便附上STM32F411的測試結果

芯片條件: stm32f411 96MHz Flash配置: 指令預取開 指令緩存開 數據緩存開ARM編譯器V5**配置條件:**阻塞鏈表數量vH_TS_BlockThreadListNum==1占位線程數量Stress_IsExtThread==0-O3優化+時間優化Thread(Stress_IsTestISR==0) avg:31375.51/100ms 3.18usSVC_ISR(Stress_IsTestISR!=0) avg:27373.31/100ms 3.65us*后面us為單位的為每次調度所用的時間 100000us/cnt*

我為什么附上這個？ 因為有了這個對比了之后我感覺STM32F103的結果似乎有問題，F4與F3的性能應該是差不多的(調度不涉及浮點運算)。但實際上，根據這個結果看來，F4與F3的性能相差1.23倍(換算到同主頻下)。感覺差的有點多了。
但F411相對于F103, Flash多了個指令緩存和數據緩存，不知道是不是這個加快了F4的速度，如果原因是這個的話，那這個緩存用處可真大

結論

毫無疑問，GD32VF103壓倒性的勝利。

什么？你說主頻不一樣？主頻也是芯片實力的一部分！憑實力達到的主頻為什么不能用來比！

歸算到同主頻

但是，上面結果的直接對比只能說芯片好不好，要說架構好不好(雖然架構似乎也能影響主頻上限)，但我還是要整個歸算到同主頻的對比。

看看高頻單片機自斷手腳(主頻)的結果！

下面的數據是歸算到主頻1MHz下的結果：

型號線程觸發SVC/ecall觸發

STM32F103	265.59/100ms	229.64/100ms
GD32VF103	334.67/100ms	244.27/100ms
STM32F411	326.83/100ms	285.14/100ms

可以發現，在SVC/ecall觸發下，F411的成績居然比VF103的好(其實就算沒有歸算，也是F411的好)，原因不難理解，risc寄存器多，中斷是risc的劣勢，為了能在中斷中正常的調用C函數，觸發中斷后，risc的中斷處理要保存更多的寄存器，然后才能調用委托的函數(在這里就是釋放信號量函數)，所以VF103的中斷成績要差一些。

雖然中斷上risc略遜一籌，但在程序正常執行時，或許是因為其寄存器更多的原因(或者更多的原因)，使得risc的性能更好，同主頻下VF103比F103快1.26倍。(或許在flash這塊上F103吃了大虧)

–

調試這個GD32不是一帆風順的，這個GD32VF官方給的異常處理代碼有點問題:

Cortex-M 有SVC異常。相應的，riscv-Bumblebee也有個環境調用異常，但在我使用這個的時候，我被自帶的中斷處理給坑了，工程里給的異常處理代碼trap_entry的上下文處理是有問題的，csr寄存器的入棧覆蓋了寄存器的，還好中斷處理代碼irq_entry里的是正確的(就是對比這兩個才發現的問題)。

一看到環境是基于eclipse的就能想想到debug的時候是什么場景了，實際上一試果然是這樣，早在STM32CubeIDE就知道了，debug體驗跟keil比起來簡直是一個天一個地。不過keil一身缺點，也就一個debug能吹了。
不過后來發現調試的問題不一定是eclipse的鍋，因為它們都用了一樣的調試方式：gdb+openocd ,得益于這種調試方式，有辦法能在vscode上也能進行調試，但結果，碼代碼神器vscode調試起來還不如eclipse，搞得我都不知道是哪里有問題了，可能都有問題。
openocd還有一個坑的地方，它似乎只認HID模式下的DAP下載器(還是官方給的openocd版本太低了？)，搞得我把winusb模式下的DAP下載器活活改回了HID模式

總而言之，GD32VF103是個好芯片，但配套的軟件還不太行(其實大部分都還好，用MounRiver Studio文件都不用自己復制，工程直接生成好。但一到debug這一塊就難受起來了)。

risv是個好架構，不僅性能好，似乎功耗還低(用我不太準的電流表測，板子上4個LED的VF103的電流比板子上只有一個LED的F103(也是最小系統版)的電流低)，重點它是Free的！

總結

以上是生活随笔為你收集整理的GD32VF103(riscv)与STM32F103性能对比的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。