这些小活动你都参加了吗?快来围观一下吧!>>
电子产品世界 » 论坛首页 » 嵌入式开发 » 软件与操作系统 » 谈谈嵌入式软件的兼容性!

共2条 1/1 1 跳转至

谈谈嵌入式软件的兼容性!

高工
2023-08-24 09:12:29     打赏

嵌入式项目中,软件是一个不断迭代的过程,需要考虑各种兼容性。之前我们的项目,因为这方面考虑得比较少,导致项目中后期开发起来很被动。

项目系统总体设计阶段,应尽可能地考虑到未来可以遇见的情况,覆盖到尽可能多的业务扩展。项目虽然分阶段开发,各个阶段完成的功能都不一样,总体设计要指向最终的需求。

数据兼容性1、协议制定

制定的协议要满足整个项目所有数据的交互。

比如:

image.png

这里的 ID 设置为 1 个字节,可能有一定的风险。后面功能加着加着,可能 1 个字节的 ID 满足不了,就得改协议。尽管可能满足了某个项目的需求,但万一之后其它项目也用了这一套代码,但是 1 个字节的 ID 满足不了,又得改代码。这里设置 2 字节可能会好一点,基本上能满足绝大部分情况的使用。

不一定为了覆盖范围更广而设置 4 字节,这样可能有点冗余。很多情况都有一个平衡点,需要自己权衡。

Length字段只设置了 1 个字节,可能也有一定的奉献。后面功能中如果有发较大的数据,可能要分好多包发,原本可以发得很快,被这里限制死了。到时候想要提速,就得改协议。

之前项目里,几块板间的通信都用同一套协议。但后期发现该协议满足不了新需求,但为了不影响到前面的数据,又搞了一套协议。导致项目里有两套差不多一样的协议处理代码。

协议应该是项目一开始考虑好、制定好,整个项目开发期间,都不应该再做改动。

2、数据添加

后面新增的数据,不应该插入现有的数据中,应该单独增加一个数据ID。

比如:

现有的数据中,有一条数据叫做设备信息的数据,设备信息里包含了:设备IP、设备Mac。这个数据会显示在手机APP上。对应的 C 语言代码:

#define  MSG_ID_DEV_INFO   0x0001

typedef struct _dev_info
{
 char dev_ip[IP_MAX_LEN];
 char dev_mac[MAC_MAX_LEN];
}dev_info_t;

假如后面需要再显示一个设备的sn,这个数据我们应该加在哪里?

如果是项目前中期,这时候还是在开发阶段,我们可以随意修改。因为设备sn也是设备信息的一部分,可以直接在设备信息这个数据里添加会比较合理:

#define  MSG_ID_DEV_INFO   0x0001

typedef struct _dev_info
{
 char dev_ip[IP_MAX_LEN];
 char dev_mac[MAC_MAX_LEN];
    char dev_sn[SN_MAX_LEN];
}dev_info_t;

如果是产品已经在市场上流通,这时候这么加的话,软件兼容性就不太好。因为假如你的手机APP版本与设备版本不匹配,原有的设备IP及设备MAC这两个设备信息可能都显示不出来,因为我们这么一改,破坏了原有的数据结构,而手机APP按照原来的数据来做解析的,会解析不过。

这时候可以这么来加:

#define  MSG_ID_DEV_INFO   0x0001
#define  MSG_ID_DEV_SN     0x0002

typedef struct _dev_info
{
 char dev_ip[IP_MAX_LEN];
 char dev_mac[MAC_MAX_LEN];
}dev_info_t;

typedef struct _dev_sn
{
    char dev_sn[SN_MAX_LEN];
}dev_sn_t;

这样,哪怕手机APP版本与设备版本没有对应上,原来的数据还是能正常显示的。当然,最好的情况当然是在开发阶段就合理地设计好。不然,像这种情况,只能牺牲一些程序可读性来换取程序兼容性了。这会让后面看代码的人觉得很奇怪,你这个sn不也是数据设备信息吗,怎么还单独给一个ID。后面接手这个代码的人可能就会把这一块代码给改了。

image.png

