本案例中，智能手表作为中央设备对心率带通过BLE进行升级，这里手表首先要通过某种方式获得心率带的固件，然后通过BLE对心率带进行连接，连接后两者建立协议进行固件的发送及接收，最后心率带接收完固件后对自身进行加载。
为了蓝牙升级时简化协议逻辑，我们建立两个数据通道，一个是命令通道，专门用来发命令；一个是数据传输通道，专门用来发送固件数据，在实现中其实就是在心率带设备里面创建两个GATT service，然后手表分别对这两个服务进行连接，通过连接句柄来收发数据，一个发送命令相关的数据，一个只发送固件数据。
针对升级协议，我们已经制定好了两个数据通道：命令通道和数据通道。之前提到了数据通道只用来发送固件内容，那么命令通道呢？我们可以将命令通道用来干这些事情：
enum
{
OTA_READY = 0,
OTA_FLASH,
}CMD_E;
//命令结构
struct
{
uint8_t cmd;
uint8_t packet_num;
uint8_t data[1];//可变长数组，这里代表任意数量数据
uint8_t checksum;
}cmd_t;
//OTA完成命令格式
struct
{
uint8_t cmd;
uint8_t packet_num;
uint32_t filesize;
uint16_t crc;
uint8_t checksum;
}cmd_finish_t;
准备命令是想获取心率带需要升级哪些文件或资源，如果都不要升级的话说明心率带的资源或固件都已经是最新的了。整个固件下载完成后，要对这个文件进行校验，校验值和主机传输过来的相等的话需要回应升级成功相应字段，反之升级失败，由 cmd_finish_t 实现。
固件数据是4K为一个校验单位发送的，每个4K需要分包发送，分包发送的每个包的大小可以自定义，一般不会太大。这部分在协议流程图里没有表现出来，具体算法请看下一节。
struct
{
uint8_t file_type;
uint32_t offset;
uint16_t packet_len;
uint32_t total_len;
uint16_t crc;
uint8_t checksum;
}section_start_t;
struct
{
uint8_t crc_equal;//是否需要发送当前4K数据
uint8_t is_fast_mode;
uint8_t mtu;
uint8_t packnum;//几包数据一个应答
}section_start_rsp_t;
整个OTA方案可以分为三部分：
如果想进一步了解实现细节的话可以私聊或者添加文章下方公众号获取。
每4K作为一个校验单位的传输方式可以起到断点续传的效果，相当于每开始传输一个4K之前，判断FLASH里面的数据是不是已经写过的，如果写过的话，则跳过该4K。