armink/EasyFlash

设备首次初始化时触发整个Flash芯片GC时间比较长，导致产品生产节拍较慢

HikerPan opened this issue · 7 comments

HikerPan commented

Hi armink，

  • 去年在研发一个新产品是使用了您的easyflash，后来也陆续接触到您的sfud，easyloger以及RTT等，觉得都是非常好的作品。给了我很多学习的机会，也将他们陆续应用在我的产品上。

  • 目前，去年研发的这个产品即将量产，有一个问题比较困扰我。就是每一个产品第一次刷入程序后，easyflash检车Sector header，发现没有Format，这是就会逐个将进行格式化(也就是GC吧)。这个时间非常长，我使用的是W25Q256，每个Sector擦除的典型时间是50ms，这就导致了一个完整的芯片格式化做下来要接近6分钟。这在批量生产产品的时候，是非常大的时间浪费。

想向您请教：
1.不知道我有没有用错，或者理解错，导致这个时间非常长？我查看了一下，貌似没有其他人提出这个问题，我有点担心是我哪里理解错了。
2.有没有办法优化这个时间？比如如果发现整个Flash都没有GC过，那么就直接整个chip擦除，我看到W25Q256的整片擦除时间是80s。这个时间与SFUD中的70+s是基本一致的，SFUD benchmark W25Q256时应当用的是整片擦除吧？

查看了一下，我的EasyFlash版本为4.0.99

armink commented
  • 1、能先说下你的应用场景吗？如果参数非常的多的话，建议使用 https://github.com/armink/FlashDB ，它支持分区管理，可以对参数进行分类，一定程度上提升了操作的效率
  • 2、首次开始时的功能称作格式化，你这个有 6 分钟，确实挺长的。先回答下第一个问题，了解了功能场景及数据量之后，会更容易定位问题。
HikerPan commented

W25Q256一共32MB空间，其中最后的1MB用于IAP了。
另外的31MB有两个主要用途：
1.一些系统参数的存储，大约4K左右；
2.设备在通信不良的时候，将通过网络无法发送的数据，以KV的形式存储于easyflash中，待网络状态恢复进行数据补发。
格式化6分钟，是以W25Q256的典型擦除时间算出来的，实际使用时，也进行了计时，确实需要这么长时间。现在数据的使用时没有问题的。主要问题时，当产品生产过程中，第一次刷入程序以后，easyflash需要全盘格式化，这个时间比较长。每一台设备都这么长时间的话，整体生产效率就下降了。估计量产时，我们产线会有比较大的意见，所以在考虑如何解决。

armink commented

确定只有 4 K 的参数区域吗？那不会有这么长时间的格式化时间的，肯定小于 1S 。建议上仿真器，看下当前到底在干嘛？是不是地址长度配置错误

HikerPan commented

是这样的，后面的31MB都是easyflash的，应该说都是的当成env的。只不过这些env分了2类，一类是4K的参数，另一类是其他的通信数据。
难道是我只应该把参数作为env？但是其他的通信数据我如何通过easyflash操作呢？

armink commented

通信的数据都有什么特性？比如：长度一般多大，是否经常修改，是否经常增加等等

另外，也建议了解一下 FlashDB https://github.com/armink/FlashDB 里的时序数据库功能

HikerPan commented

通信数据长度不定，一般一条数据存下来了在发送给服务器之前就不会改。
我刚才想我把通信数据当成log存在log区里面会不会就可以了？
是不是只有env的才需要格式化？

armink commented

是的呀，一些不用改的数据，不用存放在 env 里