簡介
爲了評估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標誌的延時精度也會造成一些損耗。