1、程序的书写结构 虽然书写格式并不会影响生成的代码质量，但是在实际编写程序时还是应该遵循一定的书写规则，一个书写清晰、明了的程序，有利于以后的维护。 在书写程序时，特别是对于While、for、do…while、if…else、switch…case 等语句或这些语句嵌套组合时，应采用“缩格”的书写形式。 2、标识符 程序中使用的用户标识符除要遵循标识符的命名规则以外，一般不要用代数符号(如a、b、x1、y1)作为变量名，应选取具有相关含义的英文单词(或缩写)或汉语拼音作为标识符，以增加程序的可读性，如：count、number1、red、work 等。 3、程序结构 C 语言是一种高级程序设计语言，提供了十分完备的规范化流程控制结构。因此在采用C 语言设计单片机应用系统程序时，首先要注意尽可能采用结构化的程序设计方法，这样可使整个应用系统程序结构清晰，便于调试和维护。 对于一个较大的应用程序，通常将整个程序按功能分成若干个模块，不同模块完成不同的功能。 各个模块可以分别编写，甚至还可以由不同的程序员编写，一般单个模块完成的功能较为简单，设计和调试也相对容易一些。在C 语言中，一个函数就可以认为是一个模块。 所谓程序模块化，不仅是要将整个程序划分成若干个功能模块，更重要的是，还应该注意保持各个模块之间变量的相对独立性，即保持模块的独立性，尽量少使用全局变量等。对于一些常用的功能模块，还可以封装为一个应用程序库，以便需要时可以直接调用。 但是在使用模块化时，如果将模块分成太细太小，又会导致程序的执行效率变低(进入和退出一个函数时保护和恢复寄存器占用了一些时间)。 4、定义常数 在程序化设计过程中，对于经常使用的一些常数，如果将它直接写到程序中去，一旦常数的数值发生变化，就必须逐个找出程序中所有的常数，并逐一进行修改，这样必然会降低程序的可维护性。因此，应尽量当采用预处理命令方式来定义常数，而且还可以避免输入错误。 5、减少判断语句 能够使用条件编译(ifdef)的地方就使用条件编译而不使用if 语句，有利于减少编译生成的代码的长度。 6、表达式 对于一个表达式中各种运算执行的优先顺序不太明确或容易混淆的地方，应当采用圆括号明确指定它们的优先顺序。一个表达式通常不能写得太复杂，如果表达式太复杂，时间久了以后，自己也不容易看得懂，不利于以后的维护。 7、函数 对于程序中的函数，在使用之前，应对函数的类型进行说明，对函数类型的说明必须保证它与原来定义的函数类型一致，对于没有参数和没有返回值类型的函数应加上“void”说明。如果需要缩短代码的长度，可以将程序中一些公共的程序段定义为函数。 如果需要缩短程序的执行时间，在程序调试结束后，将部分函数用宏定义来代替。注意，应该在程序调试结束后再定义宏，因为大多数编译系统在宏展开之后才会报错，这样会增加排错的难度。 8、尽量少用全局变量，多用局部变量 因为全局变量是放在数据存储器中，定义一个全局变量，MCU 就少一个可以利用的数据存储器空间，如果定义了太多的全局变量，会导致编译器无足够的内存可以分配；而局部变量大多定位于MCU 内部的寄存器中，在绝大多数MCU 中，使用寄存器操作速度比数据存储器快，指令也更多更灵活，有利于生成质量更高的代码，而且局部变量所能占用的寄存器和数据存储器在不同的模块中可以重复利用。 9、设定合适的编译程序选项 许多编译程序有几种不同的优化选项，在使用前应理解各优化选项的含义，然后选用最合适的一种优化方式。通常情况下一旦选用最高级优化，编译程序会近乎病态地追求代码优化，可能会影响程序的正确性，导致程序运行出错。 因此应熟悉所使用的编译器，应知道哪些参数在优化时会受到影响，哪些参数不会受到影响。 代码的优化 1、选择合适的算法和数据结构 应熟悉算法语言。将比较慢的顺序查找法用较快的二分查找法或乱序查找法代替，插入排序或冒泡排序法用快速排序、合并排序或根排序代替，这样可以大大提高程序执行的效率。 选择一种合适的数据结构也很重要，比如在一堆随机存放的数据中使用了大量的插入和删除指令，比使用链表要快得多。数组与指针具有十分密切的关系，一般来说指针比较灵活简洁，而数组则比较直观，容易理解。对于大部分的编译器，使用指针比使用数组生成的代码更短，执行效率更高。 但是在Keil 中则相反，使用数组比使用的指针生成的代码更短。 2、使用尽量小的数据类型 能够使用字符型(char)定义的变量，就不要使用整型(int)变量来定义；能够使用整型变量定义的变量就不要用长整型(long int)，能不使用浮点型(float)变量就不要使用浮点型变量。 当然，在定义变量后不要超过变量的作用范围，如果超过变量的范围赋值，C 编译器并不报错，但程序运行结果却错了，而且这样的错误很难发现。 3、使用自加、自减指令 通常使用自加、自减指令和复合赋值表达式(如a-=1 及a+=1 等)都能够生成高质量的程序代码，编译器通常都能够生成inc 和dec 之类的指令，而使用a=a+1 或a=a-1之类的指令，有很多C 编译器都会生成2~3个字节的指令。 4、减少运算的强度 可以使用运算量小但功能相同的表达式替换原来复杂的的表达式。如下： (1)求余运算 a=a%8; 可以改为： a=a&7; 说明：位操作只需一个指令周期即可完成，而大部分的C 编译器的“%”运算均是调用子程序来完成，代码长、执行速度慢。通常，只要求是求2n 方的余数，均可使用位操作的方法来代替。 (2)平方运算 a=pow(a,2.0); 可以改为： a=a*a; 说明：在有内置硬件乘法器的单片机中(如51 系列)，乘法运算比求平方运算快得多，因为浮点数的求平方是通过调用子程序来实现的，在自带硬件乘法器的AVR 单片机中，如ATMega163 中，乘法运算只需2 个时钟周期就可以完成。 即使是在没有内置硬件乘法器的AVR单片机中，乘法运算的子程序比平方运算的子程序代码短，执行速度快。如果是求3 次方，如： a=pow(a,3.0); 更改为： a=a*a*a； 则效率的改善更明显。 (3)用移位实现乘除法运算 a=a*4; b=b/4; 可以改为： a=a<<2; b=b>>2; 说明：通常如果需要乘以或除以2n，都可以用移位的方法代替。在ICCAVR 中，如果乘以2n，都可以生成左移的代码，而乘以其它的整数或除以任何数，均调用乘除法子程序。 用移位的方法得到代码比调用乘除法子程序生成的代码效率高。实际上，只要是乘以或除以一个整数，均可以用移位的方法得到结果，如： a=a*9 可以改为： a=(a<<3)+a 5、循环 (1)循环语对于一些不需要循环变量参加运算的任务可以把它们放到循环外面，这里的任务包括表达式、函数的调用、指针运算、数组访问等，应该将没有必要执行多次的操作全部集合在一起，放到一个init 的初始化程序中进行。 (2)延时函数 通常使用的延时函数均采用自加的形式： void delay (void){unsigned int i;for (i=0;i<1000;i++); }将其改为自减延时函数：void delay (void){unsigned int i;for (i=1000;i>0;i--); } 两个函数的延时效果相似，但几乎所有的C 编译对后一种函数生成的代码均比前一种代码少1~3 个字节，因为几乎所有的MCU 均有为0转移的指令，采用后一种方式能够生成这类指令。在使用while 循环时也一样，使用自减指令控制循环会比使用自加指令控制循环生成的代码更少1~3 个字母。 但是在循环中有通过循环变量“i”读写数组的指令时，使用预减循环时有可能使数组超界，要引起注意。 (3)while 循环和do…while 循环 用while 循环时有以下两种循环形式： unsigned int i;i=0;while (i<1000){i++; //用户程序}或：unsigned int i;i=1000;do{i--; //用户程序}while (i>0); 在这两种循环中，使用do…while循环编译后生成的代码的长度短于while循环。 6、查表 在程序中一般不进行非常复杂的运算，如浮点数的乘除及开方等，以及一些复杂的数学模型的插补运算，对这些即消耗时间又消费资源的运算，应尽量使用查表的方式，并且将数据表置于程序存储区。 如果直接生成所需的表比较困难，也尽量在启动时先计算，然后在数据存储器中生成所需的表，后面在程序运行直接查表就可以了，减少了程序执行过程中重复计算的工作量。 7、其它 比如使用在线汇编及将字符串和一些常量保存在程序存储器中，均有利于优化。 乘除法优化 目前单片机的市场竞争很激烈，许多应用出于性价比的考虑，选择使用程序存储空间较小（如1K，2K）的小资源8位MCU芯片进行开发。一般情况下，这类MCU没有硬件乘法、除法指令，在程序必须使用乘除法运算时，如果单纯依靠编译器调用内部函数库来实现，常常会有代码量偏大、执行效率偏低的缺点。 上海晟矽微电子推出的MC30、MC32系列MCU，采用了RISC架构，在小资源8位MCU领域有广大的用户群和广泛的应用，本文就以晟矽微电的这两个系列产品的指令集为例，结合汇编与C编译平台，给大家介绍一种既省时又节约资源的乘除法算法。 1、乘法篇 单片机中的乘法是二进制的乘法，也就是把乘数的各个位与被乘数相乘，然后再相加得出，因为乘数和被乘数都是二进制，所以实际编程时每一步的乘法可以用移位实现。 例如：乘数R3=01101101，被乘数R4=11000101，乘积R1R0。步骤如下： 1、清空乘积R1R0； 2、乘数的第0位是1，那被乘数R4需要乘上二进制数1，也就是左移0位，加到R1R0里; 3、乘数的第1位是0，忽略； 4、乘数的第2位是1，那被乘数R4需要乘上二进制数100，也就是左移2位，加到R1R0里； 5、乘数的第3位是1，那被乘数R4需要乘上二进制数1000，也就是左移3位，加到R1R0里； 6、乘数的第4位是0，忽略； 7、乘数的第5位是1，那被乘数R4需要乘上二进制数100000，也就是左移5位，加到R1R0里； 8、乘数的第6位是1，那被乘数R4需要乘上二进制数1000000，也就是左移6位，加到R1R0里； 9、乘数的第7位是0，忽略； 10、这时候R1R0里的值就是最后的乘积，至此算法完成。 以上例子运算结果： R1R0 = R3 * R4= (R4<<6)+(R4<<5)+(R4<<3)+(R4<<2)+R4 = 101001111100001 实际运算流程图见下图： 在实际的程序设计过程中，程序优化有两个目标，提高程序运行效率，和减少代码量。我们来看下本文提供的汇编算法和普通C语言编程的效率和代码量对比。 表1.1是程序运行效率的对比数据（可能会有小的偏差），很明显汇编编译出来的运行时间要比C语言减少很多。 汇编（时钟周期） C语言（时钟周期） 8*8位乘法 79-87 184-190 16*8位乘法 201-210 362-388 16*16位乘法 234-379 396-468 表1.1 乘法运算时钟周期对比表 表1.2是程序代码量的对比数据（可能会有小的偏差），汇编占用的程序空间也要比C语言小很多。 汇编（Byte） C语言（Byte） 8*8位乘法 15 34 16*8位乘法 19 96 16*16位乘法 31 96 表1.2 乘法运算ROM空间使用情况对比表 综上两点，本文介绍的乘法算法各方面使用情况都要比C编译好很多。如果大家在使用过程中，原有的程序不能满足应用需求，例如遇到程序空间不够或者运行时间太久等问题，都可以按照以上方式进行优化。 汇编语言最接近机器语言的。在汇编语言中可以直接操作寄存器，调整指令执行顺序。由于汇编语言直接面对硬件平台，而不同的硬件平台的指令集及指令周期均有较大差异，这样会对程序的移植和维护造成一定的不便，所以我们针对精简指令集做了乘法运算的例程，便于大家的移植和理解。 2、除法篇 单片机中的除法也是二进制的除法，和现实中数学的除法类似，是从被除数的高位开始，按位对除数进行相除取余的运算，得出的余数再和之后的被除数一起再进行新的相除取余的运算，直到除不尽为止，因为单片机中的除法是二进制的，每个步骤除出来的商最大只有1，所以我们实际编程时可以把每一步的除法看作减法运算。 例如：被除数R3R4=1100110001101101，除数R5=11000101，商R1R0，余数R2。步骤如下： 1、清空商R1R0，余数R2；2、被除数放开最高位，第15位，为1，1比除数小，商为0，余数R2为1；3、上一步余数并上被除数次高位，第14位，得11，11仍然比除数小，商为0，余数R2为114、直到放开第8位后，得11001100，比除数大，商得1，余数R2为111；5、上一步余数并上被除数第7位，得1110，没有除数大，商为0，余数R2为1110；6、上一步余数并上被除数第6位，得11101，没有除数大，商为0，余数R2为11101；7、按照以上步骤，直到放开了被除数得第3位，得11101101，比除数大，商为1，余数R2为101000；8、上一步余数并上被除数第2位，得1010001，没有除数大，商为0，余数R2为1010001；9、上一步余数并上被除数第1位，得10100010，没有除数大，商为0，余数R2为10100010；10、上一步余数并上被除数第0位，得101000101，比除数大，商为1，余数R2为10000000；11、然后把以上所有步骤中得商从左至右依次排列就是最后的商100001001，余数为最后算得的余数10000000。 以上例子运算结果：R1R0 = R3R4 / R5 = 100001001 ；R2 = R3R4 % R5 = 10000000 实际运算流程图见下图： 除法运算的效率，代码量见以下表格 表2.1是程序运行效率和代码量的对比数据（可能会有小的偏差），很明显本文提供的汇编算法要优化的很多。 16/8位除法 汇编 C语言 时钟周期 287-321 740-804 使用空间（Byte） 35 142 表2.1 除法运算时钟周期对比表 所以对于除法运算，本文提供的方法也是相对较优的。 以下是针对精简指令集做的除法运算，16/8位的例程，便于大家的移植和理解。
Bootloader是一个用于引导嵌入式系统的软件程序，通常存储在芯片的非易失性存储器中，如闪存。Bootloader的主要功能是在系统上电后，负责初始化系统硬件并加载操作系统或应用程序到内存中执行。 下面是一个简要的介绍Bootloader的工作流程和主要功能： 硬件初始化：Bootloader首先负责初始化处理器、时钟、内存和外设等硬件资源，确保系统处于合适的状态以便后续的操作。 引导设备选择：Bootloader可能需要检测可用的引导设备，例如闪存、外部存储器或串口等，并选择其中一个作为加载操作系统或应用程序的来源。 加载操作系统或应用程序：Bootloader根据预定义的引导策略，从选定的引导设备中读取操作系统镜像或应用程序，并将其加载到内存中。 执行加载的程序：一旦程序加载到内存中，Bootloader会跳转到该程序的入口点，启动执行。对于操作系统，这意味着将控制权移交给操作系统内核，而对于应用程序，它将开始执行应用程序的主函数。 错误处理和回滚：Bootloader通常包含错误处理机制，以便在发生错误时执行相应的操作，例如跳转到备用引导设备或者恢复到出厂设置状态。 升级支持：一些Bootloader还提供了固件升级的支持，允许通过特定的接口或协议更新系统固件，而无需物理访问设备。 总的来说，Bootloader在嵌入式系统中扮演着关键的角色，负责启动和管理系统的引导过程，同时提供了灵活性和可靠性，以适应不同的应用需求。 当我面对一个有一定规模、 稍显复杂的嵌入式项目时, 我通常并不会直接专注于主要功能的实现, 而是会做一些磨刀不误砍柴工的工作———设计一个 Bootloader(以下简称 BL) 以及构建一个Shell 框架。可能有人会觉得它们很高深, 实则不难, 正所谓“会者不难, 难者不会”。 本章就针对 BL 进行详细的讲解, 希望让大家可以体会到它的重要性。 1. 烧录方式的更新迭代 1.1 古老的烧录方式 单片机诞生于20 世纪80 年代, 以51 为代表开始广泛应用于工业控制、 家电等很多行业中。起初对于单片机的烧录, 也就是将可执行的程序写入到其内部的 ROM 中, 这不是一件容易的事情, 而且成本不低, 因为需要依赖于专门的烧录设备。而且受到半导体技术与工艺的限制, 对于 ROM 的烧写大多需要高压。这种境况一直持续到2000 年左右( 我上大学的时候还曾用过这种专门的烧录器),： 1.2 ISP 与ICP 烧录方式 随着低压电可擦写 ROM 的成熟, 单片机开始集成可通过数字电平直接读写的存储介质。其最大的优势在于可实现在系统或在电路直接烧录程序, 而无须像以前一样把单片机芯片从电路中拿出来, 放到编程器上, 这种烧录方式就是ISP(In System Programming) 或ICP (In Circuit Programming), 如图7.2 所示。 有人问过这样一个问题:“ISP 和ICP 我都听说过, 都说是可以在电路板上直接烧录程序,而无须拿下芯片, 那ISP 和ICP 有什么区别?”从广义上来说, 两者没有区别, 平时我们把其意义混淆也毫无问题。非要刨根问底的话, 那可以这样来理解:ISP 要求单片机中驻留有专门的程序, 用以与上位机进行通信, 接收固件数据并烧录到自身的 ROM 中, 很显然ISP 的单片机是需要可运行的, 即要具备基本的最小系统电路(时钟和复位); 而ICP 可以理解为 MCU 就是一块可供外部读写的存储电路, 它不需要预置任何程序, 也不需要单片机芯片处于可运行的状态。 支持ISP 或ICP 的芯片, 以 AT89S51 最为经典, 当时从 AT89C51 换成 S51 , 多少人曾因此不再依赖烧录器而大呼爽哉。这种并口下载线非常流行, 如图7.3 所示, 网上还有各种ISP小软件, 可以说它降低了很多人入门单片机的门槛, 让单片机变得喜闻乐见。一台电脑、一个S51 最小系统板、 一条并口ISP 下载线, 齐了! 1.3 更方便的ISP 烧录方式 1. 串口ISP 但是后来我们发现带有并口的电脑越来越少。那是在2005 年前后,STC 单片机开始大量出现, 在功能上其实与S51 相差无几, 甚至比同期的一些高端51 单片机还要逊色。但是它凭借一个优势让人们对它爱不释手, 进一步降低了单片机的学习门槛。这个优势就是———串口ISP, 这是真正意义上的ISP, 如图7.4 和图7.5 所示。再后来,9 针串口都很少见了, 只有 USB。这促使一个烧录和调试神器炙手可热———USB-TTL 串口。这下232 转换芯片省掉了, 直接通过 USB 进行烧录。这种方式造福了无数的单片机学习者和工程师。我本人虽然已经搞了近20 年单片机和嵌入式, USB 串口依然是不可或缺的调试工具。 多年来, 在串口与单片机的交互上, 我动了很多脑筋, 这也是我乐于开发 Bootloader 的一个原因。我希望“USB 串口在手, 一切全有!” STC 并不是第一个使用串口ISP 烧录程序的, 但它是最成功和最深入人心的。与之同期的很多单片机, 包括时至今日仍然应用最广泛的 STM32 全系列也都支持了串口ISP, 它成了一种标配的、 非常普遍的程序烧录手段。 2. 各种 USBISP 串口ISP 固然方便, 但是下载速度是它的硬伤, 当固件体积比较大的时候, 比如一些大型嵌入式项目的固件动辄几百 KB, 甚至几 MB, 再用串口ISP 就未免太慢了。所以一些单片机配有专门的 USBISP 下载器。以下列举几种比较主流的单片机及其 USBISP 下载器。 (1) AVR AVR 单片机曾经盛极一时, 但经历了2016 年的缺芯风波之后, 加之 STM32 的冲击, 开始变得一蹶不振, 鲜有人用了。与之配套的 USBISP 下载器非常多样, 有些是官方发布的, 更多的是爱好者开源项目的成果, 如图7.6 所示。 (2) C8051F( 见图7.7) (3) MSP430( 见图7.8) 我们会发现, 一个具有良好生态的主流单片机, 一定有配套的高效便捷的烧录下载工具。可见一种好的烧录方式, 对单片机开发是多么重要。 不论是串口ISP 还是各种专用的ISP 下载器, 都有一些共同的弊端。 依赖于专门的上位机或下载器硬件, 不能做到统型; 下载器价格仍然比较高, 尤其是原厂的, 这也是为什么有些单片机催生出很多第三方的下载器, 比如 AVR; 下载的时候通常需要附加额外的操作, 比如 STC 要重新上电、STM32 需要设置BOOT 引脚电平等。 这些额外的操作都增加了烧录的复杂性。尤其是在产品形态下要去重新烧录程序, 比如嵌入式升级, 就要打开外壳, 或将附加信号引出到壳外。 这都是非常不高效, 不友好的做法。如果有一种烧录方法, 对于任何一种单片机: 通信方式统一(比如一律都用串口); 提供一个友好的操作界面(比如命令行方式); 高效快速, 没有附加操作, 最好一键自动化烧录; 另外再增加一些嵌入式固件管理的功能(比如固件版本管理)。 这一定会让我们事半功倍。Bootloader 就能实现上述的这一切! 2. 关于Bootloader 2.1 Bootloader 的基本形态 直接看图7.9: 可以看到 BL 就是一段存储在 ROM 中的程序, 它主要实现4 个功能: 通过某种途径获取要烧录的固件数据; 将固件数据写入到 ROM 的 APP 区中; 跳转到 APP 区运行, 将烧录进去的用户程序引导起来; 在此过程中, 提供必要而友好的人机交互界面。这么说可能不好理解, 我们还是通过实例来进行讲解。 2.2 Bootloader 的两个设计实例 下面的两个实例, 用于说明 BL 的实际应用形态, 不涉及具体的实现细节, 旨在让大家了解 BL 实际是如何运行的。 1. 带Shell 命令行的串口BL 基本的操作逻辑如下: 通过超级终端、SecureCRT 或 Xshell 之类的串口终端输入命令program; BL 接收到命令后, 开始等待接收固件文件数据; 串口终端通过某种文件数据传输协议将固件数据传给 BL; BL 将固件数据写入到 ROM 的 APP 区中; BL 将 APP 区中的程序引导运行起来。更具体的示意如图7.10 所示。这里把操作逻辑说得很简单, 实际实现起来却并不容易, 我们放在后面去细究其具体实现。 2. 插SD 卡即烧录的BL 基本的操作逻辑如下: 将待烧录的固件拷贝到SD 卡中; 将SD 卡插入到卡槽中; BL 检测到SD 卡插入, 搜索卡中 BIN 文件; 将 BIN 文件数据读出写入到 ROM 的 APP 区中; BL 将 APP 区中的程序引导运行起来。 如图7.11 所示。通过这两个设计实例, 大家应该已经了解BL 是什么了吧。有没有感受到BL 是比ISP 烧录器更通用、 更灵活、 更友好、 功能更强大的固件烧录和管理手段呢? 有人可能知道 Linux 下的 Uboot, 它就是一个强大的 BL, 它提供非常强大的刷机(烧录操作系统镜像) 的功能以及完备而灵活的Shell 界面, 如图7.12 所示。其实我们电脑的 BIOS 也是一种广义的 BL。 那如何实现一个 BL 呢? 别急, 要实现 BL 是需要满足一些基本要求的。 2.3 BL 实现的要点 首先要说, 并不是任何一个单片机都可以实现 BL 的, 要满足几个要点。 1. 芯片体系架构要支持 来看图7.13 。 我们知道单片机程序的最开头是中断向量表, 包含了程序栈顶地址以及 Reset 程序入口,通过它才能把程序运行起来。很显然在从 BL 向 APP 跳转的时候,APP 程序必须有自己的中断向量表。而且单片机体系架构上要允许中断向量表的重定向。 传统51 单片机的中断向量表只允许放到 ROM 开头, 而不能有偏移量, 所以传统51单片机是不能支持 BL 的。有人要问“你这不是自相矛盾吗? 你前面说 STC 的51 单片机是支持串口ISP 的, 那它应该内置有ISP 程序, 我理解它应该和BL 是一个道理。”没错, 它内置的ISP程序就是一种 BL。STC 之所以可以实现 BL 功能, 是因为宏晶半导体公司对它的硬件架构进行了改进, 请看图7.14 可以看到,STC51 单片机多出了一块专门存放 BL 的 ROM, 称为 BOOTROM。 网上有一位叫 shaoziyang 的网友为 AVR 单片机写了一个 BL, 还配套开发了 一 款 叫AVRUBD 的上位机, 如图7.15 (AVRUBD 是很有用的, 本章后面会介绍, 它可以让我们实现隔空烧录) 所示, 实现了 AVR 单片机的串口烧录, 让很多人摆脱了对 USBISP 之类ISP 下载器的依赖(虽然ISP 下载器已经很方便了, 但它毕竟还需要银子嘛)。 AVR 在硬件架构上与STC51 是一个套路, 如图7.16 所示。 通过配置 AVR 的熔丝位可以控制复位入口地址以及 BOOT 区的大小和开始地址, 如图7.17 所示。 讲到这里, 有人会说:“那有没有一种单片机, 程序放在 ROM 的任何位置都可以运行起来, 也就是中断向量表可以重定位?”当然有, 这种单片机还很多, 其中最典型的就是 STM32。它的程序之所以可以放之各地皆可运行, 是因为在它的 NVIC 控制器中提供了中断向量表偏移量的相关配置, 这个后面我们再详细说。 2. ROM 要支持IAP 这也是需要单片机硬件支持的。很好理解, 在 BL 获取到固件数据之后, 需要将它写入到ROM 的 APP 区中, 所以说单片机需要支持IAP 操作, 所谓IAP 就是 In Application Programming, 即在应用烧录。也就是在程序运行过程中, 可以对自身 ROM 进行擦除和编程操作 。 大家仔细想想是不是这样? 似乎支持串口ISP 的单片机都支持IAP 功能。STC 还把这一功能包装成了它的一大特色, 可以用内部 ROM 来充当 EEPROM 的功能, 可以在运行时记录一些掉电不丢失的参数信息。 STM32 的 ROM 擦写在配套的固件库(标准库或 HAL 库) 中已经有实现, 大家可以参考或直接使用。 3. APP 程序的配套修改 为了让 BL 可以顺利地将 APP 程序引导运行起来, APP 程序在开发的时候需要配合 BL做出相应的修改。最重要的就是 APP 程序的开始地址(即中断向量表的开始地址) 以及对中断控制器的相应配置。 对于51 、AVR 这类单片机 APP 程序不用修改, 具体原因大家应该明白。这里主要对STM32 APP 程序如何修改进行详细讲解。 我们依然是结合实例, 如图7.18 所示。 假设我们所使用的STM32 的 ROM 总大小为128KB,BL 程序的体积是16KB,APP 程序紧邻 BL, 那么 APP 区的开始地址为0X08004000, 也就是 APP 程序的中断向量表偏移地址为0X4000。 如果我们使用 MDK 作为开发环境的话, 需要修改这里, 如图7.19 所示。 而如果我们使用的是gcc 的话, 则需要对link.ld 链接文件进行修改, 如图7.20 所示。 然后我们还需要对 NVIC 的中断向量表相关参数进行配置, 主要是中断向量表的偏移量,如下代码: #define VECT_TAB_OFFSET 0x4000 OK, 经过修改后的程序, 我们把它放到 ROM 的0X08004000 开始地址上, 然后再让 BL跳转到这个地址, 我们的程序就能运行起来了。 有人又会问:“BL 中的跳转代码怎么写?”别急, 这是我们要讲的下一个要点 4. BL 中的跳转代码 跳转代码是 BL 要点中的关键, 直接关系到 APP 程序能否正常运行, 如图7.21 所示。我直接给出STM32 的 jump _app 函数代码。 typedef void ( * iapfun)(void); iapfun jump2app; void MSR_MSP(u32 addr) { __ASM volatile("MSR MSP, r0" ); //set Main Stack value __ASM volatile("BX r14" ); } void load_app(u32 appxaddr) { if((( * (vu32* )appxaddr)&0x2FFE0000) ==0x20000000) //检查栈顶地址合法 { //用户代码区第二个字为程序开始地址(复位地址) jump2app= (iapfun) * (vu32* )(appxaddr+4); //初始化APP 堆栈指针(用户代码区的第一个字用于存放栈顶地址) MSR_MSP( * (vu32* )appxaddr); jump2app(); //跳转到APP. } } 这段代码大家自行研究, 如果展开讲就属于赘述了。到这里 BL 相关的要点就介绍完了, 大家应该有能力去完成一个简单的 BL 了。我基于STM32 设计了一个小实验, 大家有兴趣可以小试牛刀一下, 如图7.22 所示。 我们将 BL 程序用Jlink 烧录到0X08000000 位置, 而把 APP 程序烧录到0X08002000 开始位置, 然后复位, 如果串口打印了hello world 或流水灯亮起来了, 就说明我们的BL 成功了。 3. 把Bootloader 玩出花 上面我所讲的都是 BL 最基础的一些内容, 是我们实现 BL 所必须了解的。BL 真正的亮点在于多种多样的固件数据获取方式。 3.1 BL 的实现与延伸(串口传输固件) 前面我讲到过两个 BL 应用的实例, 一个是串口传输固件文件, 一个是 SD 卡拷贝固件文件。它们是在实际工程中经常被用到的两种 BL 形式。 这里着重对前一个实例的实现细节进行讲解剖析, 因为它非常具有典型意义, 如图7.23 所示。 这个流程图提出了3 个问题: 串口通信协议是如何实现的? 为什么获取到上位机传来的固件数据,不是直接写入到 APP 区,而是先暂存,还要校验? 对固件数据是如何实现校验的? 串口通信协议以及文件传输实现的相关内容略显繁杂, 在本书《 大话文件传输》一章中会专门进行讲解。 第二个问题: 经过串口传输最终由单片机接收到的固件数据是可能出现差错的, 而有错误的固件冒然直接写入到 APP 区, 是一定运行不起来的。所以, 我们要对数据各帧进行暂存, 等全部传输完成后, 对其进行整体校验, 以保证固件数据的绝对正确。 针对第三个问题, 我们要着重探讨一下。 一个文件从发送方传输到接收方, 如何确定它是否存在错误? 通常的做法在文件中加入校验码, 接收方对数据按照相同的校验码计算方法计算得到校验码, 将之与文件中的校验码进行对比, 一致则说明传输无误, 如图7.24 所示。 图7.24 是对固件文件的补齐以及追加校验码的示意。为什么要对文件补齐? 嵌入式程序经过交叉编译生成的可烧录文件, 比如 BIN, 多数情况下都不是128、256 、512 或1024 的整数倍。这就会导致在传输的时候, 最后一帧数据的长度不足整帧, 就会产生一个数据尾巴。取整补齐是解决数据尾巴最直接的方法。这一操作是在上位机上完成的, 通常是编写一个小软件来实现。这个小软件同时会将校验码追加到固件文件末尾。这个校验码可以使用校验和(CheckSum) 或者 CRC, 一般是16 位或32 位, 如图7.25 所示。 又有人会问:“要把整个固件暂存下来, 再作校验, 那得需要额外的存 储 空 间 吧, 外 扩ROM(FlashROM 或 EEPROM)?”是的。如果想节省成本, 我们也可以不暂存, 传输时直接烧写到 APP 区。这是有风险的, 但是一般来说问题不大(STC 和 STM32 的串口ISP 其实也都是实时烧写, 并不暂存)。因为在传输的过程中, 传输协议对数据的正确性是有一定保障的, 它会对每一帧数据进行校验, 失败的话会有重传, 连续失败可能会直接终止传输。所以说, 一般只要传输能够完成, 基本上数据正确性不会有问题。但是仍然建议对固件进行整体校验, 在成本允许的情况下适当扩大 ROM 容量。同时, 固件暂存还有一个另外的好处, 在 APP 区中的固件受到损坏的时候, 比如固件意外丢失或IAP 时不小心擦除了 APP 区, 此时我们还可以从暂存固件恢复回来(完备的 BL 会包含固件恢复的功能)。 其实也不必非要外扩 ROM, 如果固件体积比较小的话, 我们可以把单片机的片上 ROM砍成两半来用, 用后一半来作固件暂存。 如图7.26 所示, 我们将片上 ROM 划分为3 部分, 分别用于存储 BL、APP 固件以及暂存固件。比如 我 们 使 用 STM32F103RBT6 , 它 一 共 有 128 KB 的 ROM, 可 以 划 分 为 16 KB/ 56 KB/56 KB。 有些 产 品 对 成 本 极 为 敏 感。我 就 有 过 这 样 的 开 发 经 历, 当 时 使 用 的 单 片 机 是STM32F103C8T6 , 片上 ROM 总容量为64 KB, 固件大小为48 KB,BL 为12 KB。在通过BL进行固件烧写时根本没有多余的 ROM 进行固件暂存。我使用了一招“狗尾续貂”, 如图7.27所示。 我无意中了解到 STM32F103C8T6 与 RBT6 的晶元是同一个。只 是 因 为 有 些 芯 片 后64 KB 的 ROM 性能不佳或有瑕疵, 而被限制使用了。我实际测试了一下, 确实如此。但是后64 KB ROM 的使用是有前提的, 也就是需要事先对其好坏进行验证。如果是好的, 则暂存校验, 再写入 APP 区; 而如果是坏的, 那么就直接在固件传输时实时写入 APP 区(这个办法我屡试不爽, 还没有发现后64KB 有坏的)。 以上所介绍的是一种“骚操作”, 根本上还是有一定的风险的,ST 官方有声明过, 对后64K ROM 的质量不作保证, 所以还是要慎用。 3.2 10 米之内隔空烧录 OTA (On the Air) 这个“隔空烧录”源于我的一个IoT 项目, 它是对空调的外机进行工况监测。大家知道,空调外机的安装那可不是一般人能干的, 它要不就在楼顶, 要不就在悬窗上。这给硬件升级嵌入式程序带来很大的困难。所以, 我实现了“隔空烧录”的功能, 其实它就是串口 BL 应用的一个延伸, 如图7.28 所示。 “隔空烧录确实牛, 但是总要抱着一个电脑, 这不太方便吧。”确实是! 还记得前面我提过的 AVRUBD 通信协议吗? (详见“大话文件传输”一章) 它的上位机软件是有手机版的。这样我们只要有手机, 就能“隔空烧录”了, 如图7.29 所示。 “哪个 APP? 快告诉我名字”, 别急, 蓝牙串口助手安卓版, 图 7.30 是正在传输固件的界面。 AVRUBD 其实是对 Xmodem 协议的改进, 这个我们放在专门的章节进行详细讲解。 3.3 BL 的分散烧录 我们知道 BL 的核心功能其实就是程序烧录。那你有没有遇到过比较复杂的情况, 如图7.31 所示。 这种情况是有可能遇到的。主 MCU+CPLD+ 通信协处理器+ 采集协处理器就是典型的复杂系统架构。这种产品在批量生产阶段, 烧录程序是非常烦琐的。首先需要维护多个固件, 再就是需要一个个给每一个部件进行烧写, 烧写方式可能还不尽相同。所以我引入了一个机制, 叫“BL 的分散烧录”。 首先我们将所有的固件拼装成一个大固件(依次数据拼接), 并将这个大固件预先批量烧录到外扩 ROM 中, 比如spiFlash; 再将主 MCU 预先烧录好 BL; 然后进行SMT 焊接。PCBA生产出来之后, 只要一上测试工装(首次上电),BL 会去外扩 ROM 中读取大固件, 并从中分离出各个小固件, 分别以相应的接口烧录到各个部件中去。配合工装的测试命令, 直接进行自检。这样做, 批量化生产是非常高效的。当然, 这个 BL 开发起来也会有一定难度, 最大问题可能还是各个部件烧录接口的实现( 有些部件的烧录协 议 是 比 较 复 杂 的, 比 如 STM32 的SWD 或者 ESP8266 的SLIP)。 OK, 上面对一些 BL 实例的实现和应用场景进行了介绍。还有一些实例没有介绍, 比如通过 CAN 总线或SPI 进行文件传输, 这个我们还是放到专门的章节去详细讲解。当然, 各位读者可以在此基础上衍生出更多有特色而又实用的 BL 来。 BL 没有最好的, 只有最适合自己的。通常来说, 我们并不会把 BL 设计得非常复杂, 原则上它应该尽量短小精炼, 以便为 APP 区节省出更多的 ROM 空间。毕竟不能喧宾夺主, APP才是产品的主角。 4. 不走寻常路的BL 4.1 Bootpatcher 我来问大家一个问题:“Bootloader 在 ROM 中的位置一定是在 APP 区前面吗?”很显然不是,AVR 就是最好的例子。那如果我们限定是STM32 呢? 似乎是的。上电复位一定是从0X08000000 位置开始运行的, 而且 BL 一定是先于 APP 运行的。 在某些特殊的情况下, 如果 APP 必须要放在0X08000000 位置上的话, 请问还有办法实现 BL 串口烧录吗? 要知道 APP 在运行的时候, 是不能IAP 自己的程序存储器的(就是自己不能擦除自己来烧录新固件), 如图7.32 所示。 APP 运行时, 想要重新烧录自身, 它可以直接跳转到后面的BL 上,BL 运行起来之后开始接收固件文件, 暂存校验 OK 之后, 将固件写入到前面的 APP 区。然后跳转到0X08000000, 或者直接重启。这样新的 APP 就运行起来了。这个位于 APP 后面的 BL, 我们称之为 Bootpatcher(意为启动补丁)。但是这种做法是有风险的, 一旦 APP 区烧录失败, 那产品就变砖了。所以这种方法一般不用。 4.2 APP 反烧BL 前面我们都是在讲 BL 烧录 APP, 那如果 BL 需要升级怎么办呢? 用JLINK。不错, 不过有更直接的方法, 如图7.33 所示。 这是一种逆向思维, 我们在 APP 程序中也实现接收固件文件, 暂存校验, 然后将其烧录到BL 区。这种做法与 Bootpatcher 同理, 也是有一定风险的, 但一般都没有问题。
单片机内置了非常便于使用的外设功能。但是，如果要有效地运行单片机，程序是不可或缺的，那么程序到底是如何运行的呢？本期我们将向大家介绍单片机与程序的关系。 01 单片机的存储器 首先来了解存储器﹑主存储器和外置存储器的两种作用 记忆（保存）程序和数据的地方即存储器。存储器有以下两种类型。 主存储器CPU能够直接进行存取的存储器，用于保存正在执行中的程序和数据 外置存储器（辅助存储器、二级缓存器）不能从CPU直接进行存取，需通过USB或串行、并行的各种I/O来进行存取，用于保存不在执行当中（处理中）的应用和数据 外置存储器中的程序需传送到主存储器后才能执行。关于单片机的存储器，常会看到ROM（Read Only Memory：只读存储器）和RAM（Random Access Memory：可读写存储器）等词汇，其实ROM和RAM仅是表示存储器性质，而与存储器的作用无关。（请参考单片机入门(1)，了解单片机的基本结构和操作） 地址空间（内存空间） CPU能够直接进行读写的所有空间被称为“地址空间（或内存空间）”。这个地址空间的每个字节都标注有号码。这个号码称为“地址(address)”，一般以十六进制来表示。上面所介绍过的主存储器都包含在地址空间内。 根据不同用途，单片机的CPU已开发出了4位、8位、16位和32位。在GR-SAKURA中使用的RX63N单片机搭载了32位的CPU，因此也被称为“32位单片机”。那么，单片机所拥有的地址空间容量到底有多少呢？以RX63N为例，由于是32位的CPU，因此最大能够指定约40亿（2的32次方）个地址。确切地说是4,294,967,296（4x1024x1024x1024）个地址。由于一个地址可以记忆一个字节，这时也可以表示为具有“4GB（千兆字节）的地址空间”。地址空间的容量越大越能搭载大容量的存储器， 也可容纳更大的程序。因此能够实现更高功能的应用。 32位字节的CPU所拥有的４G字节的地址空间示例如图1所示。左边所示的是以十六进制标示的地址。由于一列保存有4个字节（=32位），所以左边所标记的地址就是每4个地址的值。 图1:地址空间及标示例 计算机的单位：位、字节、兆、千兆和兆兆（太） 数据的基本单位是位（b=bit），每个位的值为"0"或"1"。8位为1个字节（B=Byte）。例如，3个字节（3×8位）等同于24位。 电脑存储设备的容量所使用的单位，大家耳熟能详的有KB（千字节）、MB（兆字节）、GB（千兆字节）和TB（太字节）等。一般情况下会说1GB＝1000MB或者这样写出来，但在计算机的世界里，此单位并非为1000倍，而是1024倍（2的10次方），因此正确的表示如下： 1KB（千字节）＝2的10次方 ＝ 1,024 字节 1MB（兆字节）＝1,024KB ＝ 2的20次方 1,048,576 字节 1GB（千兆字节）＝1,024MB ＝ 2的30次方 ＝ 1,073,741,824 字节 1TB（太字节）＝1,024GB ＝ 2的40次方 ＝ 1,099,511,627,776字节 表示地址的十六进制指的是什么？ 地址空间内的地址以16进制来表示。例如，拥有16位（2的16次方）大小的地址空间中，如果以10进制来表示，就是“从地址0到地址65535”，如果以16进制来表示，则是从“地址0h到地址FFFFh”。在10进制中，每一位所取的值都在0到9之间，而在16进制中，则是0到F（相当于10进制的15）。以16进制表示的数，最后都有一个“h”，标明是以16进制来表示的。 程序保存在哪儿呢？（向量表） 那么，程序被保存在地址空间的什么地方，又是怎么样开始工作的呢？单片机复位后便开始执行最优先程序。复位是在接通电源或接收到复位信号时发生。实际上，这种“开始执行最优先程序”处理中，有如下所示的两种方法。 即开始执行程序时，有将执行程序的起始地址设为固定的CPU及将之设为可变地址的CPU。 在将起始地址设为固定的CPU中，大多是从地址0（地址空间中最小的地址）开始执行。这就是程序开始的地点。而且，有时要事先在地址0中实现写入“下一个要执行的是地址○○”的跳转(Jump)指令，并将程序预先放置在“地址○○”中。如果改写“地址○○”，将可获得与将起始地址设为可变地址同样的效果。 将起始地址设为可变地址的CPU将起始地址写入被称为“向量表”的部分中（图2）。向量表是只存放地址空间中各种起始地址的特定区域的名称。一般来说是它放置在地址空间中最大地址的部分。 图2：RX63N系列的向量表以RX63N为例，由于地址是以32位来显示的，为了保存它就需要4个字节。这就意味着图3中的“复位”部分表示从地址FFFFFFFCh到地址FFFFFFFFh的4个字节中保存了程序的起始地址。CPU复位后将读取保存于此的地址，并从作了标记的地址开始执行。被写入向量表的不仅是复位后的起始地址，向量表中还保存发生中断时程序的起始地址和异常处理(Exception Handling)的起始地址。也正因为保存了发生中断及异常处理等因多种事由的起始地址，所以才被称为“表(Table)”。我们来设想一下使用了向量表的程序处理的情况。图3表示出了发生非屏蔽中断（NMI） (*1) 时的处理流程例。 产生NMI， 读取写在向量表的NMI的起始地址（此例中为10000000h）， 执行所读取地址（10000000h）中的NMI程序。 图3：使用向量表进行处理的流程(*1)非屏蔽中断（NMI）：所谓非屏蔽指的是无法禁止的意思。如有中断请求，CPU将无条件地执行中断处理。可用于通过看门狗定时器进行的中断处理等。关于看门狗定时器，在本连载的第2期--“定时器”中已为大家作了介绍。如上所述，在将程序的起始地址设为可变的CPU中，由于能够通过写入向量表来指定中断处理的起始地址，因此具有在地址空间中自由配置中断处理程序的特征。介绍了CPU的地址空间与外设功能的关系、以及程序是从哪里开始执行的等内容。接下来我们将通过说明执行程序时的处理和内存的关系来进一步理解单片机的有效运行。 02 引导程序的运行―程序计数器 我们已经学习了将程序放在地址空间中，并在向量表中显示保存位置的内容。接下来将介绍在执行程序及产生中断时CPU内会发生什么变化。 一般来说，程序就是计算机将所要进行的处理按顺序排列的指令集。在单片机中，将程序保存在地址空间（存储器 空间）中，并由CPU来执行(处理)指令。假设地址空间中的一个地址保存一条指令，先执行某个地址中的指令（如“将值置位到CPU中”处理），接着执行下一个地址中的指令，接下来再执行下一个地址中的指令……，像这样通过连续执行指令，便可执行程序。 那么，CPU是如何判断执行指令的顺序呢？在单片机中，程序被执行的时候“程序计数器（PC）”的值也同时被更新。存放在CPU内的指令地址中，程序计数器存储有下一条CPU将要执行的指令所在的地址。执行了某个地址的指令后，下一个该执行哪个地址中的指令呢？这个答案由程序计数器来告诉你。一般来说，程序被保存在连续的地址中， 再由CPU按顺序执行存放在各个地址中的指令。图１为程序计数器的示意图。图中，假定（1）执行地址1000h中的指令，（2）执行地址1000h中的指令后，程序计数器的値自动增加一个量并显示出下一个地址1001h，接下来，（3）CPU执行地址1001h中的指令。 图1：程序计数器那么，CPU执行最初的指 令时是一种什么状况呢？单片机在接通电源或是复位时，如上期所说明的，保存在向量表的复位地址中的値（程序的起始地址）将被转移到程序计数器中，该地址中的指令便得到执行。 改变程序的运行路径―转移指令 编写程序时，在执行完某个指令的处理后有时必须先执行保存“(非连续)的下一个地址”中的指令。此时，程序计数器的值将被改写，而所用的指令被称为“转移指令”。图2所示是转移指令的示意图。图2示例中，(1)地址1000h中存放有转移指令，即将（2）程序计数器的值改写为下一个应执行的地址 （1100h）的指令。即CPU执行完1000h地址的指令（转移指令）后，接下来不是执行1001h地址的指令，而是执行（3）1100h地址的指令。 图2：转移指令另外，在转移指令中，能够利用“从当前的程序计数器的值向前（更大的地址）／向后（更小的地址）移动”的方法来设定程序计数器的值 。 信息的暂时存放处―堆栈 执行程序时，在运算过程中仅仅依靠CPU内的数据保存位置（CPU内部寄存器）是不够的，有时需在主存储器中暂时存放信息。这种信息的暂时存放位置被称为“堆栈”,而存放“下一个（暂时）存放的信息地址”的就是“堆栈指针（SP）”。如果一开始就设定好堆栈的地址，那么堆栈指针将自动更新，且总是指示“下一个（暂时）存放的信息地址”。 ⇒CPU内部寄存器等单片机的结构请参照《单片机入门（1）》。如果执行“将该信息存放（有时也用 “堆积”）在堆栈”的指令，那么被指定的信息将会被写入堆栈指针所指定的地址中，且堆栈指针的值也将被更新为新的地址（一般为一个小地址）。该情形如图3所示。如果（1）CPU将信息存放在堆栈指针所指的地址中，则（2）堆栈指针的値将被更新，然后（3）堆栈指针指向下一个存放信息的位置。 图3：将信息存放在堆栈中"将存放在堆栈中的信息返回CPU时，也将用到堆栈指针。图4所示的是将信息返回时的情形。（1）更新堆栈指针的値（更新为 一个大的地址），（2）将暂时存放在堆栈中的信息返送回CPU。此时，（3）堆栈指针指向下一个写入地址（先前将信息返回CPU后空出的地址）。 图4：将信息从堆栈返回但是堆栈中并非可无限制地保存信息。由于堆栈能使用的范围仅限于可改写的被称为RAM的存储器。如果信息存放量过多而导致堆栈超出了RAM的区域，程序将无法正常运行。 理解中断处理 我们将以发生中断时的处理为例来进行思考（图5）。中断处理就是指在执行某个程序的过程中，由于某种原因（产生中断）而导致开始执行完全不同的程序。我们以来自外设功能之一的独立的看门狗计时器（WDT、所谓的Watch Dog即看门狗的意思）的中断为例来进行分析。在程序正常运行时独立的看门狗定时器将什么也不做，但是在程序失去控制，且没有按必要的步骤进行处理时就会产生中断。使失去控制的程序停下并让系统稳定停止的处理是由通过中断开始的程序来执行的。 图5：中断处理的流程 首先，在产生中断时，必须使运行中的程序入栈。 在中断处理 “入栈”时，将信息存放在堆栈指针指向的地址（堆栈）中。进行中断处理时存放在堆栈中的信息就是正 在执行的原先的程序（被中断的程序）时的程序计数器的值，即原先的程序执行到哪一步的信息（地址）。另外，显示CPU内部状态的信息和暂时保存的值也存放 在堆栈中。 如果CPU内部的信息存放在堆栈中且完成“交付”准备（入栈）后，将执行中断程序。中断程序与正在执行的程序不同且所保 存的地址空间也不同，所以程序计数器的值与原先程序也完全不同。中断程序的起始位置将被写入向量表中。起始位置该写在向量表中的哪一项取决于所产生 的中断。 例如，如果存在不可屏蔽中断（NMI，即CPU不能屏蔽的中断），那就从写有NMI项的地址开始进行处理（请参照本文第一节的图 2及图3）。 ⇒使用向量表进行处理的流程在本文第一节中进行解说。 如上所述，向量表的NMI项中的值（地址）将转移到程序计数器中， 并从该处开始执行。此外，如将数值设为0而产生错误时，或者欲存取到无存储器的位置时，CPU本身将产生中断并从向量表中读取开始处理的地址。此例中， 由于在检测到程序失控时是通过独立的看门狗定时器进行中断处理的，所以中断程序将使系统停止下来。 如为一般的周期性中断，那么，中断处理一结束，且在入栈时将存放在堆栈中的“执行原先执行程序时的信息”返回到CPU。最后返回程序计数器的值，并结束从中断返回的处理“出栈”。 开始中断程序时，通过来自外部的信号或从CPU本身发出的指令来开始入栈。出栈时使用“来自中断的出栈指令”，因此编程人员无需考虑“堆栈 中存放有什么信息又是按什么顺序来存放的？”等问题，仅需一条指令便可进行出栈处理。结合本文第一节的内容，从执行程序的观点来分析 ，本期对于CPU中到底产生了什么变化进行了说明。程序存放在地址空间中，且在向量表中保存有起始地址，而且还有将信息暂时存放的被称为堆栈的内容等 等……，在进行嵌入式编程时，必须同时考虑这些内部动作后再进行编程。如果可通过程序对于更细微的部分发出指示，且能发挥出该单片机的能力的话，编程将变得更加容易。
在刚开始接触STM32的时候，使用的keil作为IDE，由于在这之前，使用过VS， 使用过eclipse，因而在使用keil之后，实在难以忍受keil编辑器简陋的功能，可以说是极其糟糕的写代码体验。 之后，尝试过各种IDE，使用eclipse+keil，结果发现eclipse对C语言的支持也是鸡肋，使用emBits+gcc，需要和其他人协同的话就比较麻烦，之后发现了platformIO，也是使用gcc作为编译器，不过只支持HAL库，而且还有一个重要的原因，同事都是用的keil，如果我使用gcc，就不能协同工作了。 最后，通过使用VS Code + keil的方式，完美解决了写代码的体验问题，以及工程协作问题，其实网上使用VS Code作为编辑器，keil作为编译器的教程很多，不过基本都是需要在VS Code中编辑，然后在keil中编译，下载，调试，本文就要实现编辑，编译，下载，调试，全部使用VS Code。 Part1环境 （1）VS Code； （2）keil；python； （3）GNU Arm Embedded Toolchain（arm gcc工具链）； （4）C/C++(VS Code 插件)； （5）Cortex-Debug(VS Code 插件)； （6）其他VS Code插件(提升体验)。 Part2前提 正式写代码之前，首先需要建立好一个工程，这个需要使用keil完成，包括工程配置，文件添加… Part3编辑 在安装好VS Code插件之后，VS Code编写C代码本身体验就已经很好了， 但是，因为我们使用的是keil环境，所以需要配置头文件包含，宏定义等，在工程路径的.vscode文件夹下打开c_cpp_properties.json文件，没有自己新建一个，内容配置如下： { "configurations": [ { "name": "STM32", "includePath": [ "D:/Program Files/MDK5/ARM/ARMCC/**", "${workspaceFolder}/**", "" ], "browse": { "limitSymbolsToIncludedHeaders": true, "databaseFilename": "${workspaceRoot}/.vscode/.browse.c_cpp.db", "path": [ "D:/Program Files/MDK5/ARM/ARMCC/**", "${workspaceFolder}/**", "" ] }, "defines": [ "_DEBUG", "UNICODE", "_UNICODE", "__CC_ARM", "USE_STDPERIPH_DRIVER", "STM32F10X_MD" ], "intelliSenseMode": "msvc-x64" } ], "version": 4 } 其中，需要在includePath和path中添加头文件路径，${workspaceFolder}/**是工程路径，不用改动，额外需要添加的是keil的头文件路径， 然后在defines中添加宏，也就是在keil的Options for Target的C++选项卡中配置的宏，然后就可以体验VS Code强大的代码提示，函数跳转等功能了（甩keil的编辑器一整个时代）。 Part4编译、烧录 编译和烧录通过VS Code的Task功能实现，通过Task，使用命令行的方式调用keil进行编译和烧录。 keil本身就支持命令行调用，具体可以参考keil的手册，这里就不多说了，但是问题在于，使用命令行调用keil，不管是什么操作，他的输出都不会输出到控制台上！！！(要你这命令行支持有何用) 不过好在，keil支持输出到文件中，那我们就只能利用这个做点骚操作了。一边执行命令，一边读取文件内容并打印到控制台，从而就实现了输出在控制台上，我们就能直接在VS Code中看到编译过程了 为此，我编写了一个Python脚本，实现keil的命令行调用并同时读取文件输出到控制台。 #!/usr/bin/python # -*- coding:UTF-8 -*- import os import threading import sys runing = True def readfile(logfile): with open(logfile, 'w') as f: pass with open(logfile, 'r') as f: while runing: line = f.readline(1000) if line != '': line = line.replace('\\', '/') print(line, end = '') if __name__ == '__main__': modulePath = os.path.abspath(os.curdir) logfile = modulePath + '/build.log' cmd = '\"D:/Program Files/MDK5/UV4/UV4.exe\" ' for i in range(1, len(sys.argv)): cmd += sys.argv[i] + ' ' cmd += '-j0 -o ' + logfile thread = threading.Thread(target=readfile, args=(logfile,)) thread.start() code = os.system(cmd) runing = False thread.join() sys.exit(code) 此脚本需要结合VS Code的Task运行，通过配置Task，我们还需要匹配输出中的错误信息(编译错误)，实现在keil中，点击错误直接跳转到错误代码处，具体如何配置请参考VS Code的文档，这里给出我的Task。 { // See https://go.microsoft.com/fwlink/?LinkId=733558 // for the documentation about the tasks.json format "version": "2.0.0", "tasks": [ { "label": "build", "type": "shell", "command": "py", "args": [ "-3", "${workspaceFolder}/scripts/build.py", "-b", "${config:uvprojxPath}" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": [ { "owner": "c", "fileLocation": [ "relative", "${workspaceFolder}/Project" ], "pattern": { "regexp": "^(.*)\\((\\d+)\\):\\s+(warning|error):\\s+(.*):\\s+(.*)$", "file": 1, "line": 2, "severity": 3, "code": 4, "message": 5 } } ] }, { "label": "rebuild", "type": "shell", "command": "py", "args": [ "-3", "${workspaceFolder}/scripts/build.py", "-r", "${config:uvprojxPath}" ], "group": "build", "problemMatcher": [ { "owner": "c", "fileLocation": [ "relative", "${workspaceFolder}/Project" ], "pattern": { "regexp": "^(.*)\\((\\d+)\\):\\s+(warning|error):\\s+(.*):\\s+(.*)$", "file": 1, "line": 2, "severity": 3, "code": 4, "message": 5 } } ] }, { "label": "download", "type": "shell", "command": "py", "args": [ "-3", "E:\\Work\\Store\\MyWork\\STM32F1\\FreeModbus_M3\\scripts\\build.py", "-f", "${config:uvprojxPath}" ], "group": "test" }, { "label": "open in keil", "type": "process", "command": "${config:uvPath}", "args": [ "${config:uvprojxPath}" ], "group": "test" } ] } 对于使用ARM Compiler 6编译的工程，build和rebuild中的problemMatcher应该配置为： "problemMatcher": [ { "owner": "c", "fileLocation": ["relative", "${workspaceFolder}/MDK-ARM"], "pattern": { "regexp": "^(.*)\\((\\d+)\\):\\s+(warning|error):\\s+(.*)$", "file": 1, "line": 2, "severity": 3, "message": 4, } } ] 文件中的config:uvPath和config:uvprojxPath分别为keil的UV4.exe文件路径和工程路径(.uvprojx)，可以直接修改为具体路径，或者在VS Code的setting.json中增加对应的项，至此，我们已经完美实现了在VS Code中编辑，编译，下载了。 编译输出： 有错误时输出： 错误匹配： Part5调试 调试需要使用到Cortex-Debug插件，以及arm gcc工具链，这部分可以参考Cortex-Debug的文档，说的比较详细； 首先安装Cortex-Debug插件和arm gcc工具链，然后配置好环境路径，如果使用Jlink调试，需要下载Jlink套件，安转好之后，找到JLinkGDBServerCL.exe这个程序，在VS Code的设置中添加"cortex-debug.JLinkGDBServerPath": "C:/Program Files (x86)/SEGGER/JLink/JLinkGDBServerCL.exe"，后面的路径是你自己的路径。 这里补充一下arm gcc工具链的配置："cortex-debug.armToolchainPath": "D:\\Program Files (x86)\\GNU Arm Embedded Toolchain\\9 2020-q2-update\\bin",后面的路径是你自己的路径。如果使用STLink调试，需要下载stutil工具，在GitHub上搜索即可找到，同样配置好路径即可。 以上步骤弄好之后，可以直接点击VS Code的调试按钮，此时会新建luanch.json文件，这个文件就是VS Code的调试配置文件，可参考我的文件进行配置。 { // 使用 IntelliSense 了解相关属性。 // 悬停以查看现有属性的描述。 // 欲了解更多信息，请访问: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "name": "Cortex Debug(JLINK)", "cwd": "${workspaceRoot}", "executable": "${workspaceRoot}/Project/Objects/Demo.axf", "request": "attach", "type": "cortex-debug", "servertype": "jlink", "device": "STM32F103C8", "svdFile": "D:\\Program Files\\ARM\\Packs\\Keil\\STM32F1xx_DFP\\2.3.0\\SVD\\STM32F103xx.svd", "interface": "swd", "ipAddress": null, "serialNumber": null }, { "name": "Cortex Debug(ST-LINK)", "cwd": "${workspaceRoot}", "executable": "${workspaceRoot}/Project/Objects/Demo.axf", "request": "attach", "type": "cortex-debug", "servertype": "stutil", "svdFile": "D:\\Program Files\\ARM\\Packs\\Keil\\STM32F1xx_DFP\\2.3.0\\SVD\\STM32F103xx.svd", "device": "STM32F103C8", "v1": false } ] } 注意其中几个需要修改的地方，executable修改为你的工程生成的目标文件，也就是工程的.axf文件，svdFile用于对MCU外设的监控，该文件可以在keil的安装路径中找到，可以参考我的路径去找，配置完成后，再次点击调试按钮即可进行调试。 相比keil自己的调试功能，VS Code还支持条件断点，可以设置命中条件，次数等，可以极大的方便调试。 总结 通过以上的配置，我们基本上，除了建立工程和往工程中添加文件，其他完全不需要打开keil，所以也无妨说一句，再见，智障keil！
一定有很多人都听说过嵌入式和单片机，但在刚开始接触时，不知道大家有没有听说过嵌入式就是单片机这样的说法，其实嵌入式和单片机还是有区别的。单片机与嵌入式到底有什么关系？ 下面我们就来说说嵌入式和单片机之间的联系和区别吧。 01 什么是单片机？ 首先，我们来了解一下到底什么是单片机。 嵌入式系统的核心是嵌入式处理器。嵌入式处理器一般可以分为以下几种类型： 嵌入式微控制器MCU（Micro Control Unit） 嵌入式DSP处理器（Digital Signal Processor） 嵌入式微处理器MPU（Micro Processor Unit） 嵌入式片上系统SoC（System on Chip） 可编程片上系统SoPC（System on a Programmable Chip） 我们的单片机属于嵌入式微控制器MCU（Micro Control Unit） MCU内部集成ROM/RAM、总线逻辑、定时/计数器、看门狗、I/O、串口、A/D、D/A、FLASH等。典型代表如8051、8096、C8051F等。 单片机就是在一个芯片（Chip）上集成了CPU、SRAM、Flash及其他需要模块，在一个Chip上实现一个微型计算机系统，所以就叫Single Chip Microcomputer，也就是单片机了。 它其实就是一种集成电路芯片，是通过超大规模集成电路技术，将CPU、RAM、ROM、输入输出和中断系统、定时器/计数器等功能，塞进一块硅片上，变成一个超小型的计算机。 这么说来，单片机不就是一个嵌入式系统？ 别急，我们往下看。 “单片机”其实是一种古老的叫法。在那个年代半导体工艺还在起步阶段，集成能力很差，往往是CPU一个芯片，SRAM一个芯片，Flash一个芯片，需要中断的话又得有个专门处理中断的芯片，所以一个完整可用的计算机系统是很多个芯片（Chip）做在一个PCB板上构成的。 不同的功能无法做进一个芯片（Chip），所以会有多片机。现在半导体技术早已非常发达，所以不存在多片机。但是，“单片机”的叫法却一直延用至今。 单片机技术从上世纪70年代末诞生，早期的时候是4位，后来发展为8位，16位，32位。它真正崛起，是在8位时代。8位单片机功能很强，被广泛应用于工业控制、仪器仪表、家电汽车等领域。 我们在研究单片机的时候，经常会听到一个词——51单片机。让我们来了解一下它究竟是什么。 51单片机，其实就是一系列单片机的统称。该系列单片机，兼容Intel 8031指令系统。它们的始祖，是Intel（英特尔）的8004单片机。 注意，51单片机并不全是英特尔公司产品。包括ATMEL（艾德梅尔）、Philips（飞利浦）、华邦Dallas（达拉斯）、Siemens（西门子）、STC（国产宏晶等公司，也有很多产品属于51单片机系列。 ATMEL公司的51单片机，AT89C51这是一个51单片机的开发板，中间那个芯片才是51单片机 51单片机曾经在很长时间里都是市面上最主流、应用最广泛的单片机，占据大量的市场份额。 51单片机其实放在现在毫无技术优势，是一种很老的技术。之所以它的生命力顽强，除了它曾经很流行之外，还有一个原因，就是英特尔公司彻底开放了51内核的版权。 所以，无论任何单位或个人，都可以毫无顾忌地使用51单片机，不用付费，也不用担心版权风险，所以很多学校也都在用这个。 此外，51单片机拥有雄厚的存量基础和群众基础。很多老项目都是用的51单片机，出于成本的考虑，有时候只能继续沿用51单片机的技术进行升级。 而且，很多老一辈的工程师，都精通51单片机开发技术。 所以，51单片机的生命力得以不断延续。 02 什么是嵌入式？ 嵌入式系统是一种专用的计算机系统，作为装置或设备的一部分。通常，嵌入式系统是一个控制程序存储在ROM中的嵌入式处理器控制板。 事实上，所有带有数字接口的设备，如手表、微波炉、录像机、汽车等，都使用嵌入式系统，有些嵌入式系统还包含操作系统，但大多数嵌入式系统都是由单个程序实现整个控制逻辑。 从应用对象上加以定义，嵌入式系统是软件和硬件的综合体，还可以涵盖机械等附属装置。国内普遍认同的嵌入式系统定义为： 以应用为中心，以计算机技术为基础，软硬件可裁剪，适应应用系统对功能、可靠性、成本、体积、功耗等严格要求的专用计算机系统。 嵌入式系统具体应用于哪些“专用”方向呢？ 举例如下： 办公自动化：打印机，复印机、传真机 军事及航天类产品：无人机、雷达、作战机器人 家电类产品：数字电视、扫地机器人、智能家电 医疗电子类产品：生化分析仪血液分析仪、CT 汽车电子类产品：引擎控制、安全系统、汽车导航与娱乐系统 网络通信类产品：通信类交换设备、网络设备 (交换机、路由器、网络安全) 通信与娱乐：手机、数码相机、音乐播放器、可穿戴电子产品、PSP游戏机 工业控制类产品：工控机交互式终端 (POS、ATM)、安全监控、数据采集与传输、仪器仪表 上述这些领域，都使用了嵌入式系统。这还只是冰山一角。 可以说，嵌入式系统完完全全地融入了我们，时刻影响着我们的工作和生活。 嵌入式系统，既然是一个计算机系统，那么肯定离不开硬件和软件。 一个嵌入式系统的典型架构如下： 这里最重要的就是嵌入式操作系统和嵌入式微处理器。 从硬件角度来看，嵌入式系统就是以处理器（CPU）为核心，依靠总线（Bus）进行连接的多模块系统： 其实大家不难看出和个人PC是一样的方式。 单片机是有清晰定义的，就是单个片（chip）上的计算机系统。而不同的单片机虽然配置不同，性能不同，厂家不同，甚至指令集和开发方式不同，但是都是在一个片上的完整的计算机系统，这个定义不会错。 而嵌入式就是个不清晰的定义了，并没有非常明确的关于“嵌入式”这个词的定义。他也不像单片机一样，是个确定的“物”的名字。 03 单片机是不是嵌入式？ 那么单片机到底是不是嵌入式呢？ 简单来说：是。 因为很多嵌入式产品中被嵌入的计算机系统就是单片机，譬如空调中嵌入的控制板其实核心就是个单片机。实际上大部分家电产品中嵌入的计算机系统都是单片机。 因为单片机足够简单便宜而且够用，所以使用单片机是最划算最适合的。 而单片机现在出货量最大的领域也就是家电产品了，当然未来IOT类的应用会越来越多，会成为单片机的很大的增量市场。 04 广义和狭义的嵌入式 嵌入式这个概念实际上很泛化，现在讲嵌入式这个词的人，可能想表达的意思并不相同。咱们上面讲的嵌入式的概念是嵌入式本来的定义，也就是所谓广义上的嵌入式。 而狭义的嵌入式，其实是“嵌入式linux系统”的简称。 这种狭义的嵌入式最初指的是运行了linux系统的嵌入式计算机系统。后来也包括运行了和linux同级别的其他嵌入式系统（譬如WinCE、Vxworks、Android等）的计算机。 看过上面的介绍之后你就知道到底单片机是不是嵌入式了，其实这两者之间的联系有很深，总之，不管你是准备学习嵌入式或是单片机，都要自己想好了再做决定。 05 嵌入式和单片机的区别 说到这里，我们来看看，嵌入式和单片机的区别到底是什么。 从前文的介绍来看，嵌入式系统是一个大类，单片机是其中一个重要的子类。嵌式系统像是一个完整的计算机，而单片机更像是一个没有外设的计算机。 以前单片机包括的东西并不算多，两者的硬件区别较为明显。 但是，随着半导体技术的突飞猛进，现在各种硬件功能都能被做进单片机之中。所以，嵌入式系统和单片机之间的硬件区别越来越小，分界线也越来越模糊。 于是，人们倾向于在软件上进行区分。 从软件上，行业里经常把芯片中不带MMU（memory management unit，内存管理单元）从而不支持虚拟地址，只能裸奔或运行RTOS（实时操作系统，例如ucos、华为LiteOS、RT-Thread、freertos等）的system，叫做单片机（如STM32、NXP LPC系列、NXP imxRT1052系列等）。 同时，把芯片自带MMU可以支持虚拟地址，能够跑Linux、Vxworks、WinCE、Android这样的“高级”操作系统的system，叫做嵌入式。 在某些时候，单片机本身已经足够强大，可以作为嵌入式系统使用。它的成本更低，开发和维护的难度相对较小，尤其是针对一些针对性更强的应用。而嵌入式系统理论上性能更强，应用更广泛，但复杂度高，开发难度大。 06 我们为什么要学习嵌入式和单片机 今天我也只是给大家简单地介绍了一下单片机和嵌入式以及他们之间的关系和区别，虽然嵌入式系统已经有30多年的历史，但其实一直隐藏在背后的，自从物联网上升为国家战略后，嵌入式系统也渐渐从后台走到前台。 嵌入式和单片机并不是纯“硬件”类方向。如果你想学好嵌入式和单片机，只懂数字电路和微机接口这样的硬件知识是不够的，你更需要学习的，是汇编、C/C++语言、数据结构和算法知识。拥有软硬结合的能力，远远比单纯掌握某种程序开发语言更有价值。 其次，嵌入式和单片机拥有广泛的应用场景，在各个领域都有项目需求和人才需求。而且我们国家现在正在大力发展芯片产业，也会带动嵌入式人才的就业，提升待遇。 随着5G建设的深入，整个社会正在向“万物互联”的方向变革。 物联网技术也将迎来前所未有的历史机遇。嵌入式和单片机技术是物联网技术的重要组成部分，也将进入快速发展的时代。 技术越难，过程越苦，越有利于构建竞争壁垒。大学里很多同学都热衷于学习各种编程语言，往往忽视了这一块，可以说在嵌入式开发这一块的人才我们国家还是比较欠缺的。因此，我觉得大家非常值得投入时间去学习嵌入式开发的技能。原文：https://www.zhihu.com/question/315310041/answer/2179945564
嵌入式开发，特别是单片机os-less的程序，最易范的错误是全局变量满天飞。 这个现象在早期汇编转型过来的程序员以及初学者中常见，这帮家伙几乎把全局变量当作函数形参来用。 在.h文档里面定义许多杂乱的结构体，extern一堆令人头皮发麻的全局变量，然后再这个模块里边赋值123，那个模块里边判断123分支决定做什么。 每当看到这种程序，我总要戚眉变脸而后拍桌怒喝。没错，就是怒喝。 不否认全局变量的重要性，但我认为要十分谨慎地使用它，滥用全局变量会带来其它更为严重的结构性系统问题。 为什么全局变量要越少越好？ 它会造成不必要的常量频繁使用，特别当这个常量没有用宏定义“正名”时，代码阅读起来将万分吃力。 它会导致软件分层的不合理，全局变量相当于一条快捷通道，它容易使程序员模糊了“设备层”和“应用层”之间的边界。写出来的底层程序容易自作多情地关注起上层的应用。 这在软件系统的构建初期的确效率很高，功能调试进度一日千里，但到了后期往往bug一堆，处处“补丁”，雷区遍布。说是度日如年举步维艰也不为过。 由于软件的分层不合理，到了后期维护，哪怕仅是增加修改删除小功能，往往要从上到下掘地三尺地修改，涉及大多数模块， 而原有的代码注释却忘了更新修改，这个时候，交给后来维护者的系统会越来越像一个“泥潭”，注释的唯一作用只是使泥潭上方再加一些迷烟瘴气。 全局变量大量使用，少不了有些变量流连忘返于中断与主回圈程序之间。 这个时候如果处理不当，系统的bug就是随机出现的，无规律的，这时候初步显示出病入膏肓的特征来了，没有大牛来力挽狂澜，注定慢性死亡。 无需多言，您已经成功得到一个畸形的系统，它处于一个神秘的稳定状态！ 你看着这台机器，机器也看着你，相对无言，心中发毛。你不确定它什么时候会崩溃，也不晓得下一次投诉什么时候道理。 全局变量大量使用有什么后果？ “老人”气昂昂，因为系统离不开他，所有“雷区”只有他了然于心。当出现紧急的bug时，只有他能够搞定。你不但不能辞退他，还要给他加薪。 新人见光死，但凡招聘来维护这个系统的，除了改出更多的bug外，基本上一个月内就走人，到了外面还宣扬这个公司的软件质量有够差够烂。 随着产品的后续升级，几个月没有接触这个系统的原创者会发现，很多雷区他本人也忘记了，于是每次的产品升级维护周期越来越长， 因为修改一个功能会冒出很多bug，而按下一个bug，会弹出其他更多的bug。在这期间，又会产生更多的全局变量。 终于有一天他告诉老板，不行啦不行啦，资源不够了，ram或者flash空间太小了，升级升级。 客户投诉不断，售后也快崩溃了，业务员也不敢推荐此产品了，市场份额越来越小，公司形象越来越糟糕。 要问对策，只有两个原则 能不用全局变量尽量不用，我想除了系统状态和控制参数、通信处理和一些需要效率的模块，其他的基本可以靠合理的软件分层和编程技巧来解决。 如果不可避免需要用到，那能藏多深就藏多深。 如果只有某.c文件用，就static到该文件中，顺便把结构体定义也收进来； 如果只有一个函数用，那就static到函数里面去； 如果非要开放出去让人读取，那就用函数return出去，这样就是只读属性了； 如果非要遭人蹂躏赋值，好吧，我开放函数接口让你传参赋值； 实在非要extern侵犯我，我还可以严格控制包含我.h档的对象，而不是放到公共的includes.h中被人围观，丢人现眼。 如此，你可明白我对全局变量的感悟有多深刻，悲催的我，已经把当年那些“老人”交给我维护的那些案子加班全部重新翻写了。 最后补充 全局变量是不可避免要用到的，每一个设备底层几乎都需要它来记录当前状态，控制时序，起承转合。但是尽量不要用来传递参数，这个很忌讳的。 尽量把变量的作用范围控制在使用它的模块里面，如果其他模块要访问，就开个读或写函数接口出来，严格控制访问范围。 这一点，C++的private属性就是这么干的，这对将来程序的调试也很有好处。 C语言之所以有++版本，很大原因就是为了控制它的灵活性，要说面向对象的思想，C语言早已有之，亦可实现。 当一个模块里面的全局变量超过3个(含)时，就用结构体包起来吧，要归0便一起归0，省得丢三落四的。 在函数里面开个静态的全局变量，全局数组，是不占用栈空间的，只是有些编译器对于大块的全局数组，会放到和一般变量不同的地址区。 若是在keil C51，因为是静态编译，栈爆掉了会报警，所以大可以尽情驰骋，注意交通规则就是了。 单片机的os-less系统中，只有栈没有堆的用法，那些默认对堆分配空间的“startup.s”，可以大胆的把堆空间干掉。 程序模型？如何分析抽象出来呢，从哪个角度进行模型构建呢？很愿意聆听网友的意见。 本人一直以来都是从两个角度分析系统，事件--状态机迁移图 和 数据流图，前者分析控制流向，完善UI，后者可知晓系统数据的缘起缘灭。 这些理论，院校的《软件工程》教材都有，大家不妨借鉴下。只不过那些理论，终究是起源于大型系统软件管理的，牛刀杀鸡，还是要裁剪一下的。
【前面的话】在近几年的嵌入式社区中，流传着不少关于面相Cortex-M的Bootloader科普文章，借助这些文章，一些较为经典的代码片断和技巧得到了广泛的传播。 在从Bootloader跳转到用户APP的过程中，使用函数指针而非传统的汇编代码则成了一个家喻户晓的小技巧。相信类似下面 JumpToApp() 函数，你一定不会感到陌生： typedef void (*pFunction)(void); void JumpToApp(uint32_t addr){ pFunction Jump_To_Application; __IO uint32_t StackAddr; __IO uint32_t ResetVector; __IO uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 为了读懂这段代码，需要一些从事Cortex-M开发所需的“热知识”： 向量表是一个由 32bit 数据构成的数组 数组的第一个元素是 uintptr_t 类型的指针，保存着复位后主栈顶指针（MSP）的初始值。 从数组第二个元素开始，保存的是 (void (*)(void)) 类型的异常处理程序地址（BIT0固定为1，表示异常处理程序使用Thumb指令集进行编码） 数组的第二个元素保存的是复位异常处理程序的地址（Reset_Handler） 从理论上说，要想保证APP能正常执行，Bootloader通常要在跳转前“隐藏自己存在过的事实”——需要“对房间进行适度的清理”，并模拟芯片硬件的一些行为——假装芯片复位后是直接从APP开始执行的。 总结来说，Bootloader在跳转到App之前需要做两件事： 1. 清理房间——仿佛Bootloader从未执行过一样 2. 模拟处理器的硬件的一些复位行为——假装芯片从复位开始就直接从APP开始执行 一般来说，做到上述两点，就可以实现App将Bootloader视作黑盒子的效果，从而带来极高的兼容性。甚至在App注入了“跳床（trumpline）”的情况下，实现App既可以独立开发、调试和运行，也可以不经修改的与Bootloader一起工作的奇效。 如何在App中加入“跳床（trumpline）”值得专门再写一篇独立的文章，不是本文所需关注的重点，请允许我暂且略过。 这里，“清理房间”的步骤与Bootloader具体“弄脏了什么”（或者说使用了什么资源）有关；而“模拟处理器硬件的一些复位行为”就较为简单和具体：即，从Bootloader跳转到App前的最后两个步骤为： 从APP的向量表中读取MSP的初始值并以此来初始化MSP寄存器； 从APP的向量表中读取Reset_Handler的值，并跳转到其中去执行——完成从Bootloader到APP的权利交接。 结合前面的例子代码，值得我们关注的部分是： 1. 使用自定义的函数指针类型 pFunction 定义一个局部变量： pFunction Jump_To_Application; 2. 根据向量表的首地址 addr 读取第一个元素——作为MSP的初始值暂时保存在局部变量 StackAddr 中： StackAddr = *(__IO uint32_t*)addr; 3. 根据向量表的首地址 addr 读取第二个元素——将Reset_Handler的首地址保存到局部变量 ResetVector 中： ResetVector = *(__IO uint32_t *)(addr + 4); 4. 设置栈顶指针MSP寄存器： __set_MSP(StackAddr); 5. 通过函数指针完成从Bootloader到App的跳转： Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); 其实，无论具体的代码如何，只要实现步骤与上述类似，就存在一个隐藏较深的漏洞，而漏洞的“触发与否”则完全“看脸”——简单来说： 只要你是按照上述方法来实现从Bootloader到App的跳转的，那么就一定存在问题——而“似乎可以正常工作”就只是你运气较好，或者“由此引发的问题暂时未能引发注意”罢了。 在你试图争辩“老子代码已经量产了也没有什么不妥”之前，我们先来看看漏洞的原理是什么——在知其所以然后，如何评估风险就是你们自己的事情了。 【C语言基础设施是什么】 嵌入式系统的信息安全（Security）建立在基础设施安全（Safety）的基础之上。 由于“确保信息安全的很多机制”本质上是一套建立在“基础设施能够正常工作”这一前提之上的规则和逻辑，因此很多针对信息安全的攻击往往会绕开信息安全的“马奇诺防线”，转而攻击基础设施。芯片数字逻辑的基础设施是时钟源、供电、总线时序、复位时序等等，因此，针对硬件基础设施的攻击通常也就是针对时钟源、电源、总线时序和复位时序的攻击。此时，好奇的小伙伴会产生疑问：固件一般由C语言进行编写，那么C语言所依赖的基础设施又是什么呢？ 对C语言编译器来说，栈的作用是无可替代的： 函数调用 函数间的参数传递 分配局部变量 暂时保存通用寄存器中的内容 …… 可以说，离开了栈C语言寸步难行。因此对很多芯片来说，复位后为了执行用户使用C语言编译的代码，第一个步骤就是要实现栈的初始化。 作为一个有趣的“冷知识”，Cortex-M在宣传中一直强调自己“支持完全使用C语言进行开发”，这让很多人“丈二和尚摸不着头脑”甚至觉得“非常可笑”——因为这年月连51都支持用户使用C语言进行开发了，你这里说的“Cortex-M支持使用C语言进行开发”有什么意义呢？ 其实门道就在这里： 由于Cortex-M处理器会在复位时由硬件完成对C语言基础设施（也就是栈顶指针MSP）的初始化，因此无论是理论上还是实践中，从复位异常处理程序Reset_Handler开始用户就可以完全可以使用C语言进行开发了，而整个启动代码（startup）也可以全然不涉及任何汇编； 由于Cortex-M的向量表是一个完全由 32位整数（uintptr_t）构成的数组——保存的都是地址而非具体代码，可以使用C语言的数据结构直接进行描述——因此也完全不需要汇编语言的介入。 这种从复位一开始就完全不需要汇编介入的友好环境才是Cortex-M声称自己“支持完全使用C语言进行开发”的真实意义和底气。从这一角度出发，只要某个芯片架构复位后必须要通过软件来初始化栈顶指针，就不符合“从出生的那一刻就可以使用C语言”的基本要求。 【C语言编译器的约定】 栈对C语言来说如此重要，以至于编译器一直有一条默认的约定，即： 栈必须完全交由C语言编译器进行管理（或者用户对栈的操作必须符合对应平台所提供的调用规约，比如Arm的AAPCS规约）。 简而言之，如果你“偷偷摸摸”的修改了栈顶指针，C语言编译器是会“假装”完全不知道的，而此时所产生的后果C语言编译器会默认自己完全不用负责。 回头再看这段代码： StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); 虽然我们觉得自己“正大光明”的使用了 __set_MSP() 来修改了栈顶指针，但它实际上是一段C语言编译器并不理解其具体功能的在线汇编——在编译器看来，无论是谁提供的 __set_MSP()，只要是在线汇编，这就算是用户代码——是编译器管不到的地带。 /** \brief Set Priority Mask \details Assigns the given value to the Priority Mask Register. \param [in] priMask Priority Mask */__STATIC_FORCEINLINE void __set_PRIMASK(uint32_t priMask){ __ASM volatile ("MSR primask, %0" : : "r" (priMask) : "memory");} 或者说：C语言编译器一般情况下会默认你“无论如何都不会修改栈顶指针”——它不仅管不着，也不想管。 从这点来看，上述代码的确打破了这份约定。即便如此，很多小伙伴会心理倔强的认为：我就这么改了，怎么DE了吧？！ 【问题的分析】 从原理上说，开篇那个典型的Bootloader跳转代码所存在的问题已经昭然若揭： typedef void (*pFunction)(void); void JumpToApp(uint32_t addr){ pFunction Jump_To_Application; __IO uint32_t StackAddr; __IO uint32_t ResetVector; __IO uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 我们不妨结合上述代码反汇编的结果进行深入解析： AREA ||i.JumpToApp||, CODE, READONLY, ALIGN=2 JumpToApp PROC000000 b082 SUB sp,sp,#8000002 4909 LDR r1,|L2.40|000004 9100 STR r1,[sp,#0]000006 6802 LDR r2,[r0,#0]000008 400a ANDS r2,r2,r100000a 2101 MOVS r1,#100000c 0749 LSLS r1,r1,#2900000e 428a CMP r2,r1000010 d107 BNE |L2.34|000012 6801 LDR r1,[r0,#0]000014 9100 STR r1,[sp,#0]000016 6840 LDR r0,[r0,#4]000018 f3818808 MSR MSP,r100001c 9001 STR r0,[sp,#4]00001e b002 ADD sp,sp,#8000020 4700 BX r0 |L2.34|000022 b002 ADD sp,sp,#8000024 4770 BX lr ENDP 000026 0000 DCW 0x0000 |L2.40| DCD 0x2fff0000 注意这里，StackAddr、ResetVector是两个局部变量，由编译器在栈中进行分配。汇编指令将SP指针向栈底挪动8个字节就是这个意思： 000000 b082 SUB sp,sp,#8 虽然 JumpMask 也是局部变量，但编译器根据自己判断认为它“命不久矣”，因此直接将它分配到了通用寄存器r2中，并配合r1和sp完成了后续运算。这里： __IO uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { ... } 对应： 000002 4909 LDR r1,|L2.40|000004 9100 STR r1,[sp,#0]000006 6802 LDR r2,[r0,#0]000008 400a ANDS r2,r2,r100000a 2101 MOVS r1,#100000c 0749 LSLS r1,r1,#2900000e 428a CMP r2,r1000010 d107 BNE |L2.34|...|L2.34|000022 b002 ADD sp,sp,#8000024 4770 BX lrENDP 000026 0000 DCW 0x0000|L2.40|DCD 0x2fff0000 考虑到JumpMask的内容与本文无关，不妨暂且跳过。 接下来就是重头戏了： 编译器按照用户的指示读取栈顶指针MSP的初始值，并保存在StackAddr中： StackAddr = *(__IO uint32_t*)addr; 对应的汇编是： 000012 6801 LDR r1,[r0,#0]000014 9100 STR r1,[sp,#0] 根据Arm的AAPCS调用规约，编译器在调用函数时会使用R0~R3来传递前4个符合条件的参数（这里的条件可以简单理解为每个参数的宽度要小于等于32bit）。根据函数原型 void JumpToApp(uint32_t addr); 可知，r0 中保存的就是形参 addr 的值。所以第一句汇编的意思就是：根据 （addr + 0）作为地址读取一个uint32_t型的数据保存到r1中。 第二句汇编中，栈顶指针sp此时实际上指向局部变量 StackAddr，因此其含义就是将通用寄存器r1中的值保存到局部变量 StackAddr 中。 对于局部变量 ResetVector 的读取操作，编译器的处理如出一辙： ResetVector = *(__IO uint32_t *)(addr + 4); 对应： 000016 6840 LDR r0,[r0,#4]00001c 9001 STR r0,[sp,#4] 其实就是从 (addr + 4) 的位置读取 32bit 整数，然后保存到r0里，并随即保存到sp所指向的局部变量 ResetVector 中。到这里，细心地小伙伴会立即跳起来说“不对啊，原文不是这样的！”。是的，这也是最有趣的地方。实际的汇编原文如下： 000016 6840 LDR r0,[r0,#4]000018 f3818808 MSR MSP,r100001c 9001 STR r0,[sp,#4] 作为提醒，它对应的C代码如下： ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); 后面的 __set_MSP(StackAddr) 所对应的汇编代码 MSR MSR,r1 居然插入到了ResetVector赋值语句的中间？！ “C语言编译器这么自由的么？” “在我使用sp之前把栈顶指针更新了？！” 先别激动，还记得我们和C语言编译器之间的约定么？C语言编译器默认我们在任何时候都不应该修改栈顶指针。因此在他看来，“你 MSR 指令操作的是r1，关我sp和r0啥事”？“我就算随意更改顺序应该对你一毛钱影响都没有！（因为我不关心、也没法知道用户线汇编语句的具体效果，因此我只关心涉事的通用寄存器是否存在冲突）” 上述“骚操作”的后果是：保存在r0中的Reset_Handler地址值被保存到了新栈中（MSP + 4）的位置。这立即带来两个潜在后果： 由于MSP指向的是栈存储器的末尾（栈是从数值较大的地址向数值较小的地址生长），因此 (MSP+4）实际上已经超出栈的合法范围了。 这一操作与其说是会覆盖栈后续的存储空间，倒不如说风险主要体现在BusFault上——因为相当一部分人习惯将栈放到SRAM的最末尾，而MSP+4直接超出SRAM的有效范围。 我们以为的ResetVector其实已经不在原本C编译器所安排的地址上了。 精彩的还在后面： Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); 对应的翻译是： 00001e b002 ADD sp,sp,#8000020 4700 BX r0 通过前面的分析，我们知道，此时r0中保存的是Reset_Handler的地址，因此 BX r0 能够成功完成从Bootloader到APP的跳转——也许你会松一口气——好像局部变量ResetVector的错位也没引起严重的后果嘛。 看似如此，但真正吓人的是C语言编译器随后对局部变量的释放： 00001e b002 ADD sp,sp,#8 它与一开始局部变量的分配形成呼应： 000000 b082 SUB sp,sp,#8...00001e b002 ADD sp,sp,#8 好借好还，再借不难。但此sp非彼sp了呀！ 这里由于JumpToApp没有加上__NO_RETURN的修饰，因此C编译器并不知道这个函数是有去无回的，因此仍然会像往常一样在函数退出时释放局部变量。 就像刚才分析的那样：由于MSP指向的是栈存储器的末尾（栈是从数值较大的地址向数值较小的地址生长），因此 (MSP+8）实际上已经超出栈存储空间的合法范围了。 考虑到相当一部分人习惯将栈放到SRAM的最末尾，而MSP+8直接超出SRAM的有效范围，即便刚跳转到APP的时候还不会有事，但凡APP用了任何压栈操作，（无论是BusFault还是地址空间绕回）就很有可能产生灾难性的后果。 【宏观分析】 就事论事的讲，单从汇编分析来看，上述代码所产生的风险似乎是可控的，甚至某些人会觉得可以“忽略不计”。但最可怕的也就在这里，原因如下： 从原理上说，将关键信息保存在依赖栈的局部变量中，然后在编译器不知情的情况下替换了栈所在的位置，此后只要产生对相关局部变量的访问就有可能出现“刻舟求剑”的数据错误。这种问题是“系统性的”、“原理性的”。 （此图由GorgonMeducer借助GPT4进行一系列关键词调校、配上台词后获得） 不同编译器、同一编译器的不同版本、同一版本的不同优化选项都有可能对同一段C语言代码产生不同的编译结果，因此哪怕我们经过上述分析得出某一段汇编代码似乎不会产生特别严重的后果，在严谨的工程实践上，这也只能算做是“侥幸”，是埋下了一颗不知道什么时候以什么方式引爆的定时炸弹。 根据用户Bootloader代码在修改 MSP 前后对局部变量的使用情况不同、考虑到用户APP行为的不确定性、由上述缺陷代码所产生的Bootloader与APP之间配合问题的组合多种多样、由于涉及到用户栈顶指针位置的不确定性以及新的栈存储器空间中内容的随机性，最终体现出来的现象也是完全随机的。用人话说就是，经常性的“活见鬼” 【解决方案】 既然我们知道不能对上述缺陷代码抱有侥幸心理，该如何妥善解决呢？第一个思路：既然问题是由栈导致的，那么直接让编译器用通用寄存器来保存关键局部变量不就行了？修改代码为： typedef void (*pFunction)(void); void JumpToApp(uint32_t addr){ pFunction Jump_To_Application; register uint32_t StackAddr; register uint32_t ResetVector; register uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 相同编译环境下得出的结果为： AREA ||i.JumpToApp||, CODE, READONLY, ALIGN=2 JumpToApp PROC 000002 6801 LDR r1,[r0,#0]000004 4011 ANDS r1,r1,r2000006 2201 MOVS r2,#1000008 0752 LSLS r2,r2,#2900000a 4291 CMP r1,r200000c d104 BNE |L2.24| 00000e 6801 LDR r1,[r0,#0]000010 6840 LDR r0,[r0,#4]000012 f3818808 MSR MSP,r1 000016 4700 BX r0 |L2.24|000018 4770 BX lr ENDP 00001a 0000 DCW 0x0000 |L2.28| DCD 0x2fff0000 可见，上述汇编中半个 sp 的影子都没看到，问题算是得到了解决。 然而，需要注意的是 register 关键字对编译器来说只是一个“建议”，它听不听你的还不一定。加之上述例子代码本身相当简单，涉及到的局部变量数量有限，因此问题似乎得到了解决。 倘若编译器发现你大量使用 register 关键字导致实际可用的通用寄存器数量入不敷出，大概率还是会用栈来进行过渡的——此时，哪些局部变量用栈，哪些用通用寄存器就完全看编译器的心情了。 进一步的，不同编译器、不同版本、不同优化选项又会带来大量不可控的变数。 因此就算使用 register 修饰关键局部变量的方法可以救一时之疾（“只怪老板催我催得紧，莫怪我走后洪水滔天”），也算不得妥当。 第二个思路：既然问题出在局部变量上，我用静态（或者全局）变量不就可以了？修改源代码为： #include "cmsis_compiler.h" typedef void (*pFunction)(void); __NO_RETURNvoid JumpToApp(uint32_t addr){ pFunction Jump_To_Application; static uint32_t StackAddr; static uint32_t ResetVector; register uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 这种方法看似稳如老狗，实际效果可能也不差，但还是存在隐患，因为它“没有完全杜绝编译器会使用栈的情况”，只要我们还会通过 __set_MSP() 在C语言编译器不知道的情况下更新栈顶指针，风险自始至终都是存在的。 对某些连warning都要全数消灭的团队来说，上述方案多半也是不可容忍的。 第三个思路：完全用汇编来处理从Bootloader到App的最后步骤。对此我只想说：稳定可靠，正解。 只不过需要注意的是：这里整个函数都需要用纯汇编打造，而不只是在C函数内容使用在线汇编。 原因很简单：既然我们已经下定决心要追求极端确定性，就不应该使用线汇编这种与C语言存在某些“暧昧交互”的方式——因为它仍然会引入一些意想不到的不确定性。 本着一不做二不休的态度，完全使用汇编代码来编写跳转代码才是万全之策。 【说在后面的话】 在使用栈的情况下，on-fly 的修改栈顶指针就好比在飞行途中更换引擎——不是不行，只是要求有亿点点高。 我在微信群中帮读者分析各类Bootloader的见鬼故障时，经常在大费周章的一通分析和调试后，发现问题的罪魁祸首就是跳转代码。可怕的是，几乎每个故障的具体现象都各不相同，表现出的随机性也常常让人怀疑是不是硬件本身存在问题，亦或是产品工作现场的电磁环境较为恶劣。最要命的当数那种“偶尔出现”而复现条件颇为玄学的情形，甚至在办公室环境下完全无法重现的也大有人在。同样的问题出的多了，我几乎在每次帮人调试Bootloader时都会习惯性的先要求检查跳转代码——虽然不会每次都能猜个正着，但也有个恐怖的十之七八。这也许是某种幸存者偏差吧——毕竟大部分普通问题大家自己总能解决，到我这里的多半就是“驱鬼”了。见得多了，我突然发现，出问题的代码大多使用函数指针来实现跳转——而用局部变量来保存函数指针又成了大家自然而然的选择。加之此前很多文章都曾大规模科普上述技巧，甚至是直接包含一些存在缺陷的Bootloader范例代码，实际受影响的范围真是“细思恐极”。特此撰文，为您解惑。
扫码关注面包板社区
