注解目录
1、烧录方式的更新迭代
1.1 古老的烧录方式
(怀旧一下，单片机高压烧录器。)
1.2 ISP 与ICP 烧录方式
(还记得当年我们玩过的 AT89S51?)
1.3 更方便的 ISP 烧录方式
1.3.1串口 ISP
（是 STC 单片机成就了我们，还是我们成就了 STC？）
1.3.2 各种 USB ISP
1)AVR
2) C8051F
3) MSP430
(在当前 STM32 一统天下的时代，上面这些单片机你还在用吗? )
2、关于 Bootloader
2.1 Bootloader 的基本形态
(Bootloader 先行，APP 在后。)
2.2 Bootloader 的两个设计实例
1)带 Shell 命行的口 BL
2)插 SD 卡即烧录的 BL
(上面这两种 BL 在实际应用中最常见，还讲了一下 Linux 的 Uboot。)
2.3 BL实现的要点
3、花百出的 BL
3.1 BL(串口传输)的现与延伸
(告诉你一个秘密: STM32F103C8T6 的后64K ROM 也能用，不信你试。)
3.2 10 米之内隔空烧录的实现
(一部安卓手机在手，空中升级调试全有。)
3.3 BL的分散烧录
(你以为 BL 只能给自己烧序? )
4、不走寻常路的BL
4.1 Bootpatcher
(反其道而行之，APP 先行，BL 在后。)
4.2 APP 反烧 BL
(你以为只能 BL 烧录 APP? )
花百出的 BL
上面我所讲的都是 BL 最基础的一些内容,是我们实现 BL 所必须了解的。BL 真正的亮点在于多种多样的固件数据获取方式。
3.1 BL 的实现与延伸(串口传输固件)
前面我讲到过两个 BL 应用的实例，一个是串口传输固件文件,一个是 SD 卡拷贝固件文件。它们是在实际工程中经常被用到的两种 BL 形式。这里着重对前一个实例的实现细节进行讲解剖析，因为它非常具有典型意义，如图7.23 所示。
这个流程图提出了 3 个问题：
(1) 串口通信协议是如何实现的?
(2) 为什么获取到上位机传来的固件数据,不是直接写入到 APP 区，而是先暂存,还要校验?
3) 对固件数据是如何实现校验的?
串口通信协议以及文件传输实现的相关内容略显繁杂,在本书《大话文件传输》一章中会专门进行讲解。
第二个问题:经过串口传输最终由单片机接收到的固件数据是可能出现差错的,而有错误的固件冒然直接写人到 APP 区,是一定运行不起来的。所以,我们要对数据各帧进行暂存,等全部传输完成后,对其进行整体校验，以保证固件数据的绝对正确。
针对第三个问题,我们要着重探讨一下。
一个文件从发送方传输到接收方,如何确定它是否存在错误?通常的做法在文件中加人校验码,接收方对数据按照相同的校验码计算方法计算得到校验码,将之与文件中的校验码进行对比,一致则说明传输无误,如图 7.24 所示。
图 7.24 是对固件文件的补齐以及追加校验码的示意。为什么要对文件补齐?嵌人式程序经过交叉编译生成的可烧录文件,比如 BIN,多数情况下都不是 128、256,512 或 1024 的整数倍。这就会导致在传输的时候,最后一帧数据的长度不足整帧.就会产生一个数据尾巴。取整补齐是解决数据尾巴最直接的方法。这一操作是在上位机上完成的,通常是编写一个小软件来实现。这个小软件同时会将校验码追加到固件文件未尾。这个校验码可以使用校验和(CheckSum)或者 CRC,一般是 16 位或 32 位，如图 7.25 所示。
图 7.23 BL(串口传输固件)的实现流程图
又有人会问:“要把整个固件暂存下来，再作校验,那得需要额外的存储空间吧,外扩ROM(FlashROM或 EEPROM)?”是的。如果想节省成本,我们也可以不暂存,传输时直接烧号到 APP 区。这是有风险的,但是一般来说问题不大(STC 和 STM32 的口 ISP 其实也都是实时烧写,并不暂存)。因为在传输的过程中,传输协议对数据的正确性是有一定保障的,它会对每一帧数据进行校验,失败的话会有重传,连续失败可能会直接终止传输。所以说，一般只要传输能够完成,基本上数据正确性不会有问题。但是仍然建议对固件进行整体校验,在成本允许的情况下适当扩大 ROM 容量。同时,固件暂存还有一个另外的好处,在 APP 区中的固件受到损坏的时候,比如固件意外丢失或 IAP 时不小心擦除了 APP 区,此时我们还可以从暂存固件恢复回来(完备的 BL会包含固件恢复的功能)。
其实也不必非要外扩 ROM,如果固件体积比较小的话,我们可以把单片机的片上 ROM
图 7.24 对固件文件进行补齐并追加校验码
图 7.25 通过一个小软件实现对固件文件补齐和添加校验码
砍成两半来用,用后一半来作固件暂存。
如图 7.26 所示,我们将片上 ROM 划分为 3 部分,分别用于存储 BL、APP 固件以及暂存固件。比如我们使用 STM32F103RBT6,它一共有 128 KB 的 ROM,可以划分为 16 KB56 KB/56 KB。
有些产品对成本极为敏感。我就有过这样的开发经历,当时使用的单片机是STM32F103C8T6,片上 ROM 总容量为 64 KB,固件大小为 48 KB,BL 为12 KB。在通过 BL进行固件烧写时根本没有多余的 ROM 进行固件暂存。我使用了一招“狗尾续貂”,如图 7.27所示。
我无意中了解到 STM32F103C8T6 与 RBT6 的晶元是同一个。只是因为有些芯片后64 KB的 ROM性能不佳或有瑕疵,而被限制使用了。我实际测试了一下,确实如此。但是后64 KB ROM的使用是有前提的,也就是需要事先对其好坏进行验证。如果是好的,则暂存校
图 7.26将片上 ROM 划分为 3 部分
图 7.27STM32F103C8T6 后 64KB 也可用
验,再写入 APP 区;而如果是坏的,那么就直接在固件传输时实时写入 APP 区(这个办法我屡试不爽，还没有发现后 64KB 有坏的)。
以上振南所介绍的是一种“骚操作”,根本上还是有一定的风险的,ST 官方有声明过,对后 64K ROM 的质量不作保证，所以还是要慎用。
3.2 10米之内隔空烧录
这个“隔空烧录”源于我的一个 IoT 项目,它是对空调的外机进行工况监测。大家知道，空调外机的安装那可不是一般人能干的,它要不就在楼顶,要不就在悬窗上。这给硬件升级嵌人式程序带来很大的困难。所以,我实现了“隔空烧录”的功能,其实它就是串口 BL 应用的一个延伸,如图 7.28 所示。
图 7.28通过蓝牙串口模块实现“隔空烧录
“隔空烧录确实牛,但是总要抱着一个电脑,这不太方便吧。”确实是!还记得前面我提过的 AVRUBD 通信协议吗(详见“大话文件传输”章)? 它的上位机软件是有手机版的。这样我们只要有手机,就能“隔空烧录”了，如图 7.29 所示。
“哪个 APP? 快告诉我名字”,别急,蓝牙串口助手安卓版,图 7.30 是正在传输固件的界面。
AVRUBD 其实是对 Xmodem 协议的改进，这个我们放在专门的章节进行详细讲解。
手机连接蓝牙串口模块实现“手机隔空烧录”图 7.29
图 7.30蓝牙串口助手传输固件文件的界面
