引言
上文描述了如何將一個樣例工程下載到 QSPI Flash 并運行,那么就會有一個新的問題:將應用程序存儲在 QSPI Flash、片內(nèi) Flash 以及片內(nèi) SRAM 上,執(zhí)行的效果又如何?
本章將通過在不同 Flash 中執(zhí)行相同的測試程序,記錄其執(zhí)行程序所花費的時間,驗證不同 Flash 對微控制器執(zhí)行程序性能的影響。
在進行 Flash 速度驗證前,我們需要知道如何獲取各 Flash 的速度:
QSPI Flash 訪問速度可通過 QSPI 的 SCK 波特率直接求出。
片內(nèi) Flash 的訪問速度可通過 DataSheet 手冊或寄存器配置得到。
通常,片內(nèi) SRAM (系統(tǒng)時鐘速度訪問)的訪問速度與系統(tǒng)時鐘速度保持一致。
若要驗證在不同 Flash 中程序的執(zhí)行速度,還需考慮以下幾點:
驗證程序中要包含適量的小循環(huán),從而展現(xiàn) ICACHE 和 DCACHE 對執(zhí)行程序帶來的性能提升。
驗證程序中要包含適量的長跳轉,使 CPU 需要重新訪問 Flash 獲取指令和數(shù)據(jù),從而展現(xiàn)不同 Flash 對執(zhí)行程序速度帶來的影響。
驗證程序要足夠復雜,且 code size 要足夠大,盡量消除偶然性因素,從而能夠模擬真實使用場景,使驗證結果更加可信。
驗證程序應盡量使用通用的算法應用,可以在多平臺中進行適配,且能夠進行橫向比較。
驗證環(huán)境
MCU F5270/F5280
測試所用開發(fā)板
POKT-F5270 (MM32F5277E9PV),外擴 QSPI Flash
POKT-F5280 (MM32F5287L9PV),合封 QSPI Flash
開發(fā)工具
MCU F5270/F5280 配置
System Clock:120MHz
AHB Clock:120MHz
APB1 Clock:60MHz
APB2 Clock:60MHz
ICACHE: 開啟
DCACHE: 開啟
FPU: 開啟 (單精度)
片內(nèi) SRAM
Base:0x30000000
Speed:120MHz(1 訪問周期 + 0 等待周期)
片內(nèi) Flash
Base:0x08000000
Speed:24MHz(1 訪問周期 + 4 等待周期)
QSPI Flash
Base:0x90000000
存放數(shù)據(jù)的 RAM base:0x20000000 (with DTCM),在測試用例中使用另外的 RAM 存放程序
QSPI Flash
測試所用開發(fā)板:
型號:W25Q128JVSIQ,F(xiàn)M25Q16A
SCK波特率:30MHz (MM32F5270 only,120MHz AHB 時鐘 4 分頻) 與 60MHz (MM32F5280 only,120MHz AHB 時鐘 2 分頻)
受外界環(huán)境(線路不等長,阻抗不匹配等因素)和 GPIO 電平翻轉速度(電平上升下降沿所需時間)影響,片外 QSPI Flash難以在 SCK 波特率 60MHz 的環(huán)境下讀取到正確的數(shù)據(jù),因此 60MHz 驗證只在 MM32F5280 上進行。
其余驗證程序均在 POKT-F5270 開發(fā)板上進行運行。
SPI 模式:SPI 模式 3 (CPOH = 1, CPHA = 0)
POKT-F5270 (MM32F5277E9PV),外擴 QSPI Flash
POKT-F5280 (MM32F5287L9PV),合封 QSPI Flash
工作模式:QPI 模式(各通信階段線寬皆為四線)下進行 Fast Read
指令線寬:4-line
指令位寬:8-bit
地址線寬:4-line
地址位寬:24-bit
空指令周期數(shù):2-sck_cycles
數(shù)據(jù)線寬:4-line
交互方式:
由交互方式可知,無論向 QSPI Flash 讀取多少字節(jié)數(shù)據(jù),讀取數(shù)據(jù)前都會有 10 個 SCK 時鐘準備數(shù)據(jù)。
Arm CMSIS-DSP FFT 驗證
FFT (快速傅里葉變換),是一種能夠?qū)⒁欢坞x散的波形數(shù)據(jù)轉換為頻譜數(shù)據(jù)的算法。
CMSIS-DSP 中 FFT 計算的 API,具有良好的可移植性,可在 ARM 內(nèi)核的芯片中進行橫向?qū)Ρ?,具有可信性,且它?FFT 計算涉及到大量的循環(huán)和跳轉等操作,用例的 code size 足夠大,計算方法足夠復雜,可充分展現(xiàn) CPU 和 Flash 之間配合,適合用于當前各 Flash 對微控制器性能影響測試。
驗證方法
使用 Arm CMSIS-DSP FFT 驗證方法時,可指定一段波形數(shù)據(jù),通過 FFT 進行一次正向運算,得出頻譜數(shù)據(jù),再將頻譜數(shù)據(jù)進行一次 FFT 反向運算,得出原始的波形數(shù)據(jù)。
使用 SysTick 定時器記錄時間,由于進行一次正向運算和一次反向運算所需的時間較短,因此循環(huán)多次(1000次),統(tǒng)計計算所需的時間。計算所需的時間越短,表明在該 Flash 上執(zhí)行程序的性能越好,記錄完一次時間后,調(diào)整程序的優(yōu)化等級,再次進行驗證。
驗證用例簡介
用例中主要使用函數(shù) fft_test_init_f32() 與 fft_test_run_f32() 執(zhí)行 FFT 轉換。
fft_test_init_f32()
對一塊 float32_t 類型的buffer進行初始化,生成一段波峰為1,波數(shù)為100,采樣點共1024個的波形數(shù)據(jù)。
fft_test_run_f32()
初始化 FFT,對 buffer 中的內(nèi)容進行正向 FFT 轉換,將波形數(shù)據(jù)轉換為頻譜數(shù)據(jù),替換 buffer 中原有的數(shù)據(jù);
再對 buffer 中的內(nèi)容進行逆向 FFT 轉換,將頻譜數(shù)據(jù)轉換為波形數(shù)據(jù),替換 buffer 中原有的數(shù)據(jù);
循環(huán)正向 FFT 轉換和逆向 FFT 轉換,循環(huán)次數(shù)為 test_times 次。
Arm CMSIS-DSP FFT 用例的驗證方法
調(diào)用 fft_test_init_f32() 函數(shù)對一塊 float32_t 類型的 buffer 進行初始化。
開啟 SysTick 定時器,每毫秒產(chǎn)生一次中斷,實現(xiàn)計時功能。
記錄開始驗證的時間,調(diào)用 fft_test_run_f32() 函數(shù),test_times 為 1000。
記錄驗證結束的時間,打印驗證花費的時間。
驗證結果
在 QSPI Flash(60MHz與30MHz),片內(nèi) SRAM 和片內(nèi) Flash 上運算 Arm CMSIS-DSP FFT 的性能數(shù)據(jù)及代碼變量如表1所示。
此處需注意,由于浮點數(shù)記錄數(shù)據(jù)時會有精度問題,經(jīng)過 1000 輪 FFT 轉換后的波形數(shù)據(jù)與 FFT 轉換前的波形數(shù)據(jù)相比,會有輕微變化,屬正常現(xiàn)象。
表1 各 Flash 運行 FFT 的性能數(shù)據(jù)對比
以 -ofast 優(yōu)化為例,片內(nèi) SRAM 的運算時長為基準單位,各 Flash 進行 FFT 運算所需時長對比如圖1所示。
圖1 各 Flash 的 FFT 運算速度比較 (-ofast)
驗證程序
Arm CMSIS-DSP FFT 測試程序包含三種優(yōu)化等級程序:
o0 文件夾
編譯優(yōu)化選項為 -o0 的驗證程序,包含片內(nèi) Flash,片內(nèi) SRAM 和 QSPI Flash 三種環(huán)境的工程。
ofast 文件夾
編譯優(yōu)化選項為 -ofast 的驗證程序,包含片內(nèi) Flash,片內(nèi) SRAM 和 QSPI Flash 三種環(huán)境的工程。
oz 文件夾
編譯優(yōu)化選項為 -oz image size 的驗證程序,包含片內(nèi) Flash,片內(nèi) SRAM 和 QSPI Flash 三種環(huán)境的工程。
當程序運行在片內(nèi) SRAM 或 QSPI Flash 時,需要 bootlader 進行引導,bootloader文件夾中提供三種環(huán)境下的 bootloader:
pokt-f5270_bootloader_qspi_sckdiv2_mdk
驗證程序執(zhí)行在 QSPI Flash 上,且需要 SCK 時鐘為 AHB 時鐘的二分頻(AHB 時鐘為 120MHz 時 SCK 波特率為 60MHz)。
pokt-f5270_bootloader_qspi_sckdiv4_mdk
驗證程序執(zhí)行在 QSPI Flash 上,且需要 SCK 時鐘為 AHB 時鐘的四分頻(AHB 時鐘為 120MHz 時 SCK 波特率為 30MHz)。
pokt-f5270_bootloader_sram_mdk
測試程序執(zhí)行在片內(nèi) SRAM 上,該 bootloader 僅實現(xiàn)引導 CPU 執(zhí)行片內(nèi) SRAM 上的程序,不實現(xiàn)加載程序到片內(nèi) SRAM 的功能。下載本 bootloader 后,可使用如 JLink 等工具,將驗證程序加載到片內(nèi) SRAM 中。即使微控制器發(fā)生復位,片內(nèi) SRAM 中的程序也不會被擦除。
Mbed-TLS RSA1024 驗證
RSA1024 是一種非對稱加密算法,常用于網(wǎng)絡通信時的數(shù)據(jù)加密。Mbed-TLS RSA1024 計算量大,包含大量循環(huán),跳轉等操作,且其為純應用代碼,便于移植,計算方法復雜,可用于當前各 Flash 對微控制器性能影響測試。
驗證方法
指定公鑰和私鑰,對一段指定的數(shù)據(jù)進行 RSA1024 加密和解密。
使用 SysTick 定時器記錄時間,由于進行一次加密和解密的時間較短,需將一組加密與解密循環(huán)多次 (10次),記錄所需時間。
計算所需的時間越短,表明在該 Flash 上執(zhí)行程序的性能越好,記錄完一次時間后,調(diào)整優(yōu)化等級,再次進行驗證,不得使用專用的加解密硬件外設協(xié)助計算。
驗證用例簡介
用例中主要使用函數(shù) rsa_test_init() 與 rsa_test_run() 執(zhí)行數(shù)據(jù)加密。
rsa_test_init()
對存放解密數(shù)據(jù)的 buffer1 進行初始化,存放原始數(shù)據(jù)。
對存放加密數(shù)據(jù)的 buffer2 進行初始化,填充 0x00。
加載 RSA1024 公鑰和私鑰。
rsa_test_run()
將存放解密數(shù)據(jù)的 buffer1 中的內(nèi)容進行加密,并將加密后的數(shù)據(jù)存放到 buffer2 中。
將存放加密數(shù)據(jù)的 buffer2 中的內(nèi)容進行解密,并將解密后的數(shù)據(jù)存放到 buffer1 中。
循環(huán)以上操作 test_times 次。
驗證方法
調(diào)用 rsa_test_init() 函數(shù)對一塊 float32_t 類型的buffer進行初始化。
開啟 SysTick 定時器,每毫秒產(chǎn)生一次中斷,實現(xiàn)計時功能。
記錄開始驗證的時間,調(diào)用 rsa_test_run() 函數(shù),test_times 為 10。
記錄驗證結束的時間,打印驗證花費的時間。
驗證結果
在 QSPI Flash(60MHz與30MHz),片內(nèi) SRAM 和片內(nèi) Flash 運行 Mbed-TLS RSA1024 程序的性能數(shù)據(jù),如表2所示。
表2 各 Flash 運行 Mbed-TLS RSA1024 的性能數(shù)據(jù)
以 -ofast 優(yōu)化為例,片內(nèi) SRAM 的運算時長為基準單位,各 Flash 進行 RSA1024 運算所需時長對比如圖2所示。
圖2 RSA1024 運算速度對比 (-ofast)
驗證程序
Mbed-TLS RSA1024 測試程序包含三種優(yōu)化等級程序:
o0 文件夾
編譯優(yōu)化選項為 -o0 的驗證程序,包含片內(nèi) Flash,片內(nèi) SRAM 和 QSPI Flash 三種環(huán)境的工程。
ofast 文件夾
編譯優(yōu)化選項為 -ofast 的驗證程序,包含片內(nèi) Flash,片內(nèi) SRAM 和 QSPI Flash 三種環(huán)境的工程。
oz 文件夾
編譯優(yōu)化選項為 -oz image size 的驗證程序,包含片內(nèi) Flash,片內(nèi) SRAM 和 QSPI Flash 三種環(huán)境的工程。
當程序運行在片內(nèi) SRAM 或 QSPI Flash 時,需要 bootlader 進行引導,三種環(huán)境下的 bootloader 結構與 Arm CMSIS-DSP FFT 驗證程序中對 bootloader 的介紹相同。
需要注意,MbedTLS RSA1024 用例未使用 MicroLIB庫
驗證時發(fā)現(xiàn),使用 MicroLIB 后,在片內(nèi) SRAM 中執(zhí)行 calloc 函數(shù)無法申請內(nèi)存空間,影響 RSA1024 運算,因此在工程配置選項中選擇Options for Target ... -> Target 取消勾選 Use MicroLIB 。
為使用 printf() 函數(shù)打印驗證結果,在工程配置選項中選擇 Manage Run-Time Environment -> Compiler-> I/O 勾選 STDERR , STDIN , STDOUT 。程序配置如圖3所示。
圖3 Manage Run-Time Environment 配置
Helix MP3 Decoder 驗證
Helix MP3 解碼庫作為一款開源的 MP3 解碼組件,常在多媒體應用中使用。
Helix MP3 Decoder為純應用代碼,便于移植,且其在進行 MP3 解碼的過程中,需要進行大量的循環(huán)和長跳轉操作,適合用于當前各 Flash 對微控制器性能影響測試。
驗證方法
使用 Helix MP3 Decoder 驗證方法,指定一段 MP3 文件,將其文件中的原始數(shù)據(jù)存放在待測試的 Flash 中。
使用 Helix MP3 解碼庫將該 MP3 文件的原始數(shù)據(jù)解碼為 PCM 格式。
使用 SysTick 定時器記錄時間,由于指定的 MP3 文件較小,且 Helix MP3 解碼速度較快,因此循環(huán)多次(10次),統(tǒng)計計算所需的時間。
計算所需的時間越短,表明在該 Flash 上執(zhí)行程序的性能越好。完成一次時間統(tǒng)計后,通過調(diào)整程序優(yōu)化等級,再次進行驗證。
驗證用例簡介
用例中主要使用函數(shù) mp3_dec_test_run() 執(zhí)行 MP3 解碼。
mp3_dec_test_run()
初始化 Helix MP3 Decoder。
循環(huán)尋找下一個 MP3 的同步幀的起始位置,并開始解碼這一幀 MP3 原始數(shù)據(jù),直至 MP3 文件全部解碼。
釋放 Helix MP3 Decoder。
循環(huán)上述的 MP3 解碼過程,循環(huán)次數(shù)為 test_times 次。
驗證方法
開啟 SysTick 定時器,每毫秒產(chǎn)生一次中斷,實現(xiàn)計時功能。
記錄開始驗證的時間,調(diào)用 mp3_dec_test_run() 函數(shù),test_times 為 10。
記錄驗證結束的時間,打印驗證花費的時間。
驗證結果
在 QSPI Flash(60MHz,30MHz),片內(nèi) SRAM 和片內(nèi) Flash 中運行 Helix MP3 Decoder 所獲取的性能數(shù)據(jù),如表3所示。
表3 各 Flash 運行 Helix MP3 Decoder 的性能數(shù)據(jù)
以 -ofast 優(yōu)化為例,片內(nèi) SRAM 的運算時長為基準單位,各 Flash 進行 Helix MP3 Decoder 運算所需時長對比,如圖4所示。
圖4 mp3 dec test 運算速度對比 (-ofast)
驗證程序
Helix MP3 Decoder 測試程序包含三種優(yōu)化等級程序:
o0 文件夾
編譯優(yōu)化選項為 -o0 的驗證程序,包含片內(nèi) Flash,片內(nèi) SRAM 和 QSPI Flash 三種環(huán)境的工程。
ofast 文件夾
編譯優(yōu)化選項為 -ofast 的驗證程序,包含片內(nèi) Flash,片內(nèi) SRAM 和 QSPI Flash 三種環(huán)境的工程。
oz 文件夾
編譯優(yōu)化選項為 -oz image size 的驗證程序,包含片內(nèi) Flash,片內(nèi) SRAM 和 QSPI Flash 三種環(huán)境的工程。
當程序運行在片內(nèi) SRAM 或 QSPI Flash 時,需要 bootlader 進行引導,三種環(huán)境下的 bootloader 結構與 Arm CMSIS-DSP FFT 驗證程序部分介紹的相同。
總結
本文通過在 QSPI Flash,片內(nèi) Flash 與片內(nèi) SRAM 中分別運行測試工程 Arm CMSIS-DSP FFT、Mbed-TLS RSA1024 與 Helix MP3 Decoder,獲取微控制器性能數(shù)據(jù),從而對比在不同 Flash 位置的執(zhí)行速度的差異。
通過對比上述驗證數(shù)據(jù)可知:
不同型號 QSPI Flash 的訪問速度受 SCK 波特率影響,當訪問 QSPI Flash 的方法一致時,不同型號的 QSPI Flash 訪問速度一樣。
同一優(yōu)化選項下,使用不同驗證程序,不同 Flash 位置的執(zhí)行速度存在一定差異。
MM32F5270 系列芯片具備 ICACHE 和 DCACHE,驗證執(zhí)行速度比較小的程序,說明具備良好的時間局部性和空間局部性,具有較高的 CACHE 命中率,減少了訪問 Flash 所花費的時間;驗證執(zhí)行速度比較大的程序,說明執(zhí)行程序時,進行了較多較大范圍的跳轉操作,需不斷訪問 Flash,刷新 CACHE,造成執(zhí)行速度變慢。
當然,即使關閉 ICACHE 和 DCACHE,執(zhí)行速度比也是會存在一定差異的,這是由于 QSPI Flash 的訪問方式中規(guī)定了不論讀取多少字節(jié)的數(shù)據(jù),都會包含一個指令階段,一個地址階段和一個空指令階段,需要花費 10 個 SCK 時鐘周期,因此造成讀取 2n 字節(jié)數(shù)據(jù)花費的時間和 n 字節(jié)數(shù)據(jù)花費的時間,不是簡單的二倍關系,造成執(zhí)行速度比存在一定差異。
關于靈動
上海靈動微電子股份有限公司成立于 2011 年,是中國本土領先的通用 32 位 MCU 產(chǎn)品及解決方案供應商。公司基于 Arm Cortex-M 系列內(nèi)核開發(fā)的 MM32 MCU 產(chǎn)品擁有 F/G/L/A/SPIN/W 六大系列,目前已量產(chǎn)近 300多款型號,累計交付超 4 億顆,每年都有近億臺配備了靈動 MM32MCU 的優(yōu)秀產(chǎn)品交付到客戶手中,在本土通用 32 位 MCU 公司中位居前列。
靈動客戶涵蓋智能工業(yè)、汽車電子、通信基建、醫(yī)療健康、智慧家電、物聯(lián)網(wǎng)、個人設備、手機和電腦等應用領域。靈動是中國為數(shù)不多的同時獲得了 Arm-KEIL、IAR、SEGGER 官方支持的本土 MCU 公司,并建立了獨立、完整的通用 MCU 生態(tài)體系。靈動始終秉承著“誠信、承諾、創(chuàng)新、合作”的精神,為客戶提供從硬件芯片到軟件算法、從參考方案到系統(tǒng)設計的全方位支持。
-
mcu
+關注
關注
146文章
17336瀏覽量
352687 -
bootloader
+關注
關注
2文章
235瀏覽量
45742 -
靈動微電子
+關注
關注
7文章
122瀏覽量
19694 -
靈動微
+關注
關注
4文章
174瀏覽量
22724 -
MM32
+關注
關注
1文章
106瀏覽量
811
原文標題:靈動微課堂 (第258講)|mm32-2nd-bootloader技術白皮書(7)——性能評估
文章出處:【微信號:MindMotion-MMCU,微信公眾號:靈動MM32MCU】歡迎添加關注!文章轉載請注明出處。
發(fā)布評論請先 登錄
相關推薦
BFD技術白皮書 華為
【經(jīng)典】智能電網(wǎng)白皮書資料匯編
最新的智能電網(wǎng)的白皮書資料
H3C EPON技術白皮書
簡儀科技怒對LabVIEW的白皮書
mm32-2nd-bootloader技術進階設計:實現(xiàn)Ymodem更新代碼
![<b class='flag-5'>mm32-2nd-bootloader</b><b class='flag-5'>技術</b>進階設計:實現(xiàn)Ymodem更新代碼](https://file1.elecfans.com/web2/M00/89/62/wKgaomSCgLiAEZlDAAAf-uhCgp4211.png)
評論