痛苦史---调稳 外设+无驱动+无硬件+不稳定平板的通信

09年毕业至今，共跳槽一次。现公司就是第二家公司。第一家公司是深圳华旭昌。一家伤透了我心的公司。从公司最少的8个人到这几年，靠几十个研发，创造了连续3年的数E纯利润。连对手都上市去了。在MTK出货排位第三。

第二家是一家创业型公司。算是人森的第二次创业。希望能一切顺利。

现状：平板端无人负责。从0开搞。有一个声称能用的demo。说实话，初到新公司磨合的真累。

外设：一个跑步机的电路控制面板。

平板驱动：无人负责

平板硬件：无人负责

平板软件：我

有任何问题，外设端负责人，一句话：我一定没问题。事实上，我找到了外设端的bug。
事实上，我找到了外设端的bug。结果，我负责了驱动，硬件，软件。

平板通过BLE连接控制外设，实现跑步机的控制。有两种方式 串口以及BLE。

问题来了。串口跟BLE，加上不稳定平板，各种稀奇古怪的问题。总结，丢包，高延迟，状态不同步，甚至经常出现无法连接蓝牙。

想象一下，这问题排查难啊。我不熟悉驱动啊。平板还不稳定。连平板本身都动不动就挂彩。亚历山大啊。。。在别人眼中什么都是容易的。就知道要完成时间。呵呵呵。。。

篇章一、化解驱动硬件的原因

1. 串口连接是需要驱动硬件支持的。虽然是软件，不过硬生生靠那点经验，资料查证。事实上，我找到了外设端的bug。
找到前公司驱动同事请教。发现串口通信有个缓存栈，部分设备的读写buffer是不一样的。有公用同一个buffer，也有分开的。具体要看型号。根据型号判断。

再次联系方案商，咨询具体的型号，万幸的是型号是MAX232读写buffer分开的。

为何，多次写入指令会被覆盖？  因为处理指令需要时间，发送的太快。就会出问题。这一点的查证真心是废了不少功夫。

篇章二、理解BLE通信

BLE通信是一种低功耗的通信，关键是采用的是轮询的方式。这要命了。不是实时发来发去。而且同样存在处理时间的问题。

通过添加消息的发送处理机制避免了读写覆盖的问题。

篇章三、协议出了大问题，不稳定性太大。不同步

第一版通信协议，外设端声称没问题，我一点问题都没有。不好反驳什么。但是我发现，因为BLE和串口的关系，会丢包，延迟。甚至协议本身根本就没办法做好状态同步。

整整7个月的时间，之前的程序员居然一直都说是好的。没问题。这种程度的代码根本没办法是用。更大的问题是什么。程序根本就是不能用。状态不同步的代码。

这个问题从来没被人发现。我也是傻了眼。。。。

提出第二版修改方案，将所有状态都通过 指令传输。明明可以支持。为何不做。提高实时通信效果以及稳定性。

篇章四、平板极不稳定以及外设端的mac地址干扰

曾有一段时间，经常出现平板无法连接外设。为什么？因为mac地址是一样的。别人连掉了我根本不知道，预置条件就是mac地址不一样吧。

平板极不稳定。CPU，电量都对连接产生了很多影响。当时的情况是，我刚调好连接部分的代码然后，就发生问题了。排查了所有的原因：外设，ble，代码。百思不得解。

最后，目光投向平板本身，为何还是不行。发现电量太低的情况下，系统本身的therme会将部分功能关闭。其中包括Bluetooth。呵呵呵。能打开却不能用。

同样点亮问题，我曾奋战到3点半弄明白的问题。

一切如旧，谁都说不是我的问题，boss就应说是软件不行。呵呵呵呵。连驱动跟硬件都没查到原因。唉。。。也是悲催啊。最终发现是电量。还只能是40-60%的电量。满电都不行。

篇章五、硬件配件有问题加重了现象的分析难度

因为外设都是手工焊接。呵呵呵呵呵。零配件的质量真是堪忧。。。会发生无效点击，一次点击数次触发的现象。。。。。。呵呵呵呵呵呵

篇章六、自己的程序不够完善

发现自己在不该sleep的地方用了sleep。导致程序吞吐量降低。配合压力测试。玩完了。。。。

还有一些小bug，一些逻辑上的错误。遗漏。。。。。no zuo no die.

写点工作总结-----------------跑步机BLE延迟原因-----为什么有时候会慢

原因

一. 受限于BLE协议的特殊性。测试机单纯提交指令到指令返回这需要耗费的时间在大多时候是100ms---200ms内，小概率200ms---300ms之间。我方机器在提交一个指定到收到反馈，需要100-450ms。
    这包含BLE协议跟底层处理器的处理时间。另外也需要考虑发送间隔不能过快。过快就会有指令被冲刷的风险。
二. 按键存在 单击 连续发送多个单击指令 的现象
三. 有时候手按了，但没产生点击，产生错觉！！！

现象解释

一. 现在存在连续跳过两个值的现象。
有两个原因：
1. BLE通信时快时慢，在压力测试的情况下，容易出现两条指令一起收到的情况，这样的话，基本上UI就是一起被设上去的。肉眼感觉就是变化了一次，甚至觉得是卡顿的一次。
2. 在压力测试的情况下，就会出现指令处理来不及，到时候，我速度是1 2 3 4 5 6 这样的指令提交，收到的时候，可能收到了1 3 3 4 6 6，这样的情况。
   收到指令的数量不变，但是之前应该有的指令被冲刷掉了。

双方机器对比

预置条件：经过压力测试，使用测试机，我方机器
一、 指令收到后处理时间.
测试机：10-30ms结束处理。主要集中在20ms不到一点
我方机器：30-400ms.


二.、指令发送到收到反馈时间
测试机：100-200ms，小概率200-300ms之间
我方机器：需要100-450ms。大部分集中在150-300之间.


三、展望
时间长度跟android打包方式，记得log的数量也有关。现在是用ms作为单位。那么，我预计在正式版本，时间缩短到在10-15ms之间还是有希望的.

事2.实上，我找到了外设端的bug。