FatFS (elm-chan.org) 内部闪存

晚上好，我花了一些时间研究了将持久数据写入内部闪存的三个选项：（1）FATFS（ELM Chan.org/FSW/FF/00索引x.html），（2）和声的胖库，或者（3）在第52节闪存中提供的NVM函数的扩展……（3）被排除在关注的范围内。D需要更多的调试时间，而不是选择“现成的”。（2）由于开销、复杂性而被淘汰。在这些论坛上表达了一系列关于和谐的原因。这将是和声的第一次使用，所以需要熟悉一段时间来熟悉代码和文档。（1）因此，剩下FATFS，这是现在选择的方向。我不确定它是否是最好的选择。我正在寻找任何人谁已经实施FATF与内部程序Flash的见解。（a）我找不到任何样本源使用内部闪存结合FatFS。它看起来像LPC23 XX示例项目可以使用内部闪存作为一个例子。有人知道我是否可以利用一些样本资源？我发现了几个SPI串行闪存例子，但没有内部闪存。（b）我担心磨损均衡。PIC32 MZ的内部闪存由16K页与82K行组成。FATFS运行512字节扇区。扇区大小可以增加，但是小文件包含大量未使用的内存。这种“错配”看起来不太理想，可能会很快地将闪光灯擦掉——即10000擦除/写入周期。有人能解释当文件被写入时会发生什么吗？当文件系统的表被更新时，执行多少擦除/写入操作？假设分配表驻留在扇区2或页内。我在软件中看不到任何磨损均衡优化，所以我假设写数据对应用程序性能同样有害，并且对Flash的完整性征税。每个扇区写入需要一个页面擦除/写入。正确的？但是，文件系统没有优化，以解决16K页（擦除）与512字节写差异。谢谢，汤姆
                    
                    
               
                                                                                      以下为原文

                                                                            Good evening,
I spent some time researching three options for writing persistent data to internal flash:  (1) FatFS (elm-chan.org/fsw/ff/00index_e.html), (2) HARMony's FAT libraries, or (3) expansion of NVM functions provided in Section 52 Flash Memory....

(3) was eliminated over concerns that it would require more debugging time than choosing something "off-the-shelf".
(2) was eliminated  because of overhead, complexity, .... a slew of reasons expressed in these forums regarding Harmony.  This would be the first use of Harmony so there is a ramp-up time required to familiarize myself with the code and documentation.
(1) so, that leaves FatFS, which is the direction chosen for right now.  

I am not sure if it is the best option.  I am looking for insights from anybody who has implemented FatFS to work with internal program flash.

(A)  I could not find any sample source that uses internal flash in conjunction with FatFS.  It looks like the  lpc23xx sample project may use internal flash as an example.  Anybody know if there is some sample source I can leverage?  I found a couple SPI serial flash examples, but nothing for internal flash.

(B)  I am concerned about wear leveling.  The PIC32MZ 's internal flash consists of 16k pages with 8-2k rows.  FatFS operates off 512 byte sectors.  Sector size can be increased, but then small files contain a lot of unused memory  This "mismatch" seems less than optimal and could wear out the flash in a hurry - i.e. 10,000 erase/write cycles.

Can anybody explain what really happens when a file is written?  How many erase/write operations are performed when the file system's tables are updated?  Suppose an allocation table resides in sector 2 or within a page.  I don't see any wear leveling optimizations in the software, so I assume writing data is equally detrimental to application performance, and taxing on the flash's integrity.  Each sector written requires a page erase/write.  Right?  But, the file system isn't optimized to address the 16k page (erase) versus 512 byte write discrepancies.  

Thanks,
Tom