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

注解目录

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

3.3 BL的分散烧录

我们知道 BL 的核心功能其实就是程序烧录。那你有没有遇到过比较复杂的情况，如图 7.31 所示。

这种情况是有可能遇到的。主 MCU+CPLD+通信协处理器+采集协处理器就是典型的复杂系统架构。这种产品在批量生产阶段,烧录程序是非常烦琐的。首先需要维护多个固件,再就是需要一个个给每一个部件进行烧写,烧写方式可能还不尽相同。所以我引人了一个机制，叫“BL的分散烧录”

首先我们将所有的固件拼装成一个大固件(依次数据拼接),并将这个大固件预先批量烧

图 7.31 一个系统(产品)中有多个部件需要烧录固件

录到外扩 ROM 中,比如 spiFlash;再将主 MCU 预先烧录好 BL;然后进行 SMT 焊接。PCBA生产出来之后,只要一上测试工装(首次上电),BL 会去外扩 ROM 中读取大固件,并从中分离出各个小固件,分别以相应的接口烧录到各个部件中去。配合工装的测试命令,直接进行自检。这样做,批量化生产是非常高效的。当然,这个 BL 开发起来也会有一定难度,最大问题可能还是各个部件烧录接口的实现(有些部件的烧录协议是比较复杂的,比如 STM32 的SWD 或者 ESP8266 的 SLIP)。

OK,上面振南就对一些 BL实例的实现和应用场景进为了介绍。还有一些实例没有介绍,比如通过 CAN 总线或 SPI进行文件传输,这个我们还是放到专门的章节去详细讲解。当然，各位读者可以在此基础上衍生出更多有特色而又实用的 BL 来。

BL 没有最好的,只有最适合自己的。通常来说,我们并不会把 BL 设计得非常复杂,原则上它应该尽量短小精炼,以便为 APP 区节省出更多的 ROM空间。毕竟不能喧宾夺主,APP才是产品的主角。

不走寻常路的BL

4.1 Bootpatcher

我来问大家一个问题:“Bootloader 在 ROM 中的位置一定是在 APP 区前面吗?很显然不是,AVR 就是最好的例子。那如果我们限定是 STM32 呢? 似乎是的。上电复位一定是从0X08000000 位置开始运行的，而且 BL一定是先于 APP 运行的。

在某些特殊的情况下,如果 APP 必须要放在 0X8000000 位置上的话,请问还有办法实现 BL 串口烧录吗? 要知道 APP 在运行的时候,是不能 IAP 自己的程序存储器的(就是自己不能擦除自己来烧录新固件),如图 7.32 所示。

APP 运行时,想要重新烧录自身,它可以直接跳转到后面的 BL 上,BL 运行起来之后开始接收固件文件,暂存校验 OK 之后,将固件写人到前面的 APP 区。然后跳转到 0X08000000。

图 7.32 BL位于 APP 之后称之为 Bootpatcher