Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1101620
  • 博文数量: 113
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 3944
  • 用 户 组: 普通用户
  • 注册时间: 2013-05-02 14:36
文章分类
文章存档

2019年(2)

2018年(10)

2017年(1)

2016年(50)

2015年(12)

2014年(9)

2013年(29)

分类: 嵌入式

2018-12-06 11:14:57

本文档 基于SDK13.1

 

Fds(Flash Data Storage)模块是sdk中提供的操作flash的模块。

前面介绍过fs(Flash Storage)模块,这个模块也是sdk中提供的操作flash的模块。为什么要提供两个呢?

 

这需要了解一下关于flash操作的问题。 因为操作的是片上flash,所以在擦写flash的时候CPU会暂停,这对于ble来说很可能影响底层的链路上的时序。所以对于ble应用来说,不能通过flash相关的寄存器来直接操作flash,因为你不知道你操作的时机对不对会不会对ble协议的底层交互时序造成影响。所以nordic协议栈封装了flash操作,对外提供了flash操作的接口,形如sd_flash_write 所以对于ble应用来说,我们能操作的最底层函数api就是sd开头的flash操作函数,这些sd开头的flash操作函数是异步的,即调用后不会立刻就操作flash,底层协议栈会在合适的时候,不影响或说不至于影响到ble的正常连接的时候才会实际去执行flash操作。操作结束后协议栈再抛出底层事件,告诉你flash操作的结果。

 

底层函数毕竟需要了解一些nordic协议栈的机制,以及flash操作的方式。所以nordic提供的sdk,在这些sd开头的底层函数上封装了一层来方便用户使用。即fs(Flash Storage)模块,这个模块封装了底层sd开头的API的调用以及协议栈返回的flash操作完成事件的处理。

开发者只需要注册自己的回调函数,调用初始化函数,之后就直接调用可以读/写/擦除操作来操作flash了,而不需要注意和底层flash的事件的交互,flash执行真正完成时会自动调用注册的回调函数。

只是fs封装后提供的操作接口还是保留了flash操作的特性—flash必须是要先擦除后才能写。

这就导致了还是有一定的不便性,想更新一些数据的时候,你得先把flash数据读出来,然后修改,擦除flash最后再写回flash。

关于fs 模块这里不再多介绍,之前的fs几篇文章已经详细描述了fs相关原理和操作。

 

综上为了解决fs的不便性,sdk又在fs的基础又封装了一层。形成了FDS,FDS的好处就是不仅屏蔽了和底层协议栈的事件交互(以为他依赖fs),同时也封装了更新这样的操作。Fds帮用户处理好了flash的更新,而不需要自己再去擦除flash再重写。 当然fds还提供了其他方便的特性,比如抽象了文件和记录的概念。这对上层的一些数据的组织提供了方便。比如你要存一个学校的学生记录,可以将一个班级的学生file ID设置相同,record id来区分不同的学生。

 

PS:那为什么还需要fs?直接提供一个fds不就可以了? 因为你不能限定别人的使用方式,FDS的操作方便,那就引入了一定的局限性。如果操作方式,数据格式等。当然封装的层次越多,速度上也会稍慢一点。 Fs虽然有一些不便性,但是相对更灵活。当然最灵活的还是协议栈直接开放的api  SD开头的flash操作函数。 即sdk提供了3中大类的flash操作方式,操作约方便操作的方式约受限。所以为了满足不同的可能的需求,所以sdk才将这三种操作flash的方式都提供出来。

 

我们画一下FDS,FS以及 协议栈提供的flash操作API的关系,方便后面理解。

 

下面详细介绍FDS相关的一些原理和操作。

FDS将对flash操作抽象成了类似PC上的对文件的操作。抽象出了file ID和record ID这两个概念。 第一次写flash时也同时时这个写数据的创建的时候,所以需要设置file id和record key

 

Fds组织的数据在flash上以记录的形式组织,实际存储结构如下图:

