Spiflash基于FAT的简单日志系统.docVIP

Spi flash基于FAT的简单日志系统（FTL）设计 最近一直在想给自己做的简易Hmi组态屏做一个保证FAT的稳定层，也就是所谓的日志系统(好像听人说这类玩意有个名字叫做FTL，又叫擦写均衡算法，嘛，反正纠结名词不是我喜欢的做法，所以就叫FTL吧)。 首先我用的硬件是LPC1788+SDRAM+W25Q128的组合，软件用的是RT-Thread RTOS以及它的组件driversSpi框架和DFS文件系统，底层文件系统则是FAT。 为什么是是FAT呢？首先是考虑到拷贝数据方便。因为实际上我开发能力很弱，没多少开发经验，所以要我用一个人做LPC1788跟电脑的USB device驱动并自动读写，这是不可能的，我欠缺必要的USB知识，另外一个人搞HIM组态是很吃力的，还去学驱动是不可能有时间的，所简单的，选择直接跑Host Massstoge协议，直接读取U盘文件，因为一般我们用的都是Windows，U盘都是FAT系统，所以下面也跑FAT系统比较方便，可以实现文件拷贝。此外，因为用的是SPI flash，空间很小，但是本身坏块概率不大，如果上linux上面的那些文件系统，感觉是相当不靠谱的…… 正题，FAT文件系统本身比较简单，什么都不带，它的功能就是读取跟保存，不带其他多余的东西，不像别的系统一样带FTL算法（就是擦写均衡以及坏块管理、日志），一般情况下只要操作得当，系统是没问题，但是当所在环境不对的时候，问题就会出来了。因为FAT读写都是直接地址，比如说，它的系统信息必定会保存在一开始连着的那几块里面，而任何文件系统相关改写劲操作，都会写这部分区域。而就我们知道的，spiflash是写前要先擦除的，如果在擦除到写入这短时间整个系统掉电，那么恭喜你。你系统可能挂了！！！ 在一开始用这个的时候我就知道有这个弊端了，但是当时没办法，首先是因为我用的环境很少断电，另外，则是因为基本功能都没做完就去考虑别的是傻逼的行为！！！基本东西都没做完考虑稳定性是有毛用？ 但是后面随着自己上位机也开发出来，硬件也定型后，也得考虑怎么去解决这个问题的，因此就开始用笔在纸上画，考虑具体环境与相应解决措施： 1.系统日志 首先要考虑的是，FAT为什么会挂掉呢？说白了是表头信息丢失或者不完整，这后果简单的，只需要重新创建文件系统，下对应资源就好，但是丢失的文件是找不回来了。而严重的就是因为表信息不完整，FAT在解析一半的时候直接死机了，这时候真是没办法了，只能维修了（刷修复系统固件，拒收再刷回来）。 那么为什么别人的系统就不会挂呢？这时候想起的是一个叫“系统日志”的名词，据说稳定的文件系统都是带是日志功能的，能在文件系统挂掉的时候自动恢复。但是怎么实现呢？因为都解析错误死机了，是不可能修复的，因为已经陷入while(1)里面了（Cortex-M3 Hault Handler中断会在异常情况下触发）。 这时候我就在想，FAT会挂是因为原来的信息比改掉了，但是如果原来信息不被改掉那们情况就不一样了，如果能做到FAT在改写的时候独立出来，不改变原来的信息，在改写完了之后才会真正的把改写的信息当前表信息处理，不然就还用原来的表信息，那么系统能在一定程度上保证自己即使操作失败也是当前劲爆操作失败，但是以前的东西还在，并且还是一个完全的文件系统信息表（操作前的）！！这不就是一个简单的日志逻辑吗(能恢复到上一个状态！) 地址映射表 接着继续考虑如何来把当前的系统操作与以前的操作隔离开。 在上面是明确了，如果想保证可可恢复性，就必须具有一个完整的信息表，但是如何保证呢？一开始就已经确定了一个问题，FAT在读取这个文件系统的信息表的时候是会读取指定的块地址的，这个地址不管任何时候都不会变。那么如果建立一个表，这个表的大小与spi flash可用块数大小一样，然后在这个表里面填上另一个块的地址，然后读写的地址都通过这个表转换成真实的地址。在这样的前提下，假如我有两个表，一个是没操作前的表，已经保存，一个是在操作的表，在没操作前，表头那几个块地址是分别是1、2、3、4，而在表2，这几个块地址则是5、6、7、8，那样的话，其实改写的地址就变成了新的了，因此不会覆盖掉原来的数据，从而保证原先数据代收完整。我把这表就叫地址映射表。 3.块回收表与简单擦写均衡 但是单纯有映射表是不够的，因为块的个数是一定的，在对其进行编号后，这个编号在地址表里面最多只能存在一个，不然就可能出现同个数据块给改写，比较危险的情况是因为这个块有可能就是原本系统信息所在的块，那样的话，系统也一样是挂掉了。此外，假如新的改写成功了，那么旧的块其实就没用了，但是映射表是不带记录的，它只知道自己现在是哪块，所以这时候需要另一个表，记录所有回收回来的块，来保证重利用。 这时，有必要引入一个人们都经常说的擦写均衡算