理工毕业论文嵌入式系统中的线性Flash文件系统设计

合集下载

基于NandFlash的嵌入式Linux文件系统设计

基于NandFlash的嵌入式Linux文件系统设计

DOI:10.3969/j.jssn.1009-9492.2016.z1.068基于Nand Flash的嵌入式Linux文件系统设计唐玮 任世琦 郭彦涛(广东安居宝数码科技股份有限公司 广东省广州市 510000)摘要:本文根据NAND Flash的特点,以及嵌入式Linux系统自身存在一些特殊要求,在TI DM365平台上设计了一个基于NAND Flash的嵌入式Linux文件系统,介绍了文件系统架构和功能特点,描述了一个可靠、健壮、实用的文件系统设计方案。

关键词:嵌入式;Linux文件系统;YAFFS2;CRAMFS;NAND Flash中图分类号:TP311.52 文献标识码:B 文章编号:1009-9492(2016)z1-0271-03The Design of Embedded Linux file systembased on Nand FlashTangWei, RenShiqi, GuoYantao(GuangDong Anjubao digital technology co,ltd, GuangZhou city, 510000, China)Abstract: This paper describes a reliable and practical embedded Linux system according with the special requirements of Linux system and the specifics of NAND Flash. The system is based on DM365 ,an TI CPU with ARM core, and NAND Flash. Keywords: Embedded; Linux file system; Yaffs2 CRAMFS; NAND Flash0 引言现在电子行业嵌入式设备应用越来越广泛,存储模块是系统的重要单元。

嵌入式文件系统及jffs2文件系统在Flash上的实现

嵌入式文件系统及jffs2文件系统在Flash上的实现

嵌入式文件系统及jffs2文件系统在Flash上的实现
刘金梅;张振东;路全;杨建华
【期刊名称】《河北工业大学学报》
【年(卷),期】2006(035)001
【摘要】目前嵌入式系统中大多教使用Flash作为主存,本文介绍嵌入式系统中的文件系统、存储器Flash和可读写的jffs2文件系统,通过在嵌入式操作系统uclinux上实现可读写的jffs2文件系统的实例介绍了在嵌入式系统中添加可读写文件系统的方法.
【总页数】4页(P54-57)
【作者】刘金梅;张振东;路全;杨建华
【作者单位】河北工业大学,电气与自动化学院,天津,300130;河北工业大学,电气与自动化学院,天津,300130;河北工业大学,电气与自动化学院,天津,300130;河北工业大学,电气与自动化学院,天津,300130
【正文语种】中文
【中图分类】TP368
【相关文献】
1.JFFS2文件系统在uClinux上的实现 [J], 杜睿;潘琢金;王晓菊
2.一种嵌入式Flash文件系统在机顶盒上的设计和实现 [J], 许月玲;王宏远
3.嵌入式Linux下JFFS2文件系统的实现 [J], 张勇;裘雪红
4.在CFIFLASH设备上实现JFFS2文件系统 [J], 匡杰;施亮;李树刚
5.嵌入式LINUX下的JFFS2文件系统实现 [J], 范韶辉
因版权原因,仅展示原文概要,查看原文内容请购买。

关于嵌入式Linux系统flash分区设计及文件系统格式选择的一些浅见

关于嵌入式Linux系统flash分区设计及文件系统格式选择的一些浅见

关于嵌⼊式Linux系统flash分区设计及⽂件系统格式选择的⼀些浅见嵌⼊式系统应⽤程序升级是⽐较频繁的,这就需要将flash进⾏合理的划分,⼀般情况,flash 的基本分区都有这⼏部分:1.uboot分区2.kernel分区3.rootfs分区这三部分是最基本的,⼀般都有。

