SPI FLASH存储设计一

? ? ? ?SPI?FLASH的优点就是相对EEPRom的存储容量更大，相对于大容量的SD卡和U盘，价格有优势，但其缺点是每次写入的数据空间都要是没有写过的，否则可能都要去擦除一次扇区，在去写入数据，在擦除扇区之前还要对这个扇区之前的数据进行保存，擦除完成后，再将老数据和新数据一起写入。好的器件擦个十几万次可能都没问题，不好的器件可能几万次都扛不住。

如何解决这样的缺点？针对不同的系统可能有不同的方案。因为最近在做SPI?FLASH的数据保存和查找，所以想到了一些方案，写出来供以后再深究。

1.根据该系统能提供的最长历史记录的时间来设计。

假设我的系统最长能提供3个月的历史记录查询，那么我只要估计出每个月我的系统，最大的历史记录条数是多少？一条历史记录的字节数是多少？这里假设每个月我的系统最大的历史记录条数是1000条，一条历史记录的字节数是40个字节，那么一个扇区4096/40，这样一个月的记录大概需要十个扇区，这样3个月的记录加上一个轮询的缓冲就需要40个扇区来完成这样的系统设计。40*4094/1024=160KByte,这样的容量的SPIFALSH是很小的，所以你可以提供半年的历史记录查询都可以。优点：每个扇区的擦除次数可能3个月才有一次，查找数据快，不需要考虑数据的COPY工作。

但是这样设计系统有自己的限制：

1）受制于系统的RTC，倘若系统没有RTC，或者RTC故障，会直接影响数据的可靠和实时性。

2）每个月我的系统，最大的历史记录条数是多少？这个问题可能不是由我确定的，而是用户确定的，你不能限制用户。

3）如果最长要提供一年的历史记录，或者一条历史记录就有100Byte,你会发现这样的设计也很吃FLAH的。

2.根据该系统最多能提供多少条历史记录来设计。

假设我能提供10000条记录，每条的记录信息占80个字节，则我大约需要197个扇区。首先看优点：不受限于RTC，不受限于用户每个月的操作的次数。缺点：查找数据的范围变大，响应可能变慢，10000条数据一旦写完，回头再写时，每个扇区的老数据是保存还是不保存？不保存可能会引起用户不满，保存，势必要不断的擦除扇区，在写入数据。这里一定要注意扇区的擦除次数是有限的，要是产保3年，FLASH能不能扛的了，是要关注的首要问题。

处理上面的问题，方法可能有很多？最长见的可能是不对旧数据保存，一个扇区一旦再被写，直接先扇区擦除（如果数据很久远也到无所谓）。第二种：划出2个197个扇区，或者更多，在第一个197个扇区写满8万次的时候（这里自己设计到底写完多少次？）启用第二个197个扇区去保存数据，这样对数据的查找变得更为复杂......