嵌入式linux软件数据参数保存的三种方式

2019独角兽企业重金招聘Python工程师标准>>>

    大多数软件开发都会涉及到数据参数的保存与读取，小至运行的单片机的软件，大至操作系统级别的软件(如linux，windows，mac)，均会有专门的子程序或者模块进行参数的保存和读取。不同的平台下开发，参数的保存与读取会存在一定的差异化，例如，单片机下，保存参数是写入eeprom或者rom，windows和linux下的软件则会以配置文件的形式保存参数。下面以我以前在工作中所遇到情况，重点写写嵌入式linux软件是如何进行的数据参数的保存。

    一、用数据库来保存参数。

    常见的嵌入式关系型数据库SQLite，单纯的用SQLite来进行配置参数数据的保存与读取，个人觉得并不是一个合理方案，有点杀鸡用牛刀的意味。

    在一些特定的嵌入式开发应用场景中，sqlite还是有有武之地。例如，手机中的通信录(Android系统中就集成数据库Sqlite)。

    二、以文本的形式保存参数。

    数据以文本的形式保存到一个参数数据文件。有过windows下软件开发经验的同学，一定清楚windows下配置文件---ini文件。很多windows下的应用程序采用ini的格式文件进行配置参数的保存，ini文件同样也适用于linux下。ini的格式如下。

    [login]

    username=dcdclook

    password=123456

    上面提出的二进制保存数的几个不足之处，恰恰就是文本形式保存参数的优点。

    我们可以很容易的进行数据扩展，用户名想要定义为17个字符?行，

    [login]

    username=dcdclook89abcdefghikj

    password=123456

    随便一个文本编缉工具就可以查看系统参数。保存的参数的数据内容对我们来说是完全可见的

    由于不关联硬件设备文件，移植以来容易。

    当然文本的形式保存参数也不可避免的存在着一个问题，解析花的时间会较二进制数据保存参数方案长那么一点点。

    其它常见的文本保存参数格式有xml，较之ini文件，xml可以实现多层数据参数的写入。

    三、以二进制数据保存参数。

    以二进制形式保存参数是很是常见的一种方案，也是很多项目组用于保存参数的一种方案。以我们现有的软件平台中的方案为例吧。

    我们的软件平台基于嵌入式linux，　flash芯片容量是16M，flash芯片被分为了五个区，如下所示，其中parameter分区用于数据参数的存储。

    |uboot|kernel|rootfs|app|parameter|

    -----------------------------------------------------------------------------

    uboot分区对应设备文件/dev/mtdblock0

    kernel分区对应设备文件/dev/mtdblock1

    rootfs分区对应设备文件/dev/mtdblock2

    app分区对应设备文件/dev/mtdblock3

    parameter分区对应设备文件/dev/mtdblock4

    假设我们想要保存用户名与密码。

    1、定义一个结构体，结构体成员包含用户名与密码

    struct_Parameter{

    charusename[16];

    charpassword[16];

    };

    intfd=-1;

    fd=open(/dev/mtdblock5，O_RDWR);

    struct_Parametersys_parameter;

    2、填充sys_parameter的成员usename和password，假若username为dodolook，密码为123456

    strncpy(sys_parameter.username，“dodolook”，16);

    strncpy(sys_parameter.password，“123456”，16);

    3、将sys_parameter以二进制的形式写入flash分区5的映射的设备文件/dev/mtdblock4.

    write(fd，&sys_parameter，sizeof(struct_Parameter));

    参数的读取

    从设备文件/dev/mtdblock4读取sizeof(struct_Parameter)大小的字节到所定义的参数结构体sys_parameter的变量地址。

    intfd=-1;

    fd=open(/dev/mtdblock5，O_RDWR);

    read(fd，&sys_parameter，sizeof(struct_Parameter));

    上述的保存参数的过程，与单片机开发的参数保证颇有几份相似之处，早期的嵌入式软件开发工程师大多有过单片机软件开发的经历，在单片机中，参数会写入一个eeprom芯片(部分单片机自身集成eeprom芯片)，当有着单片机开发经历的工程师转行到嵌入式软件开发，不可避免的沿续了以前的工作经验，也许这便是我们系统中数据参数存储方案的来历。

    二进制数据保存参数的方案的确存在速度的优势，但同时也存在着以下几个不是避免的问题。

    1、对现有数据进行扩展极为不便。

    例如在设计时，我们理所当然的想到，16个字符完全足够能够显示一个用户名，假设，客户提一个特别变态的需求，需要输入17个字符。怎么办?动之以情，晓之以理，劝劝客户别提这么变态的需求。可人客户不听，怎么办?只能重新定义结构体。这下更好了，新的参数结构体与早先的软件不兼容。怎么办?定义客户编绎开关，只有此客户才用到此编绎开关。行，问题是解决了，随意的添加工编绎开关，又为后期的维护埋下的定时炸弹。

    2、无法直接查看编缉参数。

    保存的参数对我们来说是不透明的，不可交互的。在软件开发，我们常常遇到由于参数区数据被破坏而引发的bug，我们为会拷贝参数区到一个文件，与正常的参数区二进制进行对比，以确定参数区是否被破坏。存入参数区的数据为二进制数据，二进制式数据对我们来说，几乎不具有可读性，进而影响到软件的可维护性。

    3、软件移植起来困难。

    如果我们想把软件从嵌入式平台移植linux(或者windows)下进行开发，由于参数保存关联到设备文件/dev/mtdblock4，会给移植造成一定的阻碍。

    想必各位看了这篇文章之后一定会有所收货，若想了解更多相关知识请继续锁定希赛系统学院！

转载于:https://my.oschina.net/u/2514712/blog/596731