完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
最近在使用littlefs文件系统,由于要跟原系统做兼容 从官方的资料来看,littlefs有点还是很明显的, 移植完成后,测试lfs系统挂载及读写操作都没有问题, 使用littlefs时的效果 使用fat时的效果 文件使用的是同一个工程,底层SPI驱动都是完全一样的, 而且使用littlefs时,读写文件达到几K时,经常会引起系统重启, |
|
相关推荐
2个回答
|
|
建议用fal 转mtd,我用的好像速度没问题
|
|
|
|
为了验证littlefs的读写测试策略,我尝试进行了如下测试,
并将测试过程中littlefs对SPI Flash的所有操作全部打印了出来,然后进行了分析。 测试用到的代码如下(其中addr初始化的值需要每次手动更改) const char spi_test[] = "LittleFS - A high-integrity embedded file system "; char test[256]; u32 i, cnt = 0; u32 addr1=8192; int fd; fd = open("LittleFS.bin", O_WRONLY | O_CREAT, 0); for(i=0;i<4;i++) { rt_kprintf("SPI Flash write time #%d -- %dn",i , rt_tick_get()); rt_snprintf(test, sizeof(test), "%s -- %d", spi_test, rt_tick_get()); lseek(fd, addr1, SEEK_SET); write(fd, (u8 *)test, sizeof(test)); addr1 += sizeof(test); } close(fd); addr1 = 0; fd = open("LittleFS.bin", O_RDONLY, 0); for(i=0;i<36;i++) { rt_kprintf("SPI Flash read time #%d -- %dn",i , rt_tick_get()); lseek(fd, addr1, SEEK_SET); read(fd, (u8 *)test, sizeof(test)); addr1 += sizeof(test); } close(fd); 具体的测试步骤如下: 第一次测试 新建文件LittleFS.bin,从文件0地址处开始,写入四次数据,每次256字节 前两次写入时,写入块地址 —— 0x75F000,写入数据重复 “LittleFS — 177” 第三次写入时,写入块地址 —— 0x760000,先复制0x75F000处的两次数据到0x760000,再写入第三次的数据 “LittleFS — 203” 第四次写入时,写入块地址 —— 0x761000,先复制0x760000处的两次数据到0x761000,再写入第四次的数据 “LittleFS — 228 写入结束,文件大小1024Byte,存储块在0x761000处 第二次测试 从文件LittleFS.bin 4096地址处开始,写入四次数据,每次256字节 第一次写入,写入块地址 —— 0x783000,先复制0x761000处的四次数据到0x783000,然后从0x783400处写入3072Byte,填充数据到0x783FFF,再从0x784000处开始,写入本次的数据,然而数据丢失,只写入“?” 第二次写入,写入块地址 —— 0x785000,先复制0x784000处的一次数据到0x785000,再写入第二次的数据 “LittleFS — 281” 第三次写入,写入块地址 —— 0x786000,先复制0x785000处的两次数据到0x785000,再写入第三次的数据 “LittleFS — 309” 第四次写入,写入块地址 —— 0x787000,先复制0x786000处的三次数据到0x785000,再写入第四次的数据 “LittleFS — 343” 写入结束,文件大小5120Byte,存储块在0x783000->0x787000处 第三次测试 从文件LittleFS.bin 5120地址处开始,写入四次数据,每次256字节 第一次写入,写入块地址 —— 0x6B7000,先复制0x787000处的四次数据到0x6B7000,再从0x6B7400处开始,写入本次的数据 “LittleFS — 190” 第二次写入,写入块地址 —— 0x6B8000,先复制0x6B7000处的五次数据到0x6B8000,再写入第二次的数据 “LittleFS — 248” 第三次写入,写入块地址 —— 0x6B9000,先复制0x6B8000处的六次数据到0x6B9000,再写入第三次的数据 “LittleFS — 304” 第四次写入,写入块地址 —— 0x6BA000,先复制0x6B9000处的七次数据到0x6BA000,再写入第四次的数据 “LittleFS — 366” 写入结束,文件大小6144Byte,存储块在0x783000->0x6BA000处 第四次测试 从文件LittleFS.bin 8192地址处开始,写入四次数据,每次256字节 第一次写入,写入块地址 —— 0x5DD000,先复制0x6BA000处的八次数据到0x5DD000,然后从0x5DD800处写入3072Byte,填充数据到0x5DDFFF,再从0x5DE000处开始,写入本次的数据,然而数据丢失,只写入“?” 第二次写入,写入块地址 —— 0x5DF000,先复制0x5DE000处的一次数据到0x5DF000,再写入第二次的数据 “LittleFS -- 315” 第三次写入,写入块地址 —— 0x5E0000,先复制0x5DF000处的两次数据到0x5E0000,再写入第三次的数据 “LittleFS -- 344” 第四次写入,写入块地址 —— 0x5E1000,先复制0x5E0000处的三次数据到0x5E1000,再写入第四次的数据 “LittleFS -- 376” 写入结束,文件大小9216Byte,存储块在0x783000->0x5DD000->0x5E1000处 第五次测试 分36次,完全读出LittleFS.bin文件内容,对比操作地址与内容,与上面描述一致 总结一下: 1、littlefs文件系统初始化时,会在SPI Flash最开始的两个块中格式化出两个超级块,用于对文件系统的识别及根目录的索引; 2、在建立文件或目录时,littlefs会从超级块中分配一个页用于记录文件的基本信息,并建立文件数据的索引以找到文件的具体数据内容; 3、当文件大小小于一个块尺寸时,尽管文件系统不对超出的部分引索,但其他文件仍然不能使用这个块的剩余部分,所以一个文件至少占用一个块尺寸; 4、如果写入到文件中的数据超过一个块尺寸时,文件系统会在各个块中建立联系,确保数据的联系性,但各个块在物理地址上不一定连续; 5、当在一个文件中追加数据时,文件系统会复制源文件中最后不足一个块的数据到一个新的块,然后在新的块中追加要写入的数据,也就是littlefs的“磨损均衡”; 6、接上边第五条,在数据写入时,littlefs每次都会新开辟一个数据块,然后在新的数据块中添加要写入的数据,即便是对原文件覆盖写入也同样开辟一个新的块,待整个块写满或数据写完时才更新文件索引,让新的数据块在文件链路中生效, 由于数据写入的较慢,而索引更新只需一次写入即可,所以littlefs能实现“断电恢复”。 |
|
|
|
你正在撰写答案
如果你是对答案或其他答案精选点评或询问,请使用“评论”功能。
2024 RT-Thread全球巡回线下培训火热来袭!报名提问有奖!
1344 浏览 5 评论
1351 浏览 0 评论
IaaS+on+DPU(IoD)+下一代高性能算力底座技术白皮书
2511 浏览 0 评论
飞凌嵌入式-ELFBOARD 常用的USB接口及其不同版本介绍第1期
1115 浏览 0 评论
【Vision Board创客营连载体验】RA8D1-Vision Board上OSPI-Flash实践
1597 浏览 0 评论
66195 浏览 21 评论
嵌入式热门DIY项目:智能机器人开源资料合集(原理图、代码、论文)
68065 浏览 22 评论
58305 浏览 32 评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-8-27 03:26 , Processed in 1.065457 second(s), Total 39, Slave 32 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191