File IDrecord key 是我们使用FDS时需要使用的。对于开发者来说file id和record用来标识一个记录。在第一次将这个记录写入flash时必须指定。FDS并没有要求file idrecord key的唯一性。也就是你可以创建几个记录,他们的file id和record key都指定相同都不会有问题。

只是record key 不能设置为0x0000,0x0000表示该record是无效的

File ID不能设置为0xFFFF,0xFFFF标识无效的file id。

 

因为FDS并没有限制file id和record key的唯一性,那么如果使用的场景中的确需要有几个记录有同样的file id和record key,那么当想删除这几个记录怎么办?所以FDS内部维护了record id该字段就是每个记录再flash中的唯一标识,由FDS模块内部维护。不需要开发者操作。当删除几个file id和record key都相同的记录时,需要开发者自己调用函数 枚举找到这几个记录,虽然每次查找时传入的file id 和record key都一样,但是fds返回的记录描述符中的record id是不同的。再依次使用该返回的描述符就可以正确删除这些同样file id和record key的记录了。

 

前面介绍了FDS相对于FS来说更方便了开发者的调用,因为它封装了更新flash的函数接口,想更新某个记录的数据可以直接调用fds_record_update 函数即可。FDS的内部实现对于update操作也很快。因为FDS的更新操作并不是真的更新这个旧的数据块,以前的旧SDK比如SDK9,更新一个数据会先将数据块读取出来保存到交换区,再更新数据,最后将交换区数据写回。 FDS的实现,不会做这些操作。FDS更新数据时,直接当成一个写操作,它会找到flash中没用的空间,然后写入这个更新的数据内容。最后直接将旧的数据块的 record key设置成脏数据标记0x0000,标识改记录无效的。所以FDS的更新操作相对以前旧的SDK很快。

 

同理删除操作的原理也是一样,并不是真正的擦掉flash中的数据而是直接将数据块的record key


需要注意的是工程中并不是可以任意使用file id和record key。除了前面说的record key =0x0000标识该记录无效,file id=0xffff标识无效外

如果工程中存在 Peer Manager.模块,那么record key只能使用0x0001 - 0xBFFF.

0xC000 to 0xFFFF是PM模块内部使用的,因为PM模块内部也会使用FDS进行flash操作。 File id只能使用0x0000 - 0xBFFF.      0xC000 to 0xFFFE也是PM模块使用了。

 

FDS模块内部又很多宏都是可配置的,开发者可以更具自己实际情况配置。一般这些宏都是在sdk_config.h 配置文件中。

FDS_OP_QUEUE_SIZE: 设置flash操作队列的大小,flash操作都是异步的,所以

调用fds提供api时,其内部实际都是放入一个操作队列然后一个个执行。所以如果应用中可能有一些地方不会等待flash操作返回结果就调用多次fds的flash操作接口,那么可能需要适当增大该宏的大小。否则可能因为队列中缓存了太多flash操作而导致新调用fds的api时返回FDS_ERR_NO_SPACE_IN_QUEUES的错误。

FDS_CHUNK_QUEUE_SIZE:设置允许缓存的记录的块的个数。这里的缓存并不是缓

存内容而是缓存的地址,同样如果fds经常返回FDS_ERR_NO_SPACE_IN_QUEUES错误时,也可尝试增大该宏大小

FDS_VIRTUAL_PAGE_SIZE:  FDS模块层面的虚拟页的大小。通常就是物理页大小

不需要改。如果应用中的一个记录大小超过该大小,这里需要修改增大。

FDS_VIRTUAL_PAGES: 定义了虚拟页的个数,通常也不需要修改。如果存储的总

数据量比较大,则需要适当增大。

FDS_MAX_USERS: 回调函数最大可注册数。可能有不同的模块都需要存储自己的

       Flash数据,所以每个模块都需要注册自己的flash回调函数。

 



阅读(2423) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~