如果只是这样分区,然后应⽤程序和⽂件系统放在⼀起,这样的话会导致应⽤程序升级的时候⽐较⿇烦,因为应⽤程序与⽂件系统放在了⼀起,每次升级的时候都要将⽂件系统重新擦除、写⼊,这样升级浪费时间,⽽且风险很⼤,如果正在擦除flash或者正在写⼊映像⽂件时突然断电了,就会导致设备⽆法启动了(⽂件系统损坏)!这样还必须从uboot重新下载⽂件系统,给升级带来了很⼤的⿇烦。

在嵌⼊式系统设计的时候⼀般都会将⽂件系统与经常更新的应⽤程序分离开来,放在不同的flash分区⾥,这样升级的时候只需要对应⽤程序分区进⾏擦除重新即可,这样即使升级过程中断电,也不会导致⽂件系统的损坏,系统依然可以启动。

可以将升级程序与⽂件系统放在⼀起,这样设备重新启动以后还可以对设备进⾏升级。

还有⼀种做法是在Uboot中实现升级,这样也⽆法避免断电带来的问题,其实最主要的是不能将应⽤程序与⽂件系统放在⼀起。

还有⼈在flash中做⼀个“安全模式”分区,系统如果损坏,导致设备⽆法正常启动,这时可以从安全模式启动,安全模式只提供最基本的功能,⽐如:升级,⽹络等,这些基本功能可以帮助你重新做系统。

这个也类似于windows的win PE。

总之,以升级整个⽂件系统来实现更新应⽤程序是最不可取的⽅法。

下⾯介绍⼀下嵌⼊式系统的⼏种常⽤的⽂件系统格式其实嵌⼊式根⽂件系统的格式⼤家都知道,常⽤的有jffs2,cramfs,ramdisk,以及yaffs等,他们各⾃的特点就不详细介绍了,百度、⾕歌讲的很详细了。

这⾥说⼀下我当初学习时⼀些问题和疑惑的地⽅。

1.flash分区格式刚开始总是以为flash的分区要对应⼀种格式,对这很是疑惑,不懂,别⼈问我你的根⽂件系统什么格式?都不知道怎么回答,后来发现这个flash分区是没有具体的格式的,你下载什么格式的⽂件系统,它就是什么格式的,并不是像windows下C 盘、D盘那样有FAT32格式、NTFS格式,windows下的这些格式也是格式化后才具有的格式,这个格式化的过程也相当于给这个盘⾥装了⼀个基本的⽂件系统。

一种基于NandFlash的嵌入式文件系统的设计

一种基于NandFlash的嵌入式文件系统的设计

文件管理层对整个文件系统进行封装 , 为应用层提供统

