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)
离线
很早以前就有人把GD芯片开盖分析过了。
GD的片内闪存是串行flash而非并行,类似于SIP工艺。
其零等待的实现方法就是RAM映射(这部分RAM覆盖flash地址空间,用户无法直接写入),对用户透明。
RAM覆盖的部分flash就是零等待闪存,RAM覆盖不到的flash就是巨慢flash,比ST的并行flash差几个数量级。
离线
这类慢速flash作为XIP,除非有cache扶持,否则就是废材。
ESP32的QSPI-Flash有cache;STM32H7的QSPI-Flash也有cache,NXP的Cortex-M7也都有cache,这些才是合理设计。
离线
如果没有cache,SDRAM用于XIP都是半残废;何况串行Flash啊。
离线
这类慢速flash作为XIP,除非有cache扶持,否则就是废材。
ESP32的QSPI-Flash有cache;STM32H7的QSPI-Flash也有cache,NXP的Cortex-M7也都有cache,这些才是合理设计。
雅特力的AT32,非零等待部分应该也是有Cache的。性能下降在同一个数量级。
GD32这个看起来是没有Cache的,就当它不存在好了。慢三个数量级,怪不得手册上不敢写。
离线
AT的零等待就是SRAM,非零等待一样拉胯
离线
对,GD号称零等待实际是在RAM中运行
离线
离线