GD32F1x0系列，常见的GD32F130和GD32F150，只有前32kB闪存为零等待，32kB往后的非零等待闪存手册中只提了一句话：
从闪存的32K ~ 64K地址空间内取数据有比较长的延迟
对这句话一个严谨的工程师是没法接受的，比较长的延迟？到底多长的延迟算是比较长呢？既然官方没有说明，那我只好自己测试一下了。
测试的目的，主要是判断一下在32kB之后的非零等待闪存中运行代码有没有实用性，对用户选型做一个参考。测试方法使用Dhrystone，和之前对比Cortex-M和RISC-V效率的代码是一样的。
测试芯片为GD32F150C8T6，方法为同一份Dhrystone代码编译的固件放到0x8002000和0x8008000分别运行，测试运行时间。运行主频选择8MHz，通常主频越高，SPI闪存访问效率瓶颈会更明显，所以先用低主频来测试，如果差异不大，再提高主频测试。
# 8MHz零等待闪存O3优化
dhry
Start dhrystone test...
Stopped, elasped time = 38ms 3840
# 8MHz零等待闪存Oz优化
dhry
Start dhrystone test...
Stopped, elasped time = 57ms 5709
# 8MHz非零等待闪存O3优化
dhry
Start dhrystone test...
Stopped, elasped time = 31708ms 26465
# 8MHz非零等待闪存Oz优化
dhry
Start dhrystone test...
Stopped, elasped time = 142337ms 12387结果汇总如下，注意单位：
8MHz零等待闪存O3优化：38.40ms
8MHz零等待闪存Oz优化：57.09ms
8MHz非零等待闪存O3优化：31.708s
8MHz非零等待闪存Oz优化：142.337s
结果一目了然，非零等待闪存的运行速度低了3个数量级，串口输出都有明显的卡顿，尤其是Oz优化的时候，我一度以为程序是不是死机了？两分多钟以后结果出来了。通常非零等待闪存运行效率的降低如果在一个数量级以内，运行一些对速度要求不高的业务代码还是完全可用的。至于低了3个数量级么，运行代码基本可以判定为不可用，放一点不常访问的数据，或者就当它不存在好了。
最近编辑记录 echo (2021-10-26 10:12:47)
离线
这类慢速flash作为XIP，除非有cache扶持，否则就是废材。
ESP32的QSPI-Flash有cache；STM32H7的QSPI-Flash也有cache，NXP的Cortex-M7也都有cache，这些才是合理设计。
雅特力的AT32，非零等待部分应该也是有Cache的。性能下降在同一个数量级。
GD32这个看起来是没有Cache的，就当它不存在好了。慢三个数量级，怪不得手册上不敢写。
离线