1. 远程升级基本信息

1. 使用NB_BC26模组，通过AT指令使用TCP的协议与公司后台交互
2. 升级的固件为BIN文件，使用原始固件包升级，未使用差分方式
3. 原始固件包有110K,大小左右，
4. 固件的存储为外置的FLASH W25Q16,
5. w25q16最小存储单位为页，一页256字节
6. W25Q16的内部结构为

W25Q16内部存储结构
总容量：2M
分为32个块，
每个块大小 64KB， 每个块分为16个扇区， 
每个扇区的大小 4KB， 每个扇区分为16个页，
每个页的大小256Byte

7. 因为固件存储器最小单位为1页，256字节
8. 所以下发的每包固件长度为 256字节的倍数为宜
9. 256字节或512字节
10. 查看NB模组BC26, 可以看到数据上下行最大长度
11. 字符串为1024字节
12. 16进制为512字节
    
13. 所以当下载固件包的长度为256字节时，模组可以下发下来，当下载固件包为512字节时，加上固件包的头尾固定字段（12个字节左右），此时模组吐出来的数据会自动截为两包
14. 此种情况有两个问题 （1）不定长解析拼接问题 （2）不定长拼接存储问题
15. 接收端可以看到黏包的现象（暂按下不表）
16. 所以粗略的计算 110KB / 256Byte = 440 包

2. 安信可透传云

使用这个TCP透传的平台测试
安信可透传云

1. 下发数据为16进制的500字节

2. 可以看到我们是以HEX发送的，下发窗口显示的是1000字节，

3. 可以看到接收端显示500字节，格式为HEX

4. 当我们的下发数据改为HEX 520字节时

5. 可以看到平台下发的1040字节

6. 然后看到接收端收到数据为两包，第一包为最大长度接收，第二包为剩余的长度

7. 此时可以知道当超过下发最大长度时，模组会自动截断剩下的
8. 别急此时做一个长度测试
9. 只下发4个字节看看
10.发送4字节16进制数据
10. 接收端显示的长度也是4
11. 但是这个数据类型是字符串，带双引号的

接收端数据为： +QIURC: “recv”,0,4,“11223344”
这是使用字符串显示的
当为16进制时，下发数据对应ASCLL码

下发的原始数据是0x11 0x22 0x33 0x44类型说明：+QIURC: "recv",0,4,"11223344"把接收负载数据16进制表示0x31 0x31 0x32 0x32 0x33 0x33 0x34 0x34解析的过程：
使用第一个字节举例：
0x11
接收端对应的是 "11"
使用的是无符号8位缓存接收，
第一字节：'1'
第二字节：'1'0x11高4位 = ('1' - '0') << 4; 
0x11低4位 = ('1' - '0') & 0x0F; 
高低位数据拼接后得 0x11

• 从上面看接收的缓存区为接收数据长度的两倍

3. 平台实际下载

1. 从平台接收来看当原始数据包为256时，不同间隔会导致出现黏包的情况概率

这个是正常的情况，下发间隔为500毫秒

计算下载时间
时间 = 总包440包 * 500毫秒 = 220秒 加上丢包的时间
3分钟多

问题：TCP协议层理论数据下载计算？占个坑