振南技术干货集：深入浅出的Bootloader（4）

注解目录

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