传感器开发平台
登录
直播中
赵伟
7年用户
117经验值
私信
关注
嵌入式linux软件怎么进行数据参数保存?
开启该帖子的消息推送
嵌入式
大多数软件开发都会涉及到数据参数的保存与读取,小至运行的
单片机
的软件,大至操作系统级别的软件(如linux,windows,mac),均会有专门的子程序或者模块进行参数的保存和读取。不同的平台下开发,参数的保存与读取会存在一定的差异化,例如,单片机下,保存参数是写入eeprom或者 rom,windows和linux下的软件则会以配置文件的形式保存参数。下面以我以前在工作中所遇到情况,重点写写嵌入式linux软件是如何进行的数据参数的保存。
回帖
(1)
刘艳芳
2020-4-7 16:23:46
一 以二进制数据保存参数。
以二进制形式保存参数是很是常见的一种方案,也是很多项目组用于保存参数的一种方案。以我们现有的软件平台中的方案为例吧。
我们的软件平台基于嵌入式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{
char usename[16];
char password[16];
};
int fd = -1;
fd = open(/dev/mtdblock5, O_RDWR);
struct _Parameter sys_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的变量地址。
int fd = -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,会给移植造成一定的阻碍。
二 以文本的形式保存参数。
数据以文本的形式保存到一个参数数据文件。有过windows下软件开发经验的同学,一定清楚windows下配置文件---ini文件。很多windows下的应用程序采用ini的格式文件进行配置参数的保存,ini文件同样也适用于linux下。 ini的格式如下。
[login]
username=dcdclook
password=123456
上面提出的二进制保存数的几个不足之处,恰恰就是文本形式保存参数的优点。
我们可以很容易的进行数据扩展,用户名想要定义为17个字符?行,
[login]
username=dcdclook89abcdefghikj
password=123456
随便一个文本编缉工具就可以查看系统参数。保存的参数的数据内容对我们来说是完全可见的
由于不关联硬件设备文件,移植以来容易。
当然文本的形式保存参数也不可避免的存在着一个问题,解析花的时间会较二进制数据保存参数方案长那么一点点。
其它常见的文本保存参数格式有xml,较之ini文件,xml可以实现多层数据参数的写入。
三 用数据库来保存参数。
常见的嵌入式关系型数据库SQLite,单纯的用SQLite来进行配置参数数据的保存与读取,个人觉得并不是一个合理方案,有点杀鸡用牛刀的意味。
在一些特定的嵌入式开发应用场景中,sqlite 还是有有武之地。例如,手机中的通信录(Android系统中就集成数据库Sqlite)。
没有最好的技术,只有最合适的技术。具体采用何种参数,可以依实际的需求进行选择。
一 以二进制数据保存参数。
以二进制形式保存参数是很是常见的一种方案,也是很多项目组用于保存参数的一种方案。以我们现有的软件平台中的方案为例吧。
我们的软件平台基于嵌入式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{
char usename[16];
char password[16];
};
int fd = -1;
fd = open(/dev/mtdblock5, O_RDWR);
struct _Parameter sys_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的变量地址。
int fd = -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,会给移植造成一定的阻碍。
二 以文本的形式保存参数。
数据以文本的形式保存到一个参数数据文件。有过windows下软件开发经验的同学,一定清楚windows下配置文件---ini文件。很多windows下的应用程序采用ini的格式文件进行配置参数的保存,ini文件同样也适用于linux下。 ini的格式如下。
[login]
username=dcdclook
password=123456
上面提出的二进制保存数的几个不足之处,恰恰就是文本形式保存参数的优点。
我们可以很容易的进行数据扩展,用户名想要定义为17个字符?行,
[login]
username=dcdclook89abcdefghikj
password=123456
随便一个文本编缉工具就可以查看系统参数。保存的参数的数据内容对我们来说是完全可见的
由于不关联硬件设备文件,移植以来容易。
当然文本的形式保存参数也不可避免的存在着一个问题,解析花的时间会较二进制数据保存参数方案长那么一点点。
其它常见的文本保存参数格式有xml,较之ini文件,xml可以实现多层数据参数的写入。
三 用数据库来保存参数。
常见的嵌入式关系型数据库SQLite,单纯的用SQLite来进行配置参数数据的保存与读取,个人觉得并不是一个合理方案,有点杀鸡用牛刀的意味。
在一些特定的嵌入式开发应用场景中,sqlite 还是有有武之地。例如,手机中的通信录(Android系统中就集成数据库Sqlite)。
没有最好的技术,只有最合适的技术。具体采用何种参数,可以依实际的需求进行选择。
举报
更多回帖
rotate(-90deg);
回复
相关问答
嵌入式
嵌入式
软件
开发
数据
参数
怎么
保存
?
2020-04-02
1447
如何去实现
嵌入式
LINUX
驱动的
软件
代码呢
2021-12-24
641
嵌入式
软件
开发需要学习什么?
2016-01-31
3896
Linux
作为
嵌入式
操作系统的优势是什么?如何建立
嵌入式
Linux
?
2021-04-27
2339
如何使用PCS
进行
嵌入式
Linux
研究?
2019-08-13
1336
求一种基于ARM芯片和
嵌入式
操作系统
Linux
2021-06-04
1227
如何学习
嵌入式
linux
?学习
嵌入式
linux
有什么技术门槛吗?
2021-10-20
1370
嵌入式
linux
学***汇总
2020-06-08
2626
Linux
嵌入式
操作系统有什么优势?
2019-08-20
3685
嵌入式
软件
学什么?怎样去学呢
2021-12-24
1032
发帖
登录/注册
20万+
工程师都在用,
免费
PCB检查工具
无需安装、支持浏览器和手机在线查看、实时共享
查看
点击登录
登录更多精彩功能!
英国威廉希尔公司网站
william hill官网 版块
小组
免费开发板试用
ebook
直播
搜索
登录
×
20
完善资料,
赚取积分