的、 标准的 A I 口, P接 把用户对文件的操作请求提交给文件
逻辑层来处理 。如 FF p ( ,SC s( ,SCet) FF SO e ) FF le ) FF r ( ,S — n o a Se( ,SR a( ,S W i ( ,SD l)FF ea e) e )FF e )F F re)FF e ,SR nm (等。 k d t ( 文件逻辑层 为文件管理层提供服务 , 把文件管理层对文 件的操作转换 为物理逻辑上 的操作 , 平均磨损控制 , 块管 坏 理, 并提交给 Fa 驱动层处理。 lh s F s 设备驱动层实现对 F s 的物理操作 , 括块 的擦 lh a lh a 包
次数没有限制。每页有 1 个字节的空闲区, 6 可作扩展功能使用 。芯片包含有失效块 , 其数 目最大可达 到 3 3 块( ~ 5 取决于存储器密度 )失效块不会影 响有效块的性能, , 但设计者需。故在文件系统 的设计 中必须考虑提高 系统的可靠性、l h F s 存储器的磨损均衡性 、 a 坏块 的 管理和文件系统的效率等问题。
嵌入式系统条件在应用时由于电源 电压 的不稳定以及突发性断 电可能对 F s 的存储器造成灾难 lh a
性的影响。另外 , 通用文件系统一般针对系统资源非常丰富的计算机平 台, 常使用大量缓存技术来提高
文件系统的速度 , 耗费的系统资源较多 , 而嵌入式系统 中系统资源十分有限。 N nF s 与其他存储器的不同点在于写操作过程 , adl h a 它的各个存储单元不可直接改写 , 需要先擦除 再写入 。通常以页为单位进行读 和编程操作 , 以块为单位进行操除操作 , 各块擦除次数有限制 , 但读 的

毕业设计(论文)样例-嵌入式专业本科

毕业设计(论文)样例-嵌入式专业本科

封面(在学校统一印制的封皮上打印相应的内容,以下为填写举例)论文题目 简化的姓名刘刚学院 东北大学东软信息学院 专 业指导教师 张三备 注2011年——作者指导教师: 张三 教授 李四 单位名称: 嵌入式系统工程系 专业名称: 电子信息工程东北大学东软信息学院2011年6月Northeastern University Neusoft Institute of InformationJune 2011Supervisor:Professor Liu Hongyi Associate Supervisor:毕业设计(论文)任务书………………………。

-Ⅱ-东北大学东软信息学院毕业设计(论文) Abstract-Ⅲ-computer network for a long time.This article mainly discusses the QoS architecture, the principle of V oIP and the two related protocols: H.323, SIP. And then, introduce some QoS control mechanisms: packet classification, admission control, QoS route and queue management.………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………….Key words: V oIP QoS, H.323 SIP RSVP Diffserv RTCP, dynamic control admission-1-任务书 .......................................................................................................... I 摘 要 .........................................................................................................II .. (III)第1章 ...................... 1 1.1 .. (1)1.2 (1)第2章 关键技术介绍 (2)2.1 简 ......................................2 2.2 .. (2)第3章 (3)3.1 (3)3.1.1 软件功能构架 ···············································3.1.2 硬件功能框图 ··············································· 3.2 系统开发环境3.3 ·3.3.1 (4)3.3.2 (4)第4章 系统设计 (6)4.1 设计指导思想和原则 (6)4.1.1 指导思想 ................................................................................................................ 6 4.1.2 设计原则 . (6)4.2 系统概述 (6)东北大学东软信息学院毕业设计(论文)目录4.3系统功能结构设计 (6)4.3.1实现单片机与外围存储器的技术连接 (6)4.3.2LED数码管的电路设计 (6)4.3.3rs232串行接口电路设计 (6)4.3.4键盘接口电路设计 (6)4.4系统UI界面设计 (6)4.5系统控制流程 (6)第5章系统实现 (7)5.1系统软件的实现 (7)5.1.1系统软件框图 (7)5.1.2系统程序流程图 (10)第6章系统测试 (12)6.1测试方案及测试用例 (12)6.1.1LED显示 (12)6.1.2键盘响应 (12)6.1.3串口收发 (12)6.1.3UI界面测试 (12)第7章结论 (13)附录1原理图 (14)附录2PCB图 (15)附录3实物图 (16)参考文献 (17)致谢 (18)-2-1章 绪论 说明:在绪论中简要说明设计(论文)工作的目的、意义、范围、研究设想、方法、选题依据等。

FLash毕业论文

FLash毕业论文

江汉艺术职业学院JIANGHAN ART VOCATIONAL COLLEGE毕业论文(设计)题目: 多媒体动画制作技术系部: 信息技术系专业班级: 08计科一班学号: 20097058学生姓名:况天佑指导教师:李云龙2010年1 2月2 6日摘要Flash软件由Macromedia公司推出,除了制作动画以外,还能实现交互功能。

Flash是一种创作工具,设计人员和开发人员可使用它来创建演示文稿、应用程序和其它允许用户交互的内容。

Flash 可以包含简单的动画、视频内容、复杂演示文稿和应用程序以及介于它们之间的任何内容.它不仅能够制作出许多眩目多彩的效果,只要你肯赋予它一定的情景,它也会模拟出现实生活中的场景.通过flash生成的动画文件非常小,可以很好的用在网页设计及更多的领域。

Flash制作动画比较简单,你只要定义好各个关键帧,当中的过程由计算机自动生成.它在制作动画方面和秘密武器是多层透明效果和变形技术,再结合按钮符号的交互功能,就能制作出炫目的动画关键词:Flash+photoshop+Dreamweave目录第1章项目总体规划 ....................................................... 错误!未定义书签。

第2章介绍Flash .............................................................. 错误!未定义书签。

2。

1 flash简介...................................................................... 错误!未定义书签。

2。

2 flash的前景.................................................................. 错误!未定义书签。

2。

2。

1出现初期......................................................... 错误!未定义书签。

一种微嵌入式Flash文件系统_effs

一种微嵌入式Flash文件系统_effs

一种微嵌入式Flash文件系统——μEFFS摘要:针对Flash存储器的特性提出一种分层文件系统架构,抽象出逻辑存储器作为中间层,屏蔽了底层物理器件操作上的不足。

本文件系统非常适合1GB以下容量的Flash存储器,具有可移植性高、访问效率高、寿命均衡等特性。

关键词: Flash存储器, Block, Page, 逻辑存储器, FAT随着嵌入式系统应用的迅速发展,嵌入式系统被广泛应用于各行各业,嵌入式系统的数据存储问题随之变成了一个最核心的关键问题。

由于Flash器件的迅速普及,使得Flash存储器的使用变得十分重要。

同时,Flash器件本身固有的擦写寿命、不可字节擦除等特点也使Flash器件存储管理变得非常复杂。

目前嵌入式系统领域已有了一些较为成熟的Flash文件系统,如:嵌入式Linux中普遍使用的JFFS2日志文件系统、YAFFS文件系统。

但是这些文件系统本身比较大,适合于大系统运行;并且经实践检验,这些文件系统对寿命的均衡处理并不像宣传的那样好,文件系统效率和可靠性也有待提高。

本文通过中间抽象逻辑存储器建立一种短小精炼、高性能、高可靠性、适合于嵌入式小型设备的嵌入式Flash文件系统——μEFFS。

实际上,通过更改底层物理存储器(软件),此文件系统也可以很方便地移植到其他器件上。

而且通用文件系统(如:FAT文件系统)很容易移植到本文提出的中间层逻辑存储器上,从而使得通用文件系统也获得了Flash文件系统的特性,如:寿命均衡。

1 Flash存储器特性(1)NAND Flash器件特点:高存储密度,采用页读写(读写速度快)、块擦除方式操作;容易发生位反转;存在坏块(存储不可靠性);容量一般较大(大于32MB);擦写寿命一般为100万次。

(2)NOR Flash器件特点:随机读写、块擦除;坏块少;器件本身存储可靠性高;擦写速度较慢;容量一般较小(小于16MB),擦写寿命一般为10万次。

(3)块(block):擦除的最小单元。

基于FLASH的嵌入式文件系统设计及应用的开题报告

基于FLASH的嵌入式文件系统设计及应用的开题报告

基于FLASH的嵌入式文件系统设计及应用的开题报告写作目的:本开题报告旨在介绍一种基于FLASH的嵌入式文件系统的设计及其应用的研究。

该研究主要针对嵌入式系统中文件存储效率低下、易丢失等问题,探讨如何构建一种高效可靠的文件系统,提升文件系统的稳定性和可靠性。

写作内容:本文主要从如下几个方面进行阐述:1. 嵌入式系统文件系统现状:介绍目前广泛采用的文件系统以及其存在的问题。

2. FLASH存储技术简介:阐述FLASH存储技术的基本原理及其特点。

3. 基于FLASH的嵌入式文件系统设计:详细介绍设计思路、实现方法及技术细节。

考虑到实际应用中可能会出现文件整理、文件查找、文件读写等复杂场景,本文还将介绍如何应对这些问题。

4. 嵌入式文件系统的应用:阐述该文件系统在实际应用中的优势和劣势,同时也将展示该文件系统的一些应用场景和案例。

5. 计划和成果预期:介绍本研究的计划安排以及成果预期。

写作计划:1. 预计撰写时间为2个月,初稿完成后再进行修改和优化。

2. 撰写时重点关注嵌入式系统的文件系统问题以及FLASH存储技术的特点,逐步完善文件系统设计并进行初步实验。

3. 在第三个月中,进行一定数量的测试、验证等工作,并对研究成果进行归纳总结。

4. 在第四个月中,进行最终完善和修改。

预期成果:1. 提出一种基于FLASH的嵌入式文件系统设计方案。

2. 证明该方案具有高效、稳定、可靠等优点。

3. 探究了该文件系统在实际应用中的不同应用场景,并给出对应的案例。

4. 通过实验验证,证明该设计的可行性和实用性。

5. 实现了该文件系统的基本功能,具有一定的市场推广价值。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

嵌入式系统中的线性Flash文件系统设计在嵌入式系统中,为了便于对闪存(Flash)空间进行管理,会采用文件的形式来访问Flash。

目前,可以购买到的Flash文件系统一般都是兼容DOS的文件系统(Flash File System,FFS),这对需要一个具有复杂的目录层次,并且DDS文件兼容的系统来说是必要的;但是对大多数的嵌入式应用来说,这种文件系统太过奢侈。

笔者在参与嵌入式系统项目的时候,设计了一种线性文件系统,它适用于大多数的嵌入式应用对Flash文件系统的需求。

线性文件系统设计基于三个目标:一是提供给应用程序通过文件名而不是物理地址访问系统Flash的能力;二是文件系统的设计独立于实时操作系统(RTOS),这样可以很容易移植到不同的嵌入式应用中;三是设计统一的底层接口,适应不同的Flash类型。

本文设计的线性文件系统为典型的嵌入式系统提供了所需的类文件系统能力。

需要注意的是,本文件系统不支持复杂的Flash扇区擦写次数均衡算法,没有目录层次,并且和其它的文件系统不兼容。

1 线性文件系统线性文件系统的设计思路是这样的:文件分为文件头和文件数据区两个部分,每个文件按照顺序存放在Flash中,以单向链表来链接文件。

文件的起始部分是文件头,包含文件的属性、指向下一个文件头的指针、文件头和文件数据区的32位循环冗余校验和(CRC32)等。

文件头用一个32位的字来表示文件属性,每位表示一种属性,如数据文件或者是可执行文件,是否已删除的文件等,具体可以根据应用的需要来定义文件的属性;文件头和文件数据区维护独立的CRC32校验,使文件系统能更精确检测文件的完整性。

文件的起始地址没有特殊需求,分配给文件系统的Flash大小限制了文件的大小。

另外,线性文件系统作为嵌入式系统的一个功能模块,它为应用程序提供与标准文件系统类似的API接口,如:read()、write()、open()、close()、stat()和seek()等。

对于同时在多片Flash的系统而言,每片Flash相当于一个目标,文件都可存储在任何一片中(当然受物理空间限制),但不能跨片存储。

图1 Flash文件系统空间在第一个文件创建之前,必须进行初始化,将所有分配给文件系统的Flash空间擦除。

当创建第一个文件时,起始位置从文件系统的起始地址开始,文件头指针指向下一个空文件的起始位置(链表尾部);第二个文件的位置从当前的链表尾部开始,同时文件头中的链表指针指向新的尾部。

删除文件时,仅仅是简单地把文件头的标识位中的活动文件标识位置0,表示删除。

这样,在经过多次删除之后,就有必要运行碎片整理模块来进行文件系统Flash空间的碎片整理。

碎片整理模块还需要在文件系统Flash 空间尾部留一个扇区来数据备份,以便当碎片整理被打断时(如下电或者复位)可以恢复文件系统。

这个保留的扇区称空闲扇区。

它必须放在文件系统空间之后,这样可以保证文件系统的所有文件在所占用的Flash空间是连续的。

整个文件空间的分配如图1所示。

阴影部分是文件头,数据结构如下:struct hdr{unsigned short hdrsize; /*文件头字节数*/long filsize; /*文件头版本*/long filsize; /*文件大小*/long flags; /*描述文件的标识*/unsigned long filcrc; /*文件数据的CRC32的值*/unsigned long hdrcec; /*文件的最后修改时间*/struct hdr *next; /*指向下一个文件头的指针*/char name[NAMESIZE]; /*文件名*/char info[INFOSIZE]; /*文件描述信息*/};碎片整个记录区包含两种数据类型:碎片整理文件头信息表defraghdr和文件区扇区整理前后的CRC值备份表sectorcre。

具体的地址分配从空闲扇区的起始地址减1开始,往前分配文件系统扇区数乘以4字节作为sectorcrc的空间;从sectorcrc起始地址减1开始,往前分配活动文件个数乘以64字节作为碎片整理文件头信息表。

这两个结构定义如下:在嵌入式系统中,为了便于对闪存(Flash)空间进行管理,会采用文件的形式来访问Flash。

目前,可以购买到的Flash文件系统一般都是兼容DOS的文件系统(Flash File System,FFS),这对需要一个具有复杂的目录层次,并且DDS文件兼容的系统来说是必要的;但是对大多数的嵌入式应用来说,这种文件系统太过奢侈。

笔者在参与嵌入式系统项目的时候,设计了一种线性文件系统,它适用于大多数的嵌入式应用对Flash文件系统的需求。

线性文件系统设计基于三个目标:一是提供给应用程序通过文件名而不是物理地址访问系统Flash的能力;二是文件系统的设计独立于实时操作系统(RTOS),这样可以很容易移植到不同的嵌入式应用中;三是设计统一的底层接口,适应不同的Flash类型。

本文设计的线性文件系统为典型的嵌入式系统提供了所需的类文件系统能力。

需要注意的是,本文件系统不支持复杂的Flash扇区擦写次数均衡算法,没有目录层次,并且和其它的文件系统不兼容。

1 线性文件系统线性文件系统的设计思路是这样的:文件分为文件头和文件数据区两个部分,每个文件按照顺序存放在Flash中,以单向链表来链接文件。

文件的起始部分是文件头,包含文件的属性、指向下一个文件头的指针、文件头和文件数据区的32位循环冗余校验和(CRC32)等。

文件头用一个32位的字来表示文件属性,每位表示一种属性,如数据文件或者是可执行文件,是否已删除的文件等,具体可以根据应用的需要来定义文件的属性;文件头和文件数据区维护独立的CRC32校验,使文件系统能更精确检测文件的完整性。

文件的起始地址没有特殊需求,分配给文件系统的Flash大小限制了文件的大小。

另外,线性文件系统作为嵌入式系统的一个功能模块,它为应用程序提供与标准文件系统类似的API接口,如:read()、write()、open()、close()、stat()和seek()等。

对于同时在多片Flash的系统而言,每片Flash相当于一个目标,文件都可存储在任何一片中(当然受物理空间限制),但不能跨片存储。

图1 Flash文件系统空间在第一个文件创建之前,必须进行初始化,将所有分配给文件系统的Flash空间擦除。

当创建第一个文件时,起始位置从文件系统的起始地址开始,文件头指针指向下一个空文件的起始位置(链表尾部);第二个文件的位置从当前的链表尾部开始,同时文件头中的链表指针指向新的尾部。

删除文件时,仅仅是简单地把文件头的标识位中的活动文件标识位置0,表示删除。

这样,在经过多次删除之后,就有必要运行碎片整理模块来进行文件系统Flash空间的碎片整理。

碎片整理模块还需要在文件系统Flash 空间尾部留一个扇区来数据备份,以便当碎片整理被打断时(如下电或者复位)可以恢复文件系统。

这个保留的扇区称空闲扇区。

它必须放在文件系统空间之后,这样可以保证文件系统的所有文件在所占用的Flash空间是连续的。

整个文件空间的分配如图1所示。

阴影部分是文件头,数据结构如下:struct hdr{unsigned short hdrsize; /*文件头字节数*/long filsize; /*文件头版本*/long filsize; /*文件大小*/long flags; /*描述文件的标识*/unsigned long filcrc; /*文件数据的CRC32的值*/unsigned long hdrcec; /*文件的最后修改时间*/struct hdr *next; /*指向下一个文件头的指针*/char name[NAMESIZE]; /*文件名*/char info[INFOSIZE]; /*文件描述信息*/};碎片整个记录区包含两种数据类型:碎片整理文件头信息表defraghdr和文件区扇区整理前后的CRC值备份表sectorcre。

具体的地址分配从空闲扇区的起始地址减1开始,往前分配文件系统扇区数乘以4字节作为sectorcrc的空间;从sectorcrc起始地址减1开始,往前分配活动文件个数乘以64字节作为碎片整理文件头信息表。

这两个结构定义如下:在嵌入式系统中,为了便于对闪存(Flash)空间进行管理,会采用文件的形式来访问Flash。

目前,可以购买到的Flash文件系统一般都是兼容DOS的文件系统(Flash File System,FFS),这对需要一个具有复杂的目录层次,并且DDS文件兼容的系统来说是必要的;但是对大多数的嵌入式应用来说,这种文件系统太过奢侈。

笔者在参与嵌入式系统项目的时候,设计了一种线性文件系统,它适用于大多数的嵌入式应用对Flash文件系统的需求。

线性文件系统设计基于三个目标:一是提供给应用程序通过文件名而不是物理地址访问系统Flash的能力;二是文件系统的设计独立于实时操作系统(RTOS),这样可以很容易移植到不同的嵌入式应用中;三是设计统一的底层接口,适应不同的Flash类型。

本文设计的线性文件系统为典型的嵌入式系统提供了所需的类文件系统能力。

需要注意的是,本文件系统不支持复杂的Flash扇区擦写次数均衡算法,没有目录层次,并且和其它的文件系统不兼容。

1 线性文件系统线性文件系统的设计思路是这样的:文件分为文件头和文件数据区两个部分,每个文件按照顺序存放在Flash中,以单向链表来链接文件。

文件的起始部分是文件头,包含文件的属性、指向下一个文件头的指针、文件头和文件数据区的32位循环冗余校验和(CRC32)等。

文件头用一个32位的字来表示文件属性,每位表示一种属性,如数据文件或者是可执行文件,是否已删除的文件等,具体可以根据应用的需要来定义文件的属性;文件头和文件数据区维护独立的CRC32校验,使文件系统能更精确检测文件的完整性。

文件的起始地址没有特殊需求,分配给文件系统的Flash大小限制了文件的大小。

另外,线性文件系统作为嵌入式系统的一个功能模块,它为应用程序提供与标准文件系统类似的API接口,如:read()、write()、open()、close()、stat()和seek()等。

对于同时在多片Flash的系统而言,每片Flash相当于一个目标,文件都可存储在任何一片中(当然受物理空间限制),但不能跨片存储。

图1 Flash文件系统空间在第一个文件创建之前,必须进行初始化,将所有分配给文件系统的Flash空间擦除。

当创建第一个文件时,起始位置从文件系统的起始地址开始,文件头指针指向下一个空文件的起始位置(链表尾部);第二个文件的位置从当前的链表尾部开始,同时文件头中的链表指针指向新的尾部。

相关文档
最新文档