一、 前言
在运动手表中,需要连接第三方配件作为配件的显示控制终端,主要起到控制或者获取配件数据的作用。比如控制相机,获取心率带数据,获取跑步动态数据。
随着项目的业务需求越来越丰富,对配件的连接要求和应用场景也越来越多,比如需要考虑同类配件的多连接,同类配件的版本信息获取和电量获取。
以下将介绍配件管理优化致力于解决什么问题。
二、 现状
-
手表可同时连接多个配件,但是不能同时连接多个同类配件:比如可以同时连接心率带、跑步动态计、相机;但是不能同时连接两个心率带,或者同时连接两个跑步动态计。
-
不能够获取电量、版本信息。
-
一个配件设备,里面可能包含多个服务,比如STRYD,里面包含功率计服务、跑步速度踏频服务、STRYD私有服务、电量服务。在这种情况下,会存在一个奇怪的现象,已经给每个配件指定一个设备类型了,但是这个设备里面有多个服务数据。
-
服务发现流程在蓝牙模块端,handle 的index及value目前都在蓝牙模块中管理。在这种情况下,MCU端如果要操作相关handle,需要写类HCI接口,比较繁琐和耗时。当handle比较多的时候,比如需要实现同类配件的多连接时,不仅联系到handle的存储和查找,也要关注连接句柄,此时如果不把这个管理直接交给MCU管理,是比较难实现的,后者比较麻烦易出错。
三、优化方向
- 希望能连接多个同类配件,弱化配件类型,强化服务。通过链表来管理已发现服务。
- 不管连接了多少个配件,不care,只需要保存好设备里面的服务相关信息,后续只针对服务操作,服务里面要增加设备地址,好区分同类设备的多连接。
- 将服务发现的流程交给MCU控制,属性handle和connId也交给MCU管理,增加通信效率。