本帖最后由 MindMotion 于 2023-7-10 16:46 编辑
引言
上文描述了如何将一个样例工程下载到 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
开发工具
- MDK5.37（ARM Compiler: v6.18）
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
存放数据的 RAM base：0x20000000 (with DTCM)，在测试用例中使用另外的 RAM 存放程序
QSPI Flash
测试所用开发板：
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 转换前的波形数据相比，会有轻微变化，属正常现象。
表1 各 Flash 运行 FFT 的性能数据对比
以 -ofast 优化为例，片内 SRAM 的运算时长为基准单位，各 Flash 进行 FFT 运算所需时长对比如图1所示。
图1 各 Flash 的 FFT 运算速度比较 (-ofast)
验证程序
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所示。
表2 各 Flash 运行 Mbed-TLS RSA1024 的性能数据
以 -ofast 优化为例，片内 SRAM 的运算时长为基准单位，各 Flash 进行 RSA1024 运算所需时长对比如图2所示。
图2 RSA1024 运算速度对比 (-ofast)
验证程序
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所示。
图3 Manage Run-Time Environment 配置
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所示。
表3 各 Flash 运行 Helix MP3 Decoder 的性能数据
以 -ofast 优化为例，片内 SRAM 的运算时长为基准单位，各 Flash 进行 Helix MP3 Decoder 运算所需时长对比，如图4所示。
图4 mp3 dec test 运算速度对比 (-ofast)
验证程序
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 字节数据花费的时间，不是简单的二倍关系，造成执行速度比存在一定差异。
点击下方链接，阅读mm32-2nd-bootloader技术白皮书系列更多内容：
| 
楼主
标题置顶
标题高亮
