简介
为了评估Nor性能优化空间，我需要根据Spec计算出极限情况下，Nor Flash的性能理论值。
在全志的R**相关项目中分别支持ESMT、MXIC、Winbond、GD这4个厂家的Nor Flash，具体型号不方便透露，其规格书参数如下：
| 厂家 | 写(ms) | 4K擦除(ms) | 32K擦除(ms) | 64K擦除(ms) | 全盘擦除(s) |
|---|---|---|---|---|---|
| MXIC | 0.33~1.2 | 25~120 | 140~650 | 250~650 | 26~60 |
| Winbond | 0.7~3 | 45~400 | 120~1600 | 150~2000 | 40~200 |
| GD | 0.5~2.4 | 50~400 | 160~800 | 300~1200 | 50~120 |
| ESMT | 0.5~3 | 40~300 | 200~1000 | 300~2000 | 60~200 |
上表是Spec中记录的典型时间到最大时间。
Flash有写前必须擦除的特性，为了简化计算，我们忽略除了擦除、写外的损耗，例如WREN:Write Enable等，例如传输损耗。由此计算出的性能会比实际性能略高，但也足以让我们对其性能有个直观认识。
我以性能较高的MXIC的Nor Flash为例，计算理论性能
理论性能
关键词说明如下：
EraseTime: 擦除(erase)时间
EraseSize: 擦除的大小
WriteTime: 写(write)时间
WriteCount: 一次擦除可以写多少笔数据
BlockSize: 块大小
Flash的特性要求必须先擦除后写，Nand如此，Nor也如此。
在spiffs的代码中，我们可以看到对nor的一个特殊应用：某些标志bit不擦除，直接写。是的，Nor也支持不擦除直接写，但只支持1->0的编程，因此spiffs中只用作某个1->0的标志bit也是可以的。但对大多数情况，为了不丢失数据，我们务必擦除后再写。
综合上擦除和写的时间：
Time(ms) = EraseTime + WriteTime * WriteCount
在Nor中，我们假设每次写256B的数据(1Page)，那么1次4K擦除可以写16笔数据，1次32K擦除可以写128笔数据，1次64K擦除可以写256笔数据。
因此，理论性能应该为：
Speed = EraseSize / (EraseTime + WriteTime * WriteCount)
以MXIC的4K大小擦除块为例：
性能 = 4KB / (25ms + 0.33ms * (4KB / 256B)) = 4 KB / 30.28ms = 132.1 KB/s
类似的，根据上述的计算方法，我们统计的各厂家理论性能如下(KB/s)：
| 厂家 | 4K擦除 | 32K擦除 | 64K擦除 |
|---|---|---|---|
| MXIC | 132.10 | 176.23 | 191.34 |
| Winbond | 71.17 | 153.70 | 194.41 |
| GD | 68.97 | 142.86 | 149.53 |
| ESMT | 83.33 | 121.67 | 149.53 |
务必注意的是，上述理论性能是按Spec的Typ时间计算的，实际使用中，擦除和写的耗时随着使用寿命的增加而增加。而对于一块全新Flash来说，其写和擦除的耗时应该会比Spec的Typ时间要少。因此也就不奇怪我实测的性能会比Spec的理论性能要略高：
| 厂家 | 4K擦除 |
|---|---|
| MXIC | 140 |
| Winbond | 117 |
| GD | 88 |
| ESMT | 101 |
上述测试的性能，是不经过FS的裸设备操作性能，且驱动中完全无buffer，文件系统/驱动的缓存对性能还是有比较大影响的。此外除了硬件损耗之外，驱动软件在检查Busy标志的延时精度也会造成一些损耗。