我们有两个独立的产品、都采用了 TI 的无线模块 一个使用 C2564MODN、另一个使用 WL1837MOD。 我们注意到了 C2564MODN 版本和 WL1837MOD 版本在行为上电成功与否以及启用蓝牙所需的时间方面存在差异。 以下是每个堆叠成功加电的记录时间：
C256x：
- BluetopiaPM 守护程序重新启动: 1.152秒
-设置由 BluetopiaPM 发送和完成的开机命令: 3.414秒
-由 BluetopiaPM 发送和完成的上电配置命令: 0.419秒
-设置波特率
-设置名称
-设置设备类别
-设置编解码器
-注册验证
-注册耳机配置文件事件回叫
-注册免提配置文件事件回叫
-输入发现
-无重试的总启动时间: 4.987秒
WL18xx：
- BluetopiaPM 守护程序重新启动: 7.250秒
-设置由 BluetopiaPM 发送和完成的开机命令: 9.215秒
-由 BluetopiaPM 发送和完成的上电配置命令: 0.283秒
-无重试的总启动时间: 16.749秒
您可以看到、与 C256x 版本相比、WL18xx 守护程序启动需要~6秒、然后再~6秒即可为芯片上电。 此外、我们从未看到有必要使用 C256x 构建来实现任何重试机制(即、它似乎总是启动而没有任何问题)；因此 C256x BT-On 时间似乎始终约为5秒。 但是、我们必须解决的一个奇怪问题是确保 WL18xx 编译模块的蓝牙能够可靠启动—我们的解决方案是只要 Set Power 命令失败、我们就会重新初始化 BluetopiaPM 守护程序并重试 Set Power 命令。 在对此进行测试时、我发现 WL18xx 蓝牙始终最终会启动、但很有可能(例如~17%) BluetopiaPM 启动失败、此过程需要复位。 通常、加电命令会导致故障、因此我们可以看到16.5秒后需要重试、然后执行重试。 因此、启动的单次重试版本大约需要33秒；如果需要第二次重试、我们将需要50秒左右的时间。 据统计、在 WL18xx 上使用蓝牙大约需要16秒的时间超过80%。
有没有更好的方法可以在 Set Power-On 命令失败后重试它—就像我能告诉的那样，如果该失败发生，唯一的恢复方法是重新启动守护进程，这非常耗时。 此外、是否有办法加快 WL18xx 启动时间？