温馨提示:在没有完全弄懂维护项目的代码为什么这么实现的情况下,能正常在跑的程序还是别乱动得好,哪怕你觉得这是屎山代码。否则可能会出大问题。要么等到软件重构时再修改,要么就继续打补丁。

3、数据删除

如果是删除本模块内部自己使用的数据,你想怎么删就怎么删。

如果是删除与其它模块进行交互的数据,这就不能这么随意了。比如,请求、应答的方式。应答端给请求端返回的数据是不能随意删的,如果要删,一定要确保请求端已经没有请求数据的需求,并且已经去掉相关代码时,这时候应答端才去删数据,否则还是留着吧。

4、数据修改

其实数据定了,为了保证软件兼容性,应该是要禁止修改的。

如果一定要修改,可以先增加一条新数据,后面慢慢切为新数据、删除旧数据。

接口兼容性

正在使用的接口,应该尽量不要修改。如果要修改,一定不要影响之前的功能。

之前就有遇到类似的情况。举个例子:

typedef enum _sys_status
{
 SYS_STATUS_IDLE,
 SYS_STATUS_RUNNING,
 SYS_STATUS_STOP,
}sys_status_t;

static sys_status_t g_sys_status;

sys_status_t get_sys_status(void)
{
 return g_sys_status;
}

这里的系统状态是要显示在手机APP上的,不同的状态显示不同的图标。后面要新增一个状态,结果数据提供者这么改:

typedef enum _sys_status
{
 SYS_STATUS_IDLE,
 SYS_STATUS_NEW_STATUS,
 SYS_STATUS_RUNNING,
 SYS_STATUS_STOP,
}sys_status_t;

static sys_status_t g_sys_status;

sys_status_t get_sys_status(void)
{
 return g_sys_status;
}

接口提供者把新增的数据插入了中间,影响了枚举原有的顺序。结果手机APP上图标显示乱了。

影响到接口的修改,要保证原有的数据不受影响。

系统兼容性

在软件升级过程中,需要考虑软件所依赖的其他系统组件是否发生变化,以确保升级后软件能够正常运行,不会影响其他系统组件的正常运行。如果其他系统组件发生变化,则需要进行相关测试和文档更新,以确保整个系统能够正常运行。

另外随着项目的迭代,这一套代码有可能运行于不同的系统不同的芯片平台。

比如,我们嵌入式Linux项目,有些项目里会用到一些第三方库,这时候可能会编译成动态库的形式。要考虑升级的时候能不能升级动态库。如果不能,就得把依赖的库一起编译到可执行程序里。

另外,如果使用动态库,之后产品软硬件迭代换了一个芯片平台的话,我们就需要重新交叉编译一次所依赖的库。如果为了保证这一块的兼容性,也可以考虑把所依赖的库与用户代码一起编译。

当然,这个根据实际情况进行权衡取舍。如果依赖的库很多,一起编译到可执行程序里,导致可执行程序很大,到时候更新也不好更新。

功能兼容性

涉及到功能的添加的,尽量不要影响到之前已开发的功能。不然也会增加用户对产品的学习成本。比如某些指示灯在前一个版本的快闪、慢闪代表什么意思,这个在之后就尽量不要去修改了,不然用户又得重新理解。

性能兼容性

在软件升级过程中,需要考虑软件的性能是否发生变化,以确保升级后软件的性能仍然能够满足用户需求。如果软件的性能发生变化,则需要进行相关测试和优化,以确保软件能够正常运行,并且能够满足用户的性能需求。

比如,原来正常升级需要3分钟,某个版本之后升级变成了6分钟,升级效率变差了。

安全兼容性

在软件升级过程中,需要考虑软件的安全性是否得到加强,以确保升级后软件的安全性能够得到保障,不会出现新的安全风险。如果软件的安全性得到加强,则需要进行相关测试和文档更新,以确保软件能够正常运行,并且能够保障用户的安全。





关键词: 嵌入式     软件     兼容性    

工程师
2023-08-26 11:13:15     打赏
2楼

很棒


共2条 1/1 1 跳转至

回复

匿名不能发帖!请先 [ 登陆 注册 ]