電子發燒友App
** 引言**
上文描述了如何將一個樣例工程下載到 QSPI Flash 并運行，那么就會有一個新的問題：將應用程序存儲在 QSPI Flash、片內 Flash 以及片內 SRAM 上，執行的效果又如何？
本章將通過在不同 Flash 中執行相同的測試程序，記錄其執行程序所花費的時間，驗證不同 Flash 對微控制器執行程序性能的影響。
在進行 Flash 速度驗證前，我們需要知道如何獲取各 Flash 的速度：
QSPI Flash 訪問速度可通過 QSPI 的 SCK 波特率直接求出。
片內 Flash 的訪問速度可通過 DataSheet 手冊或寄存器配置得到。
通常，片內 SRAM （系統時鐘速度訪問）的訪問速度與系統時鐘速度保持一致。
若要驗證在不同 Flash 中程序的執行速度，還需考慮以下幾點：
驗證程序中要包含適量的小循環，從而展現 ICACHE 和 DCACHE 對執行程序帶來的性能提升。
驗證程序中要包含適量的長跳轉，使 CPU 需要重新訪問 Flash 獲取指令和數據，從而展現不同 Flash 對執行程序速度帶來的影響。
驗證程序要足夠復雜，且 code size 要足夠大，盡量消除偶然性因素，從而能夠模擬真實使用場景，使驗證結果更加可信。
驗證程序應盡量使用通用的算法應用，可以在多平臺中進行適配，且能夠進行橫向比較。
** 驗證環境**
MCU F5270/F5280
測試所用開發板
POKT-F5270 (MM32F5277E9PV)，外擴 QSPI Flash
POKT-F5280 (MM32F5287L9PV)，合封 QSPI Flash
開發工具
MCU F5270/F5280 配置
System Clock：120MHz
AHB Clock：120MHz
APB1 Clock：60MHz
APB2 Clock：60MHz
ICACHE: 開啟
DCACHE: 開啟
FPU: 開啟 (單精度)
片內 SRAM
Base：0x30000000
Speed：120MHz（1 訪問周期 + 0 等待周期）
片內 Flash
Base：0x08000000
Speed：24MHz（1 訪問周期 + 4 等待周期）
QSPI Flash
Base：0x90000000
存放數據的 RAM base：0x20000000 (with DTCM)，在測試用例中使用另外的 RAM 存放程序
QSPI Flash
測試所用開發板：
型號：W25Q128JVSIQ，FM25Q16A
SCK波特率：30MHz (MM32F5270 only，120MHz AHB 時鐘 4 分頻) 與 60MHz (MM32F5280 only，120MHz AHB 時鐘 2 分頻)
受外界環境（線路不等長，阻抗不匹配等因素）和 GPIO 電平翻轉速度（電平上升下降沿所需時間）影響，片外 QSPI Flash難以在 SCK 波特率 60MHz 的環境下讀取到正確的數據，因此 60MHz 驗證只在 MM32F5280 上進行。
其余驗證程序均在 POKT-F5270 開發板上進行運行。
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
空指令周期數：2-sck_cycles
數據線寬：4-line
交互方式：
由交互方式可知，無論向 QSPI Flash 讀取多少字節數據，讀取數據前都會有 10 個 SCK 時鐘準備數據。
** Arm CMSIS-DSP FFT 驗證**
FFT (快速傅里葉變換)，是一種能夠將一段離散的波形數據轉換為頻譜數據的算法。
CMSIS-DSP 中 FFT 計算的 API，具有良好的可移植性，可在 ARM 內核的芯片中進行橫向對比，具有可信性，且它的 FFT 計算涉及到大量的循環和跳轉等操作，用例的 code size 足夠大，計算方法足夠復雜，可充分展現 CPU 和 Flash 之間配合，適合用于當前各 Flash 對微控制器性能影響測試。
驗證方法
使用 Arm CMSIS-DSP FFT 驗證方法時，可指定一段波形數據，通過 FFT 進行一次正向運算，得出頻譜數據，再將頻譜數據進行一次 FFT 反向運算，得出原始的波形數據。
使用 SysTick 定時器記錄時間，由于進行一次正向運算和一次反向運算所需的時間較短，因此循環多次（1000次），統計計算所需的時間。計算所需的時間越短，表明在該 Flash 上執行程序的性能越好，記錄完一次時間后，調整程序的優化等級，再次進行驗證。
驗證用例簡介
用例中主要使用函數 fft_test_init_f32() 與 fft_test_run_f32() 執行 FFT 轉換。
fft_test_init_f32()
對一塊 float32_t 類型的buffer進行初始化，生成一段波峰為1，波數為100，采樣點共1024個的波形數據。
fft_test_run_f32()
初始化 FFT，對 buffer 中的內容進行正向 FFT 轉換，將波形數據轉換為頻譜數據，替換 buffer 中原有的數據；
再對 buffer 中的內容進行逆向 FFT 轉換，將頻譜數據轉換為波形數據，替換 buffer 中原有的數據；
循環正向 FFT 轉換和逆向 FFT 轉換，循環次數為 test_times 次。
Arm CMSIS-DSP FFT 用例的驗證方法
調用 fft_test_init_f32() 函數對一塊 float32_t 類型的 buffer 進行初始化。
開啟 SysTick 定時器，每毫秒產生一次中斷，實現計時功能。
記錄開始驗證的時間，調用 fft_test_run_f32() 函數，test_times 為 1000。
記錄驗證結束的時間，打印驗證花費的時間。
驗證結果
在 QSPI Flash（60MHz與30MHz），片內 SRAM 和片內 Flash 上運算 Arm CMSIS-DSP FFT 的性能數據及代碼變量如表1所示。
此處需注意，由于浮點數記錄數據時會有精度問題，經過 1000 輪 FFT 轉換后的波形數據與 FFT 轉換前的波形數據相比，會有輕微變化，屬正常現象。
以 -ofast 優化為例，片內 SRAM 的運算時長為基準單位，各 Flash 進行 FFT 運算所需時長對比如圖1所示。
驗證程序
Arm CMSIS-DSP FFT 測試程序包含三種優化等級程序：
o0 文件夾
編譯優化選項為 -o0 的驗證程序，包含片內 Flash，片內 SRAM 和 QSPI Flash 三種環境的工程。
ofast 文件夾
編譯優化選項為 -ofast 的驗證程序，包含片內 Flash，片內 SRAM 和 QSPI Flash 三種環境的工程。
oz 文件夾
編譯優化選項為 -oz image size 的驗證程序，包含片內 Flash，片內 SRAM 和 QSPI Flash 三種環境的工程。
當程序運行在片內 SRAM 或 QSPI Flash 時，需要 bootlader 進行引導，bootloader文件夾中提供三種環境下的 bootloader：
pokt-f5270_bootloader_qspi_sckdiv2_mdk
驗證程序執行在 QSPI Flash 上，且需要 SCK 時鐘為 AHB 時鐘的二分頻（AHB 時鐘為 120MHz 時 SCK 波特率為 60MHz）。
pokt-f5270_bootloader_qspi_sckdiv4_mdk
驗證程序執行在 QSPI Flash 上，且需要 SCK 時鐘為 AHB 時鐘的四分頻（AHB 時鐘為 120MHz 時 SCK 波特率為 30MHz）。
pokt-f5270_bootloader_sram_mdk
測試程序執行在片內 SRAM 上，該 bootloader 僅實現引導 CPU 執行片內 SRAM 上的程序，不實現加載程序到片內 SRAM 的功能。下載本 bootloader 后，可使用如 JLink 等工具，將驗證程序加載到片內 SRAM 中。即使微控制器發生復位，片內 SRAM 中的程序也不會被擦除。
** Mbed-TLS RSA1024 驗證**
RSA1024 是一種非對稱加密算法，常用于網絡通信時的數據加密。Mbed-TLS RSA1024 計算量大，包含大量循環，跳轉等操作，且其為純應用代碼，便于移植，計算方法復雜，可用于當前各 Flash 對微控制器性能影響測試。
驗證方法
指定公鑰和私鑰，對一段指定的數據進行 RSA1024 加密和解密。
使用 SysTick 定時器記錄時間，由于進行一次加密和解密的時間較短，需將一組加密與解密循環多次 (10次)，記錄所需時間。
計算所需的時間越短，表明在該 Flash 上執行程序的性能越好，記錄完一次時間后，調整優化等級，再次進行驗證，不得使用專用的加解密硬件外設協助計算。
驗證用例簡介
用例中主要使用函數 rsa_test_init() 與 rsa_test_run() 執行數據加密。
rsa_test_init()
對存放解密數據的 buffer1 進行初始化，存放原始數據。
對存放加密數據的 buffer2 進行初始化，填充 0x00。
加載 RSA1024 公鑰和私鑰。
rsa_test_run()
將存放解密數據的 buffer1 中的內容進行加密，并將加密后的數據存放到 buffer2 中。
將存放加密數據的 buffer2 中的內容進行解密，并將解密后的數據存放到 buffer1 中。
循環以上操作 test_times 次。
驗證方法
調用 rsa_test_init() 函數對一塊 float32_t 類型的buffer進行初始化。
開啟 SysTick 定時器，每毫秒產生一次中斷，實現計時功能。
記錄開始驗證的時間，調用 rsa_test_run() 函數，test_times 為 10。
記錄驗證結束的時間，打印驗證花費的時間。
驗證結果
在 QSPI Flash（60MHz與30MHz），片內 SRAM 和片內 Flash 運行 Mbed-TLS RSA1024 程序的性能數據，如表2所示。
以 -ofast 優化為例，片內 SRAM 的運算時長為基準單位，各 Flash 進行 RSA1024 運算所需時長對比如圖2所示。
驗證程序
Mbed-TLS RSA1024 測試程序包含三種優化等級程序：
o0 文件夾
編譯優化選項為 -o0 的驗證程序，包含片內 Flash，片內 SRAM 和 QSPI Flash 三種環境的工程。
ofast 文件夾
編譯優化選項為 -ofast 的驗證程序，包含片內 Flash，片內 SRAM 和 QSPI Flash 三種環境的工程。
oz 文件夾
編譯優化選項為 -oz image size 的驗證程序，包含片內 Flash，片內 SRAM 和 QSPI Flash 三種環境的工程。
當程序運行在片內 SRAM 或 QSPI Flash 時，需要 bootlader 進行引導，三種環境下的 bootloader 結構與 Arm CMSIS-DSP FFT 驗證程序中對 bootloader 的介紹相同。
需要注意，MbedTLS RSA1024 用例未使用 MicroLIB庫
驗證時發現，使用 MicroLIB 后，在片內 SRAM 中執行 calloc 函數無法申請內存空間，影響 RSA1024 運算，因此在工程配置選項中選擇Options for Target ... -> Target 取消勾選 Use MicroLIB 。
為使用 printf() 函數打印驗證結果，在工程配置選項中選擇 Manage Run-Time Environment -> Compiler -> I/O 勾選 STDERR ， STDIN ， STDOUT 。程序配置如圖3所示。
** Helix MP3 Decoder 驗證**
Helix MP3 解碼庫作為一款開源的 MP3 解碼組件，常在多媒體應用中使用。
Helix MP3 Decoder為純應用代碼，便于移植，且其在進行 MP3 解碼的過程中，需要進行大量的循環和長跳轉操作，適合用于當前各 Flash 對微控制器性能影響測試。
驗證方法
使用 Helix MP3 Decoder 驗證方法，指定一段 MP3 文件，將其文件中的原始數據存放在待測試的 Flash 中。
使用 Helix MP3 解碼庫將該 MP3 文件的原始數據解碼為 PCM 格式。
使用 SysTick 定時器記錄時間，由于指定的 MP3 文件較小，且 Helix MP3 解碼速度較快，因此循環多次（10次），統計計算所需的時間。
計算所需的時間越短，表明在該 Flash 上執行程序的性能越好。完成一次時間統計后，通過調整程序優化等級，再次進行驗證。
驗證用例簡介
用例中主要使用函數 mp3_dec_test_run() 執行 MP3 解碼。
mp3_dec_test_run()
初始化 Helix MP3 Decoder。
循環尋找下一個 MP3 的同步幀的起始位置，并開始解碼這一幀 MP3 原始數據，直至 MP3 文件全部解碼。
釋放 Helix MP3 Decoder。
循環上述的 MP3 解碼過程，循環次數為 test_times 次。
驗證方法
開啟 SysTick 定時器，每毫秒產生一次中斷，實現計時功能。
記錄開始驗證的時間，調用 mp3_dec_test_run() 函數，test_times 為 10。
記錄驗證結束的時間，打印驗證花費的時間。
驗證結果
在 QSPI Flash（60MHz，30MHz），片內 SRAM 和片內 Flash 中運行 Helix MP3 Decoder 所獲取的性能數據，如表3所示。
以 -ofast 優化為例，片內 SRAM 的運算時長為基準單位，各 Flash 進行 Helix MP3 Decoder 運算所需時長對比，如圖4所示。
驗證程序
Helix MP3 Decoder 測試程序包含三種優化等級程序：
o0 文件夾
編譯優化選項為 -o0 的驗證程序，包含片內 Flash，片內 SRAM 和 QSPI Flash 三種環境的工程。
ofast 文件夾
編譯優化選項為 -ofast 的驗證程序，包含片內 Flash，片內 SRAM 和 QSPI Flash 三種環境的工程。
oz 文件夾
編譯優化選項為 -oz image size 的驗證程序，包含片內 Flash，片內 SRAM 和 QSPI Flash 三種環境的工程。
當程序運行在片內 SRAM 或 QSPI Flash 時，需要 bootlader 進行引導，三種環境下的 bootloader 結構與 Arm CMSIS-DSP FFT 驗證程序部分介紹的相同。
** 總結**
本文通過在 QSPI Flash，片內 Flash 與片內 SRAM 中分別運行測試工程 Arm CMSIS-DSP FFT、Mbed-TLS RSA1024 與 Helix MP3 Decoder，獲取微控制器性能數據，從而對比在不同 Flash 位置的執行速度的差異。
通過對比上述驗證數據可知：
不同型號 QSPI Flash 的訪問速度受 SCK 波特率影響，當訪問 QSPI Flash 的方法一致時，不同型號的 QSPI Flash 訪問速度一樣。
同一優化選項下，使用不同驗證程序，不同 Flash 位置的執行速度存在一定差異。
MM32F5270 系列芯片具備 ICACHE 和 DCACHE，驗證執行速度比較小的程序，說明具備良好的時間局部性和空間局部性，具有較高的 CACHE 命中率，減少了訪問 Flash 所花費的時間；驗證執行速度比較大的程序，說明執行程序時，進行了較多較大范圍的跳轉操作，需不斷訪問 Flash，刷新 CACHE，造成執行速度變慢。
當然，即使關閉 ICACHE 和 DCACHE，執行速度比也是會存在一定差異的，這是由于 QSPI Flash 的訪問方式中規定了不論讀取多少字節的數據，都會包含一個指令階段，一個地址階段和一個空指令階段，需要花費 10 個 SCK 時鐘周期，因此造成讀取 2n 字節數據花費的時間和 n 字節數據花費的時間，不是簡單的二倍關系，造成執行速度比存在一定差異。
工商網監
評論