51c嵌入式~单片机~合集3

我自己的原文哦~https://blog.51cto.com/whaosoft/12362395

一、STM32代码远程升级之IAP编程

IAP是什么

有时项目上需要远程升级单片机程序，此时需要接触到IAP编程。

IAP即为In Application Programming，解释为在应用中编程，用户自己的程序在运行过程中对User Flash的部分区域进行烧写。即是一种对单片机Flash擦写的一种编程方案。

通常情况下，一片STM32单片机的Flash只有一个用户程序，而IAP编程则是将单片机的Flash分成至少两大区域，一部分叫做bootloader区，一部分叫做app用户代码区，还可留出一部分区域为代码备份区。

IAP的应用场所

通常情况下我们给STM32单片机烧录更新程序时是通过SWD、J-link或者通过设置BOOT引脚后，使用串口进行程序下载，这样的方式直接一次性将程序文件下载到单片机的Flash中，比较适合绝大部分的应用。

但是当产品投入实际应用时，封装完成后在后期的使用过程中遇到某些程序上的bug或者是根据客户需求需要增加一些功能的时候，使用传统代码烧录的方法就可能需要拆除封装，而使用IAP编程在bootloader区提前写入与外部通信的接口用于升级单片机代码，使得我们不用对已完成包装的产品进行拆除既可以更新代码，这样既节约了成本，也更加方便快捷。

IAP编程的流程

IAP编程将Flash区分成的两个区域，bootloader区和app用户代码区具有截然不同的功能。相关文章推荐:详解STM32在线IAP升级。bootloader区，主要实现接收程序文件，并将该程序写于特定位置的Flash区域。而这里接收外部程序文件，就需要实时和外部通信了。

STM32单片机与外部通信大多是通过自身的串口接收和发送数据，不过STM32单片机的串口可以外接多种通讯接口，例如422、485、GPRS及ESP8266等。即我们可以通过串口外接蓝牙模块、WiFi模块或者是其他网络模块，就可以实现远程的文件传送更新单片机程序了。

app用户代码区则是主要实现我们所需要的功能操作，除此之外app用户代码区还需要实时检查代码运行情况，通过判断更新程序的标志位来判断是否需要升级程序。若是需要升级程序则进入bootloader区进行代码更新；若不需要则继续运行功能函数代码即可。

因此IAP编程下的单片机运行流程如下图：

根据运行流程，我们可以总结出简单几条bootloader设计过程中需要注意的地方：

• 精简、程序尽可能精简。在单片机Flash有限的情况下，bootloader代码占用Flash的空间越小，则APP程序代码就可占用更多，实现更多功能函数。
• 标志位不受复位的影响。
• Bootloader中尽量不使用中断。

二、详解STM32在线IAP升级

本文主要讲解在线升级IAP的基础知识, 主要是针对IAP 从原理分析, 分区划分, 到代码编写和实验验证等过程阐述这一过程. 帮助大家加深对在线升级的认识.

1. 在线升级知识

什么是BootLoader?

​​BootLoader​​可以理解成是引导程序, 它的作用是启动正式的​​App应用程序​​. 换言之, ​​BootLoader​​是一个程序, App也是一个程序, ​​BootLoader程序​​是用于启动​​App程序​​的.

STM32中的程序在哪儿?

正常情况下, 我们写的程序都是放在STM32片内Flash中(暂不考虑外扩Flash). 我们写的代码最终会变成二进制文件, 放进Flash中 感兴趣的话可以在​​Keil​​>>>​​Debug​​>>>​​Memory​​中查看, 右边Memory窗口存储的就是代码

接下来就可以进入正题了.

进行分区

既然我们写的程序都会变成二进制文件存放到Flash中, 那么我们就可以进一步对我们程序进行分区. 我使用的是​​F103RB-NUCLEO开发板​​,他的Flash一共128页, 每页1K.见下图:

以它为例, 我将它分为三个区.​​BootLoader区​​、 ​​App1区​​、 ​​App2区(备份区)​​具体划分如下图:

• ​BootLoader区​存放启动代码
• ​App1区​存放应用代码
• ​App2区​存放暂存的升级代码

总体流程图

• 先执行​BootLoader​程序, 先去检查​APP2​区有没有程序, 如果有就将App2区(备份区)的程序拷贝到​App1区​, 然后再跳转去执行​App1​的程序.
• 然后执行​App1​程序, 因为​BootLoader​和​App1​这两个程序的向量表不一样, 所以跳转到​App1​之后第一步是先去更改程序的向量表. 然后再去执行其他的应用程序.
• 在应用程序里面会加入程序升级的部分, 这部分主要工作是拿到升级程序, 然后将他们放到​App2区(备份区)​, 以便下次启动的时候通过​BootLoader​更新​App1​的程序. 流程图如下图所示:

2. BootLoader的编写

本节主要讲解在线升级(OTA)的​​BooLoader​​的编写，我将以我例程的BootLoader为例, 讲解​​BootLoader​​(文末会提供免费的代码下载链接)，其他的大体上原理都差不多。

流程图分析

以我例程的BootLoader为例：

我将​​App2区​​的最后一个字节(​​0x0801FFFC​​)用来表示​​App2区​​是否有升级程序, STM32在擦除之后Flash的数据存放的都是​​0xFFFFFFFF​​, 如果有, 我们将这个地址存放​​0xAAAAAAAA​​. 具体的流程图见下图所示

程序编写和分析

所需STM32的资源有:

• 发送USART数据和printf重定向

• Flash的读写

• 程序跳转指令,可以参考如下代码:

  1/* 采用汇编设置栈的值 /
  2__asm void MSR_MSP (uint32_t ulAddr)
  3{
  4 MSR MSP, r0 //设置Main Stack的值
  5 BX r14
  6}
  7
  8
  9/ 程序跳转函数 */
  10typedef void (*Jump_Fun)(void);
  11void IAP_ExecuteApp (uint32_t App_Addr)
  12{
  13 Jump_Fun JumpToApp;
  14
  15 if ( ( ( * ( __IO uint32_t * ) App_Addr ) & 0x2FFE0000 ) == 0x20000000 ) //检查栈顶地址是否合法.
  16 {
  17 JumpToApp = (Jump_Fun) * ( __IO uint32_t *)(App_Addr + 4); //用户代码区第二个字为程序开始地址(复位地址)
  18 MSR_MSP( * ( __IO uint32_t * ) App_Addr ); //初始化APP堆栈指针(用户代码区的第一个字用于存放栈顶地址)
  19 JumpToApp(); //跳转到APP.
  20 }
  21}

• 在需要跳转的地方执行这个函数就可以了​IAP_ExecuteApp(Application_1_Addr);​

• 其他的代码请参考​BootLoader​源代码

3. APP的编写

本节主要讲解在线升级(OTA)的​​App1​​的编写以及整个流程的说明，我将以我例程的App为例, 采用Ymodem协议进行串口传输,讲解​​App​​的编写(后面会提供免费的代码下载链接), 其他的协议原理大体上都差不多, 都是通过某种协议拿到升级的代码。

流程图分析

以我例程的App1为例：

• 先修改向量表, 因为本程序是由BootLoader跳转过来的, 不修改向量表后面会出现问题；
• 打印版本信息, 方便查看不同的App版本；
• 本例程的升级程序采用串口的Ymoderm协议进行传输bin文件. 具体的流程图见下图所示：

程序编写和分析

所需STM32的资源有:

• 发送USART数据和printf重定向
• Flash的读写
• 串口的DMA收发
• YModem协议相关

Ymodem协议

• 百度百科[Ymodem协议]
• 具体流程可自行查找相关文档, 这儿提供一个我找到的 XYmodem.pdf(文末和源码一起提供).
• Ymodem协议相关介绍可参考我的这篇教程 YModem介绍

(​​https://blog.csdn.net/weixin_41294615/article/details/104652105​​).

代码分析

• 代码大多数都是通过串口实现Ymodem协议的接收, 这儿就不详细说明
• 后面放了我的源代码, 详情请参考我的源代码.
• 主函数添加修改向量表的指令

• 打印版本信息以及跳转指令

• YModem相关的文件接收部分

  1/**
  2 * @bieaf YModem升级
  3 *
  4 * @param none
  5 * @return none
  6 /
  7void ymodem_fun(void)
  8{
  9 int i;
  10 if(Get_state()==TO_START)
  11 {
  12 send_command(CCC);
  13 HAL_Delay(1000);
  14 }
  15 if(Rx_Flag) // Receive flag
  16 {
  17 Rx_Flag=0; // clean flag
  18
  19 / 拷贝 /
  20 temp_len = Rx_Len;
  21 for(i = 0; i < temp_len; i++)
  22 {
  23 temp_buf[i] = Rx_Buf[i];
  24 }
  25
  26 switch(temp_buf[0])
  27 {
  28 case SOH:///<数据包开始
  29 {
  30 static unsigned char data_state = 0;
  31 static unsigned int app2_size = 0;
  32 if(Check_CRC(temp_buf, temp_len)==1)///< 通过CRC16校验
  33 {
  34 if((Get_state()==TO_START)&&(temp_buf[1] == 0x00)&&(temp_buf[2] == (unsigned char)(~temp_buf[1])))///< 开始
  35 {
  36 printf("> Receive start...\r\n");
  37
  38 Set_state(TO_RECEIVE_DATA);
  39 data_state = 0x01;
  40 send_command(ACK);
  41 send_command(CCC);
  42
  43 / 擦除App2 /
  44 Erase_page(Application_2_Addr, 40);
  45 }
  46 else if((Get_state()==TO_RECEIVE_END)&&(temp_buf[1] == 0x00)&&(temp_buf[2] == (unsigned char)(~temp_buf[1])))///< 结束
  47 {
  48 printf("> Receive end...\r\n");
  49
  50 Set_Update_Down();
  51 Set_state(TO_START);
  52 send_command(ACK);
  53 HAL_NVIC_SystemReset();
  54 }
  55 else if((Get_state()==TO_RECEIVE_DATA)&&(temp_buf[1] == data_state)&&(temp_buf[2] == (unsigned char)(~temp_buf[1])))///< 接收数据
  56 {
  57 printf("> Receive data bag:%d byte\r\n",data_state * 128);
  58
  59 / 烧录程序 */
  60 WriteFlash((Application_2_Addr + (data_state-1) * 128), (uint32_t *)(&temp_buf[3]), 32);
  61 data_state++;
  62
  63 send_command(ACK);
  64 }
  65 }
  66 else
  67 {
  68 printf("> Notpass crc\r\n");
  69 }
  70
  71 }break;
  72 case EOT://数据包开始
  73 {
  74 if(Get_state()==TO_RECEIVE_DATA)
  75 {
  76 printf("> Receive EOT1...\r\n");
  77
  78 Set_state(TO_RECEIVE_EOT2);
  79 send_command(NACK);
  80 }
  81 else if(Get_state()==TO_RECEIVE_EOT2)
  82 {
  83 printf("> Receive EOT2...\r\n");
  84
  85 Set_state(TO_RECEIVE_END);
  86 send_command(ACK);
  87 send_command(CCC);
  88 }
  89 else
  90 {
  91 printf("> Receive EOT, But error...\r\n");
  92 }
  93 }break;
  94 }
  95 }
  96}

• 其中部分函数未在以上代码中展现, 详情请参看文末给出的源码链接.

4. 整体测试

本节主要对前三节的教程做测试验证 ​​BootLoader​​ + ​​App​​的升级功能。

源代码

BootLoader源代码和App1源代码可以在原作者的gitee获取：

​​https://gitee.com/leafguo/leaf_notes/STM32CubeMX/STM32CubeMx_OTA​​

代码的下载

• 由下图可知两份代码的下载区域是不一样的，所以他们**「下载的区域也不一样」**。

BootLoader的下载

• BootLoader的代码默认是最开始的所以不需要特别设置代码的下载位置
• 按照下图, 修改擦除方式为​Erase Sectors​, 大小限制在​0X5000​(20K)

• 烧录代码
• 运行, 通过串口1打印输出, 会看到以下打印消息
• 说明BootLoader已经成功运行

App1的下载

• App1稍微复杂一点, 需要将代码的起始位置设置为​0x08005000​
• 同时也要修改擦除方式为​Erase Sectors​, 见下图

• 烧录代码
• 运行, 通过串口1打印输出, 会看到以下打印消息
• 说明​BootLoader​已经成功跳转到版本号为0.0.1的​App1​

生成App2的.bin文件

• Keil如何生成.bin文件, 请参考这篇博文 Keil如何生成.bin文件

​​https://blog.csdn.net/weixin_41294615/article/details/104656577​​

• 修改代码, 把版本号改为0.0.2, 并且编译并且生成.bin文件
• 生成好之后你会得到一个.bin结尾的文件, 这就是我们待会儿YModem要传输的文件

使用Xshell进行文件传输

• 打开Xshell
• 代码中, 串口1进行调试信息的打印, 串口2进行YModem升级的
• 所以使用Xshell打开串口2进行文件传输, 串口1则可以通过串口调试助手查看调试消息
• 你会看到App的版本成功升级到0.0.2了.
• 如果你到了这一步.
• 那么恭喜你! 你已经能够使用在线升级了!

5. 总结

通过本几节的教程, 想必你已经会使用在线升级了, 只要原理知道了其他的问题都可以迎刃而解了, 除了使用YModem协议传输.bin文件, 你还可以通过蓝牙, WIFI,等其他协议传输, 只要能够将.bin文件传输过去, 那其他的部分原理都差不多。

三、STM32单片机开发中的RTOS

很多STM32单片机初学者都是从裸机开始的，裸机确实也能开发出好的产品。但是，作为一个嵌入式软件工程师，况且用的并不是51那种低端单片机，如果只会用裸机开发产品，那肯定是不够的。

要从裸机的思维转变到RTOS（Real Time Operating System）的思维，其实需要一个过程，而且开始的一段时间会很痛苦。但过一段时间理解了一些内容，能写一些Demo之后，你会发现其实RTOS也不难，相关demo推荐:使用STM32CubeMx工具，写FreeRTOS的demo程序。

现在FreeRTOS在CubeMX工具中可以直接配置并使用，相当方便。

为什么需要RTOS

为什么我们需要RTOS？就像最开始学C编程时，老师告诉我们，指针很重要，那时你肯定有一个大的疑问，指针到底有什么好？

心里一直犯嘀咕着：不用指针不一样把程序编出来了？ 现在想想看C语言没了指针，是不是"寸步难行"呢。

回到正题，我们到底为什么需要RTOS？相关文章推荐:详解选择RTOS的要点。

一般的简单的嵌入式设备的编程思路是下面这样的：

这是最常见的一种思路，对于简单的系统当然是够用了，但这样的系统实时性很差。

比如"事务1"如果是一个用户输入的检测，当用户输入时，如果程序正在处理事务1下面的那些事务，那么这次用户输入将失效，用户的体验是"这个按键不灵敏，这个机器很慢"，而我们如果把事务放到中断里去处理，虽然改善了实时性但会导致另外一个问题，有可能会引发中断丢失，这个后果有时候比"慢一点"更加严重和恶劣！

又比如事务2是一个只需要1s钟处理一次的任务，那么显然事务2会白白浪费CPU的时间。

改进思路

看到上面裸机开发的局限了吗？

这时，我们可能需要改进我们的编程思路，一般我们会尝试采用"时间片"的方式。这时候编程会变成下面的方式：

可以看到，这种改进后的思路，使得事务的执行时间得到控制，事务只在自己的时间片到来后，才会去执行。但这种方式仍然不能彻底解决"实时性"的问题，因为某个事务的时间片到来后，也不能立即就执行，必须等到当前事务的时间片用完，并且后面的事务时间片没到来，才有机会获得"执行时间"。

这时候我们需要继续改进思路,为了使得某个事务的时间片到来后能立即执行，我们需要在时钟中断里判断完时间片后，改变程序的返回位置，让程序不返回到刚刚被打断的位置，而从最新获得了时间片的事务处开始执行，这样就彻底解决了事务的实时问题。

我们在这个思路上，进行改进，我们需要在每次进入时钟中断前，保存CPU的当前状态和当前事务用到的一些数据，然后我们进入时钟中断进行时间片处理，若发现有新的更紧急的事务的时间片到来了，则我们改变中断的返回的地址，并在CPU中恢复这个更紧急的事务的现场，然后返回中断开始执行这个更紧急的事务。

使用RTOS的好处

上面那段话，对于初学者来说，可能有些不好理解。

事实上，这是因为要实现这个过程是有些复杂和麻烦的，这时候我们就需要找一个操作系统(OS)帮我们做这些事了，如果你能自己用代码实现这个过程，事实上你就在自己写操作系统了。

其实从这里也可也看出，操作系统的原理其实并不那么神秘，只是一些细节你很难做好。我们常见的RTOS基本都是这样的一个操作系统，它能帮你完成这些事情，而且是很优雅的帮你完成！

事实上，RTOS的用处远不止帮你完成这个"事务时间片的处理"，它还能帮你处理各种超时，进行内存管理，完成任务间的通信等。

有了RTOS，程序的层次也更加清晰，给系统添加功能也更方便，这一切在大型项目中越发的明显！​

1 FreeRTOS

由于RTOS需占用一定的系统资源(尤其是RAM资源)，只有μC／OS-II、embOS、salvo、FreeRTOS等少数实时操作系统能在小RAM单片机上运行。

相对于C／OS-II、 embOS等商业操作系统，FreeRTOS操作系统是完全免费的操作系统，具有源码公开、可移植、可裁减、调度策略灵活的特点，可以方便地移植到各种单片机上运行，其最新版本为6.0版。

作为一个轻量级的操作系统，FreeRTOS提供的功能包括：任务管理、时间管理、信号量、消息队列、内存管理、记录功能等，可基本满足较小系统的需要。

FreeRTOS内核支持优先级调度算法，每个任务可根据重要程度的不同被赋予一定的优先级，CPU总是让处于就绪态的、优先级最高的任务先运行。

FreeRT0S内核同时支持轮换调度算法，系统允许不同的任务使用相同的优先级，在没有更高优先级任务就绪的情况下，同一优先级的任务共享CPU的使用时间。

FreeRTOS的不足：相对于常见的μC／OS---II操作系统，FreeRTOS操作系统既有优点也存在不足。其不足之处， 一方面体现在系统的服务功能上，如FreeRTOS只提供了消息队列和信号量的实现，无法以后进先出的顺序向消息队列发送消息；另一方 面，FreeRTOS只是一个操作系统内核，需外扩第三方的GUI(图形用户界面)、TCP／IP协议栈、FS(文件系统)等才能实现一个较复杂的系统， 不像μC／OS-II可以和μC／GUI、μC／FS、μC／TCP-IP等无缝结合。

在STM32CubeIDE中直接可以配置FreeRTOS，如上图。STM32使用FreeRTOS的相关文章，请移步此处:使用STM32CubeMx工具，写FreeRTOS的demo程序。

FreeRTOS资料多、生态活跃，在Cube中通过配置界面，三两下上手这款操作系统，推荐拿来入门。

基于不同的需求，下文再介绍下其他RTOS。

2 μClinux

μClinux是一种优秀的嵌入式Linux版本，其全称为micro-control Linux，从字面意思看是指微控制Linux。

同标准的Linux相比，μClinux的内核非常小，但是它仍然继承了Linux操作系统的主要特性，包括良好的稳定性和移植性、强大的网络功能、出色的文件系统支持、标准丰富的API，以及TCP／IP网络协议等。因为没有MMU内存管理单元，所以其多任务的实现需要一定技巧。

μClinux在结构上继承了标准Linux的多任务实现方式，分为实时进程和普通进程，分别采用先来先服务和时间片轮转调度，仅针对中低档嵌入式CPU特点进行改良，且不支持内核抢占，实时性一般。

综上可知，μClinux最大特点在于针对无MMU处理器设计，这对于没有MMU功能的STM32F103来说是合适的，但移植此系统需要至少512KB的RAM空间，1MB的ROM/FLASH空间，而STM32F103拥有256K的FLASH，需要外接存储器，这就增加了硬件设计的成本。

μClinux结构复杂，移植相对困难，内核也较大，其实时性也差一些，若开发的嵌入式产品注重文件系统和与网络应用则μClinux是一个不错的选择。

3 μC／OS-II

μC／OS-II是在μC/OS的基础上发展起来的，是用C语言编写的一个结构小巧、抢占式的多任务实时内核。μC／OS-II能管理64个任务，并提供任务调度与管理、内存管理、任务间同步与通信、时间管理和中断服务等功能，具有执行效率高、占用空间小、实时性能优良和扩展性强等特点。

在文件系统的支持方面，由于μC/OS-II是面向中小型嵌入式系统的，即使包含全部功能，编译后内核也不到10 KB，所以系统本身并没有提供对文件系统的支持。但是μC/OS-II具有良好的扩展性能，如果需要也可自行加入文件系统的内容。

在对硬件的支持上，μC/OS-II能够支持当前流行的大部分CPU，μC/OS-II由于本身内核就很小，经过裁剪后的代码最小可以为2KB，所需的最小数据RAM空间为4 KB，μC/OS-II的移植相对比较简单，只需要修改与处理器相关的代码就可以。

综上可知，μC/OS-II是一个结构简单、功能完备和实时性很强的嵌入式操作系统内核，针对于没有MMU功能的CPU，它是非常合适的。它需要很少的内核代码空间和数据存储空间，拥有良好的实时性，良好的可扩展性能，并且是开源的，网上拥有很多的资料和实例，所以很适合向STM32F103这款CPU上移植。

4 eCos

eCos(embedded Configurable operating system)，即嵌入式可配置操作系统。它是一个源代码开放的可配置、可移植、面向深度嵌入式应用的实时操作系统。

最大特点是配置灵活，采用模块化设计，核心部分由小同的组件构成，包括内核、C语言库和底层运行包等。

每个组件可提供大量的配置选项(实时内核也可作为可选配置)，使用eCos提供的配置工具可以很方便地配置，并通过不同的配置使得eCos能够满足不同的嵌入式应用要求。

eCos操作系统的可配置性非常强大，用户可以自己加入所需的文件系统。eCos操作系统同样支持当前流行的大部分嵌入式CPU，eCos操作系统可以在16位、32位和64位等不同体系结构之间移植。

eCos由于本身内核就很小，经过裁剪后的代码最小可以为10 KB，所需的最小数据RAM空间为10 KB。

在系统移植方面 eCos操作系统的可移植性很好，要比μC／OS-II和μClinux容易。

综上所述，eCos最大特点是配置灵活，并且支持无MMU的CPU的移植，开源且具有很好的移植性，也比较合适于移植到STM32平台的CPU上。但eCOS的应用还不是太广泛，还没有像μC／OS-II那样普遍，并且资料也没有μC／OS-II多。eCos适合用于一些商业级或工业级对成本敏感的嵌入式系统,例如消费电子领域中的一些应用。​

5 mbed OS

开源嵌入式操作系统，ARM公司将mbed OS免费提供给所有厂商使用，mbed提供了一个相对更加系统和更加全面的智能硬件开发环境。

主要功能：

提供用于开发物联网设备的通用操作系统基础，以解决嵌入式设计的碎片化问题。支持所有重要的连接性与设备管理开放标准，以实现面向未来的设计。使安全可升级的边缘设备支持新增处理能力与功能。通过自动电源管理解决复杂的能耗问题。

主要特点：

开发速度快，功能强大，安全性高，为了量产化而设计，可离线开发，也可以在网页上编辑。

6 RTX

是ARM公司的一款嵌入式实时操作系统，使用标准的C结构编写，运用RealView编译器进行编译。不仅仅是一个实时内核，还具备丰富的中间层组件，不但免费，而且代码也是开放的。

主要功能：

开始和停止任务（进程），除此之外还支持进程通信，例如任务的同步、共享资源（外设或内存）的管理、任务之间消息的传递。开发者可以使用基本函数去开启实时运行器，去开始和终结任务，以及去传递任务间的控制（轮转调度）。开发者可以赋予任务优先级。

主要特点：

支持时间片，抢占式和合作式调度。不限制数量的任务，每个任务都具有254的优先级。不限制数量的信号量，互斥信号量，消息邮箱和软定时器。支持多线程和线程安全操作。使用MDK基于对话框的配置向导，可以很方便的完成MDK的配置。​

7 都江堰

都江堰操作系统，简称djyos，得名于一个伟大的水利工程：都江堰。

与传统操作系统不同，djyos不是以线程而是以事件为调度核心，这种调度算法使程序员摆脱模拟计算机执行过程编写程序的思维方式，而是按人类认知世界的方式编写应用程序，就如同在嵌入式编程中引入了VC似的。

djyos的调度算法使程序员可以摆脱线程和进程的束缚，djyos没有有关线程的api，一个完全不懂线程知识的程序员也可以顺利地在djyos下编写应用程序。

djyos 操作系统是以事件为核心进行调度的，这种调度策略使程序员可以按人类认知事物的习惯而不是计算机的习惯来编程。

8 RT-Thread

嵌入式操作系统RTOS介绍，RT-Thread是一个集实时操作系统（RTOS）内核、中间件组件和开发者社区于一体的技术平台，由熊谱翔先生带领并集合开源社区力量开发而成，RT-Thread也是一个组件完整丰富、高度可伸缩、简易开发、超低功耗、高安全性的物联网操作系统。

RT-Thread具备一个IoT OS平台所需的所有关键组件，例如GUI、网络协议栈、安全传输、低功耗组件等等。经过11年的累积发展，RT-Thread已经拥有一个国内最大的嵌入式开源社区，同时被广泛应用于能源、车载、医疗、消费电子等多个行业，累积装机量超过两千万台，成为国人自主开发、国内最成熟稳定和装机量最大的开源RTOS。

国内最有可能成为Top 1，优势在于丰富的组件，中立立场！赶上了时机，得到诸多芯片厂商的支持，也挺受开发者喜欢的。缺点在于本身的教程文档和freertos等之类的比还是很弱。

四、嵌入式裸机环形队列与RTOS消息队列

"环形队列"和"消息队列"在嵌入式领域有应用非常广泛，相信有经验的嵌入式软件工程师对它们都不陌生。

但经常看到一些初学者问一些相关的问题，今天就来分享一下关于"环形队列"和"消息队列"的内容。

一、环形队列

环形队列是在实际编程极为有用的数据结构，它是一个首尾相连的FIFO的数据结构，采用数组的线性空间，数据组织简单，能很快知道队列是否满为空，能以很快速度的来存取数据。

环形队列通常用于通信领域，比如UART、USB、CAN、网络等。

1 环形队列实现原理

内存上没有环形的结构，因此环形队列实上是数组的线性空间来实现。当数据到了尾部它将转回到0位置来处理。

因此环列队列的逻辑：将数组元素q[0]与q[MAXN-1]连接，形成一个存放队列的环形空间。

为了方便读写，还要用数组下标来指明队列的读写位置。head/tail.其中head指向可以读的位置，tail指向可以写的位置。

环形队列的关键是判断队列为空，还是为满。当tail追上head时，队列为满时；当head追上tail时，队列为空。但如何知道谁追上谁，还需要一些辅助的手段来判断.

如何判断环形队列为空，为满有两种判断方法：

a.附加一个标志位tag

• 当head赶上tail，队列空，则令tag=0
• 当tail赶上head，队列满，则令tag=1

b.限制tail赶上head，即队尾结点与队首结点之间至少留有一个元素的空间。

• 队列空： head==tail
• 队列满： (tail+1)% MAXN ==head

2 附加标志实现原理

a.采用第一个环形队列有如下结构:

初始化状态：

q->head = q->tail = q->tag = 0;

队列为空：

( q->head == q->tail) && (q->tag == 0)

队列为满 ：

((q->head == q->tail) && (q->tag == 1))

入队操作，如队列不满，则写入：

q->tail =  (q->tail + 1) % q->size ;

出队操作，如果队列不空，则从head处读出。

下一个可读的位置在：

q->head =  (q->head + 1) % q->size

b.完整代码

头文件ringq.h:

#ifndef __RINGQ_H__
#define __RINGQ_H__


#ifdef __cplusplus
extern "C" {
#endif 


#define QUEUE_MAX 20


typedef struct ringq{
   int head; /* 头部，出队列方向*/
   int tail; /* 尾部，入队列方向*/ 
   int tag ; /* 为空还是为满的标志位*/
    int size ; /* 队列总尺寸 */
   int space[QUEUE_MAX]; /* 队列空间 */
}RINGQ;


/* 
  第一种设计方法:
     当head == tail 时，tag = 0 为空，等于 = 1 为满。
*/


extern int ringq_init(RINGQ * p_queue);


extern int ringq_free(RINGQ * p_queue);




/* 加入数据到队列 */
extern int ringq_push(RINGQ * p_queue,int data);


/* 从队列取数据 */
extern int ringq_poll(RINGQ * p_queue,int *p_data);




#define ringq_is_empty(q) ( (q->head == q->tail) && (q->tag == 0))


#define ringq_is_full(q) ( (q->head == q->tail) && (q->tag == 1))


#define print_ringq(q) printf("ring head %d,tail %d,tag %d\n", q->head,q->tail,q->tag);
#ifdef __cplusplus
}
#endif 


#endif /* __RINGQ_H__ */

源代码 ringq.c：​

#include <stdio.h>
#include "ringq.h"


int ringq_init(RINGQ * p_queue)
{
   p_queue->size = QUEUE_MAX ;


   p_queue->head = 0;
   p_queue->tail = 0;


   p_queue->tag = 0;


   return 0;
}


int ringq_free(RINGQ * p_queue)
{
  return 0;
}




int ringq_push(RINGQ * p_queue,int data)
{
  print_ringq(p_queue);


  if(ringq_is_full(p_queue))
   {


     printf("ringq is full\n");
     return -1;
   }


   p_queue->space[p_queue->tail] = data;


   p_queue->tail = (p_queue->tail + 1) % p_queue->size ;


   /* 这个时候一定队列满了*/
   if(p_queue->tail == p_queue->head)
    {
       p_queue->tag = 1;
    }


    return p_queue->tag ;  
}


int ringq_poll(RINGQ * p_queue,int * p_data)
{
   print_ringq(p_queue);
  if(ringq_is_empty(p_queue))
   {


      printf("ringq is empty\n");
     return -1;
   }


   *p_data = p_queue->space[p_queue->head];


   p_queue->head = (p_queue->head + 1) % p_queue->size ;


    /* 这个时候一定队列空了*/
   if(p_queue->tail == p_queue->head)
    {
       p_queue->tag = 0;
    }    
    return p_queue->tag ;
}

看到源代码，相信大家就明白其中原理了。其实还有不采用tag，或者其他一些标志的方法，这里就不进一步展开讲述了，感兴趣的读者可以自行研究一下。

二、消息队列

在RTOS中基本都有消息队列这个组件，也是使用最常见的组件之一。

1 消息队列的基本概念

消息队列是一种常用于任务间通信的数据结构，队列可以在任务与任务间、中断和任务间传递信息，实现了任务接收来自其他任务或中断的不固定长度的消息。

通过消息队列服务，任务或中断服务程序可以将一条或多条消息放入消息队列中。同样，一个或多个任务可以从消息队列中获得消息。

使用消息队列数据结构可以实现任务异步通信工作。

2 消息队列的特性

RTOS消息队列，常见特性：

• 消息支持先进先出方式排队，支持异步读写工作方式。
• 读写队列均支持超时机制。
• 消息支持后进先出方式排队，往队首发送消息（LIFO）。
• 可以允许不同长度（不超过队列节点最大值）的任意类型消息。
• 一个任务能够从任意一个消息队列接收和发送消息。
• 多个任务能够从同一个消息队列接收和发送消息。
• 当队列使用结束后，可以通过删除队列函数进行删除。

3 消息队列的原理

这里以 FreeRTOS 为例进行说明。FreeRTOS 的消息队列控制块由多个元素组成，当消息队列被创建时，系统会为控制块分配对应的内存空间，用于保存消息队列的一些信息如消息的存储位置，头指针 pcHead、尾指针 pcTail、消息大小 uxItemSize 以及队列长度 uxLength 等。

比如创建消息队列：

xQueue = xQueueCreate(QUEUE_LEN, QUEUE_SIZE);

任务或者中断服务程序都可以给消息队列发送消息，当发送消息时，如果队列未满或者允许覆盖入队，FreeRTOS 会将消息拷贝到消息队列队尾，否则，会根据用户指定的阻塞超时时间进行阻塞，在这段时间中，如果队列一直不允许入队，该任务将保持阻塞状态以等待队列允许入队。当其它任务从其等待的队列中读取入了数据（队列未满），该任务将自动由阻塞态转移为就绪态。当等待的时间超过了指定的阻塞时间，即使队列中还不允许入队，任务也会自动从阻塞态转移为就绪态，此时发送消息的任务或者中断程序会收到一个错误码 errQUEUE_FULL。

发送紧急消息的过程与发送消息几乎一样，唯一的不同是，当发送紧急消息时， 发送的位置是消息队列队头而非队尾，这样，接收者就能够优先接收到紧急消息，从而及时进行消息处理。

当某个任务试图读一个队列时，其可以指定一个阻塞超时时间。在这段时间中，如果队列为空，该任务将保持阻塞状态以等待队列数据有效。当其它任务或中断服务程序往其等待的队列中写入了数据，该任务将自动由阻塞态转移为就绪态。当等待的时间超过了指定的阻塞时间，即使队列中尚无有效数据，任务也会自动从阻塞态转移为就绪态。

当消息队列不再被使用时，应该删除它以释放系统资源，一旦操作完成， 消息队列将被永久性的删除。

消息队列的运作过程具体见下图：

4 消息队列的阻塞机制

出队阻塞：当且仅当消息队列有数据的时候，任务才能读取到数据，可以指定等待数据的阻塞时间。

入队阻塞：当且仅当队列允许入队的时候，发送者才能成功发送消息；队列中无可用消息空间时，说明消息队列已满，此时，系统会根据用户指定的阻塞超时时间将任务阻塞。

假如有多个任务阻塞在一个消息队列中，那么这些阻塞的任务将按照任务优先级进行排序，优先级高的任务将优先获得队列的访问权。

三、环形队列与消息队列的异同

通过以上分析，你会发现"环形队列"和"消息队列"之间有很多共同点：

1.他们都是一种数据结构，结构中都包含头、尾、标志等信息；

2.它们都是分配一块连续的内存空间，且都可以分配多个队列。

3.应用场景类似，有大量吞吐数据的情况下，比如通信领域。

...

当然，他们也有一些不同点：

1."环形队列"可以独立使用，也可以结合操作系统使用。而消息队列依赖RTOS（有些RTOS的参数信息）。

2."环形队列"占用资源更小，更适合于资源较小的系统中。

3."消息队列"结合RTOS应用更加灵活，比如延时、中断传输数据等。

...

最后，这两种队列应用都比较广，建议抽空都研究一下。

五、固件升级防变砖的方法

汽车软件Boot程序的主要作用是刷新App程序。在一个具体客户项目中，Boot也是客户需求的一部分，跟随项目也有软件开发计划（有的为了和其它Boot区分，把项目上的Boot称作CB, Customer Boot）。

对于已经下线盒盖的控制器，无论是在供应商或者客户手里测试，只能通过CB刷新App。如果需要CB自刷新，就需要额外的方法。

整车厂只有对App程序刷新的规范，没有对Boot自刷新的规范。因为规范是针对量产车的，售后只负责App程序的升级，不对Boot升级（也不允许Boot升级）。

所以，Boot的自刷新只存在于项目开发阶段，且由供应商自行提供方案。本文分析五种Boot自更新方式的优缺点。

1 方式一，SB更新CB：

如图1-a，有的软件架构是两级Boot：SB+CB，Start Boot只检查CPU最小系统，与具体项目的外围电路无关，它独立于客户需求，由供应商自行维护，在Pilot项目早期就应开发完成。

因为程序启动顺序是SB->CB->App,这样在SB里增加刷新逻辑可以更新CB。通常情况下运行CB更新App程序，特殊情况下程序启动后一直停留在SB里，更新CB。

优点：

逻辑结构简单清晰，软件分工明确。

2.一次刷新，操作简易。

缺点：

1.需要较大的Flash空间在SB里存放刷新逻辑，项目SOP后又要禁止这种刷新方式，造成额外的浪费。

2.软件分三级启动，结构复杂，开发和维护成本较高。对于不需要SB的控制器是一种负担。

3.万一SB也需要更新怎么办？按照这种策略，还得做个SSB？显然不现实。

方式二、RAM+Flash Reboot更新

如图2-a，不存在SB情况下，程序启动顺序是CB->App。需要刷新Boot时，首先把Reboot程序下载到不用的RAM里（图2-b），然后在RAM环境下运行ReBoot,下载新的CB（图2-c）

优点：

不需要额外的Flash空间，Boot程序运行只需要少量的RAM，因此为App设计的RAM临时可以保存Reboot程序。

RAM擦写速度很快，则下载ReBoot的速度会很快。

缺点：

在CB更新过程中万一CPU掉电，重新上电后Reboot内容全无，CB已经破损，程序不能正常启动，控制器瘫痪，只能开盖用JTAG烧写程序。

方式三、RAM+RAM ReBoot更新（对方式二的改进）

首先把ReBoot（蓝色）+NewCB（紫色）一起都下载到RAM里（图3-a），然后运行ReBoot,擦除CB Flash区域，将RAM中NewCB复制到CB Flash区域（这一步内部完成）。

最后，重新上电复位，RAM中的ReBoot和NewCB自动丢失，程序从新的CB开始运行。

优点：

相比方式二少了一步刷新（因为ReBoot和CB是绑在一起的）。

相比方式二CB更新全部在CPU内部执行，不受外界干扰，耗时更短

缺点：

相比方式二需要更大的RAM空间存储ReBoot+NewCB。

和方式二一样存在CB更新阶段掉电后控制器瘫痪的风险 。

方式四、借助App程序Flash空间

刷新分三步：1.图4-b运行CB，擦除App，把ReBoot下载到App区域。2.图4-c运行ReBoot,擦除旧CB，刷入新CB。3.图4-d运行新CB，刷回App。

优点：

不需要额外的Flash和RAM资源。

稳定可靠，通过优化设计，可以保证在任何一个步骤突然掉电，上电后可以继续操作，控制器不会刷死。（详细设计方法请看附录）

对CB做稍微改造就可以成为Reboot程序，开发快速。

缺点：

步骤繁多，为了更新CB必须要先擦除App，最后恢复App，至少三次刷新。对不熟悉步骤的操作者容易搞混乱。

整体刷新时间会较长，两次Boot+一次App

方式五、借助额外Flash空间

相比方式四，需要一块和CB一样大小的额外Flash空间，刷新分三步：

图5-b,运行CB，刷入ReBoot到额外Flash。

图5-c,运行ReBoot，更新CB。

运行新的CB，破坏ReBoot（全部擦除，或只擦除ReBoot有效性标志）

优点：相比方式四，不需要破坏App程序，也省去了这部分更新时间。

缺点：相比方式四，需要额外的Flash空间，且必须是独立的Block。

小结：

本质上只有三种：

依赖启动程序SB（方式一），当CPU的Flash资源很富余且项目需要两级Boot时，用该方法最节省时间。

借助RAM（方式二、三）3.借助Flash（方式四、五）。只需要单级Boot（CB）时，可以容忍因Boot刷新瘫痪必须要给控制器开盖带来时间，人力，物力的成本损耗的情况下用方式二，三较方便。

只需要单级Boot（CB）时，不允许或不方便控制器开盖，但可以容忍Boot更新步骤繁多时间较长的情况下用方式四、五最可靠。

综上，工程师需要根据整体软件架构，CPU资源，时间人力物料等成本因素综合考虑一种适合自己产品及项目的Boot自刷新方法。

附录：

《Boot自刷新方式四（借助Flash）的具体实现方法》

背景：

对于方式四借助Flash刷新【不存在刷死风险，在任何一个步骤中控制器突然掉电，上电后可以继续操作。】的结论，是有条件的。笔者给出这个结论是从最理想的前提思考的，即只要控制器中至少有一个Boot存在（即使一个是坏的），程序就可以从任何一正常的Boot启动运行。这里就有一个问题，CPU怎么判断哪个Boot是好的，哪个是坏的？现在分析一下存在控制器刷死这种风险的情况和几种对策方案。

两级启动地址介绍：

如下图示，CPU上电后程序按地址顺序，检查BootSector的有效性，如果BOOT_ID合法则从指定的地址开始执行，否则检查下一个BootSector。

考虑CPU至少具备两个启动地址的情况，如图1-a,当且仅当启动地址1有效时（App为空），程序启动后自动进入Boot。如图1-b,当且仅当启动地址2有效时（不带Boot测试），程序启动后自动进入App。

如图1-c，当启动地址1，2都有效势，程序优先从地址1启动，在Boot里检查App程序有效时，再靠跳转指令Jump到启动地址2，开始运行App。

方式四控制器刷死情况分析：

如图 2-a，运行Reboot更新CB途中断电。重新上电后，如图2-b，由于启动地址1的内容是在刷新开始就被更新了是有效的，程序会进入CB运行，但是CB不完整，必然运行出错，程序不会跳入ReBoot里，从而不能再刷新（即刷死）。

假设从擦除完旧CB开始到刷入新CB完成的时间有10S，在此期间掉电的可能性也不能忽略。

对策一、Boot有效性标志与启动地址重合

考虑最普遍情况，CPU只能整块（Block）的擦出（16K,32K,64K...），可以最少4字节单位写，没有顺序限制，现在CB只用了一个Block。

现在调整刷新顺序：擦出成功后，先刷新橙色区域，最后一步刷新启动地址1有效性标志（灰色区域）。这样，即使在更新橙色区域过程中掉电。

重新上电后，程序依然从启动地址2开始运行，即重新运行Reboot继续等待刷新CB指令，如图3-a所示。

具体操作时也不需要更改下载流程，使用$34,36服务按顺序从上位机传输数据到CPU中，先把启动地址1的有效性标志放到RAM里，

当把橙色区域都下载到Flash后，再从RAM里把启动地址1的有效性标志写到Flash里（这一步10ms以内即可完成，完全可以忽略在此时间内掉电的可能性）

如果最后一步启动地址1刷新成功，再重新上电后，程序从启动地址1开始运行新的Boot。即启动地址1起了Boot有效性标志的作用（最先擦，最后写），如图3-b所示。

对策二、Boot有效性标志独立置尾，增加Boot有效性检查逻辑

如图4-a,把Boot分成2个段，Sec1里仅存放少量的启动自检查逻辑，当它检测到置于Sec2末尾的CB_ValidFlg无效时，即认为Boot是不完整的，则程序控制跳转到启动地址2继续运行ReBoot，重新刷新Boot。

如图4-b,当Sec1的逻辑检测到CB_ValidFlg有效时，即认为Boot刷新完成，则程序控制跳转入Sec2里，此时由于App(ReBoot)末尾的App_ValidFlg是无效的，程序并不会跳转入ReBoot里，接下来就可以刷入新的App了。

这种方法只需要对CB的逻辑和段分配做一下调整，不需要更改刷新顺序。Sec1里的启动自检查逻辑可以做的尽量小，则只要保证刷新Sec1段的过程中不掉电，控制器就不会刷死，大大降低风险。

但是对量产软件，检查CB_ValidFlg无效就直接跳转入App是不合理的，所以当Boot最终定型后，应该把这个跳转逻辑关闭。

小结：对策一简单可靠，经过实际测试验证，完全可以满足稳定刷新ECU的要求。

六、单片机如何工作的

单片机内部结构分析

我们来思考一个问题，当我们在编程器中把一条指令写进单片机内部，然后取下单片机，单片机就可以执行这条指令，那么这条指令一定保存在单片机的某个地方，并且这个地方在单片机掉电后依然可以保持这条指令不会丢失，这是个什么地方呢？这个地方就是单片机内部的只读存储器即ROM（READ ONLY MEMORY）。为什么称它为只读存储器呢？刚才我们不是明明把两个数字写进去了吗？

原来在89C51中的ROM是一种电可擦除的ROM，称为FLASH ROM，刚才我们是用的编程器，在特殊的条件下由外部设备对ROM进行写的操作，在单片机正常工作条件下，只能从那面读，不能把数据写进去，所以我们还是把它称为ROM。

几个基本概念

1 数的本质和物理现象

我们知道，计算机可以进行数学运算，这令我们非常难以理解，计算机吗，我们虽不了解它的组成，但它们只是一些电子元器件，怎么可以进行数学运算呢？我们做数学题如37+45是这样做的，先在纸上写37，然后在下面写45，然后大脑运算，最后写出结果，运算的原材料：37、45和结果：82都是写在纸上的，计算机中又是放在什么地方呢？相关推荐：单片机中的RAM vs ROM。

为了解决这个问题，先让我们做一个实验：这里有一盏灯，我们知道灯要么亮，要么不亮，就有两种状态，我们可以用'0'和'1'来代替这两种状态，规定亮为'1'，不亮为'0'。现在放上两盏灯，一共有几种状态呢？我们列表来看一下：

请大家自己写上3盏灯的情况000 001 010 011 100 101 110 111我们来看，这个000，001，101 不就是我们学过的的二进制数吗？本来，灯的亮和灭只是一种物理现象，可当我们把它们按一定的顺序排好后，灯的亮和灭就代表了数字了。让我们再抽象一步，灯为什么会亮呢？是因为输出电路输出高电平，给灯通了电。因此，灯亮和灭就可以用电路的输出是高电平还是低电平来替代了。这样，数字就和电平的高、低联系上了。（请想一下，我们还看到过什么样的类似的例子呢？（海军之）灯语、旗语，电报，甚至红、绿灯）。

2 位的含义

通过上面的实验我们已经知道：一盏灯亮或者说一根线的电平的高低，可以代表两种状态：0和1。实际上这就是一个二进制位，因此我们就把一根线称之为一"位"，用BIT表示。

3 字节的含义

一根线可以表示0和1，两根线可以表达00，01，10，11四种状态，也就是可以表达0到3，而三根可以表达0~7，计算机中通常用8根线放在一起，同时计数，就可以表示0-255一共256种状态。这8根线或者8位就称之为一个字节（BYTE）。

存储器的工作原理

1 存储器构造

存储器就是用来存放数据的地方。它是利用电平的高低来存放数据的，也就是说，它存放的实际上是电平的高、低，而不是我们所习惯认为的1234这样的数字，这样，我们的一个谜团就解开了，计算机也没什么神秘的吗。相关推荐：CPU怎么识别我们写的代码？如上图左所示：一个存储器就象一个个的小抽屉，一个小抽屉里有八个小格子，每个小格子就是用来存放"电荷"的，电荷通过与它相连的电线传进来或释放掉。

至于电荷在小格子里是怎样存的，就不用我们操心了，你可以把电线想象成水管，小格子里的电荷就象是水，那就好理解了。存储器中的每个小抽屉就是一个放数据的地方，我们称之为一个"单元"。

有了这么一个构造，我们就可以开始存放数据了，想要放进一个数据12，也就是00001100，我们只要把第二号和第三号小格子里存满电荷，而其它小格子里的电荷给放掉就行了（看上图右）。可是问题出来了，看上图右，一个存储器有好多单元，线是并联的，在放入电荷的时候，会将电荷放入所有的单元中，而释放电荷的时候，会把每个单元中的电荷都放掉，这样的话，不管存储器有多少个单元，都只能放同一个数，这当然不是我们所希望的，因此，要在结构上稍作变化，看上图右，在每个单元上有个控制线，我想要把数据放进哪个单元，就把一个信号给这个单元的控制线，这个控制线就把开关打开，这样电荷就可以自由流动了，而其它单元控制线上没有信号，所以开关不打开，不会受到影响，这样，只要控制不同单元的控制线，就可以向各单元写入不同的数据了，同样，如果要从某个单元中取数据，也只要打开相应的控制开关就行了。

2 存储器译码

那么，我们怎样来控制各个单元的控制线呢？这个还不简单，把每个单元的控制线都引到集成电路的外面不就行了吗？事情可没那么简单，一片27512存储器中有65536个单元，把每根线都引出来，这个集成电路就得有6万多个脚？不行，怎么办？要想法减少线的数量。我们有一种方法称这为译码，简单介绍一下：一根线可以代表2种状态，2根线可以代表4种状态，3根线可以代表几种，256种状态又需要几根线代表？8种，8根线，所以65536种状态我们只需要16根线就可以代表了。

3 存储器的选片及总线的概念

至此，译码的问题解决了，让我们再来关注另外一个问题。送入每个单元的八根线是用从什么地方来的呢？它就是从计算机上接过来的，一般地，这八根线除了接一个存储器之外，还要接其它的器件。这样问题就出来了，这八根线既然不是存储器和计算机之间专用的，如果总是将某个单元接在这八根线上，就不好了，比如这个存储器单元中的数值是0FFH另一个存储器的单元是00H，那么这根线到底是处于高电平，还是低电平？岂非要打架看谁历害了？

所以我们要让它们分离。办法当然很简单，当外面的线接到集成电路的引脚进来后，不直接接到各单元去，中间再加一组开关就行了。平时我们让开关打开着，如果确实是要向这个存储器中写入数据，或要从存储器中读出数据，再让开关接通就行了。这组开关由三根引线选择：读控制端、写控制端和片选端。

要将数据写入片中，先选中该片，然后发出写信号，开关就合上了，并将传过来的数据（电荷）写入片中。如果要读，先选中该片，然后发出读信号，开关合上，数据就被送出去了。读和写信号同时还接入到另一个存储器，但是由于片选端不同，所以虽有读或写信号，但没有片选信号，所以另一个存储器不会"误会"而开门，造成冲突。那么会不同时选中两片芯片呢？只要是设计好的系统就不会，因为它是由计算控制的，而不是我们人来控制的，如果真的出现同时出现选中两片的情况，那就是电路出了故障了，这不在我们的讨论之列。

从上面的介绍中我们已经看到，用来传递数据的八根线并不是专用的，而是很多器件大家共用的，所以我们称之为数据总线，总线英文名为BUS，总即公交车道，谁也可以走。而十六根地址线也是连在一起的，称之为地址总线。

七、主流单片机的优缺点

单片机现在可谓是铺天盖地，种类繁多，让开发者们应接不暇，发展也是相当的迅速，从上世纪80年代，由当时的4位8位发展到现在的各种高速单片机。

各个厂商们也在速度、内存、功能上此起彼伏，参差不齐。同时涌现出一大批拥有代表性单片机的厂商：Atmel、TI、ST、MicroChip、ARM...... 除此之外国内厂商的STC单片机也是可圈可点。

下面为大家带来51、MSP430、STM32、TMS、PIC、AVR、STC单片机之间的优缺点比较及功能体现。

51单片机

应用最广泛的8位单片机当然也是初学者们最容易上手学习的单片机，最早由Intel推出，由于其典型的结构和完善的总线专用寄存器的集中管理，众多的逻辑位操作功能及面向控制的丰富的指令系统，堪称为一代"经典"，为以后的其它单片机的发展奠定了基础。目前在教学场合和对性能要求不高的场合大量被采用。

特点

​​51单片​​机之所以成为经典，成为易上手的单片机主要有以下特点：

• 从内部的硬件到软件有一套完整的按位操作系统，称作位处理器，处理对象不是字或字节而是位。不但能对片内某些特殊功能寄存器的某位进行处理，如传送、置位、清零、测试等，还能进行位的逻辑运算，其功能十分完备，使用起来得心应手。
• 同时在片内RAM区间还特别开辟了一个双重功能的地址区间，使用极为灵活，这一功能无疑给使用者提供了极大的方便。
• 乘法和除法指令，这给编程也带来了便利。很多的八位单片机都不具备乘法功能，做乘法时还得编上一段子程序调用，十分不便。

缺点

51单片机虽然是经典但是缺点还是很明显的：

• AD、EEPROM等功能需要靠扩展，增加了硬件和软件负担。
• 虽然I/O脚使用简单，但高电平时无输出能力，这也是51系列单片机的最大软肋。
• 运行速度过慢，特别是双数据指针，如能改进能给编程带来很大的便利。
• 51保护能力很差，很容易烧坏芯片。

MSP430单片机

MSP430系列单片机是1996年开始推向市场的一种16位超低功耗的混合信号处理器，给人们留下的最大的亮点是低功耗而且速度快，汇编语言用起来很灵活，寻址方式很多，指令很少，容易上手。主要是由于其针对实际应用需求，把许多模拟电路、数字电路和微处理器集成在一个芯片上，以提供"单片"解决方案。在低功耗及超低功耗的工业场合应用的比较多。

特点

MSP430单片机其迅速发展和应用范围的不断扩大，主要取决于以下的特点。

• 强大的处理能力，采用了精简指令集(RISC)结构，具有丰富的寻址方式( 7 种源操作数寻址、 4 种目的操作数寻址)、简洁的 27 条内核指令以及大量的模拟指令；大量的寄存器以及片内数据存储器都可参加多种运算；还有高效的查表处理指令；有较高的处理速度，在 8MHz 晶体驱动下指令周期为 125 ns 。这些特点保证了可编制出高效率的源程序。
• 在运算速度方面，能在 8MHz 晶体的驱动下，实现 125ns 的指令周期；16 位的数据宽度、 125ns 的指令周期以及多功能的硬件乘法器(能实现乘加)相配合，能实现数字信号处理的某些算法(如 FFT 等)。
• 超低功耗方面，MSP430 单片机之所以有超低的功耗，是因为其在降低芯片的电源电压及灵活而可控的运行时钟方面都有其独到之处；电源电压采用的是 1.8~3.6V 电压，因而可使其在 1MHz 的时钟条件下运行时， 芯片的电流会在 200~400uA 左右，时钟关断模式的最低功耗只有 0.1uA。

缺点

• 可能不太容易上手，不适合初学者入门，资料也比较少，只能跑官网去找。
• 占的指令空间较大，因为是16位单片机，程序以字为单位，有的指令竟然占6个字节，虽然程序表面上简洁， 但与pic单片机比较空间占用很大。

STM32单片机

由ST厂商推出的​​STM32​​系列单片机，行业的朋友都知道，这是一款性价比超高的系列单片机，应该没有之一，功能及其强大。其基于专为要求高性能、低成本、低功耗的嵌入式应用专门设计的ARM Cortex-M内核，同时具有一流的外设：1μs的双12位ADC，4兆位/秒的UART，18兆位/秒的SPI等等，在功耗和集成度方面也有不俗的表现，当然和MSP430的功耗比起来是稍微逊色的一些，但这并不影响工程师们对它的热捧程度，由于其简单的结构和易用的工具再配合其强大的功能在行业中赫赫有名。

特点​

STM32单片机其强大的功能主要表现在：

• 内核：ARM32位Cortex-M3CPU，最高工作频率72MHz，1.25DMIPS/MHz，单周期乘法和硬件除法。
• 存储器：片上集成32-512KB的Flash存储器；6-64KB的SRAM存储器。
• 时钟、复位和电源管理：2.0-3.6V的电源供电和I/O接口的驱动电压；POR、PDR和可编程的电压探测器(PVD)；4-16MHz的晶振；内嵌出厂前调校的8MHz RC振荡电路，内部40 kHz的RC振荡电路；用于CPU时钟的PLL；带校准用于RTC的32kHz的晶振。
• 调试模式：串行调试(SWD)和JTAG接口；最多高达112个的快速I/O端口、最多多达11个定时器、最多多达13个通信接口。

TMS单片机

这里也提一下TMS系列单片机，虽不算主流。由TI推出的8位CMOS单片机，具有多种存储模式、多种外围接口模式，适用于复杂的实时控制场合。虽然没STM32那么优秀，也没MSP430那么张扬，但是TMS370C系列单片机提供了通过整合先进的外围功能模块及各种芯片的内存配置，具有高性价比的实时系统控制。同时采用高性能硅栅CMOS EPROM和EEPROM技术实现。低工作功耗CMOS技术，宽工作温度范围，噪声抑制，再加上高性能和丰富的片上外设功能，使TMS370C系列单片机在汽车电子，工业电机控制，电脑，通信和消费类具有一定的应用。

PIC单片机

PIC单片机系列是美国微芯公司(Microship)的产品，共分三个级别，即基本级、中级、高级，是当前市场份额增长最快的单片机之一，CPU采用RISC结构，分别有33、35、58条指令，属精简指令集。

同时采用Harvard双总线结构，运行速度快，它能使程序存储器的访问和数据存储器的访问并行处理，这种指令流水线结构，在一个周期内完成两部分工作，一是执行指令，二是从程序存储器取出下一条指令，这样总的看来每条指令只需一个周期，这也是高效率运行的原因之一。

特点​

PIC单片机之所以成为一时非常热的单片机不外乎以下特点：

• 具有低工作电压、低功耗、驱动能力强等特点。PIC系列单片机的I/O口是双向的，其输出电路为CMOS互补推挽输出电路，I/O脚增加了用于设置输入或输出状态的方向寄存器，从而解决了51系列I/O脚为高电平时同为输入和输出的状态。
• 当置位1时为输入状态，且不管该脚呈高电平或低电平，对外均呈高阻状态；置位0时为输出状态，不管该脚为何种电平，均呈低阻状态，有相当的驱动能力，低电平吸入电流达25mA，高电平输出电流可达20mA。相对于51系列而言，这是一个很大的优点。
• 它可以直接驱动数码管显示且外电路简单。它的A/D为10位，能满足精度要求。具有在线调试及编程(ISP)功能。

缺点

• 其专用寄存器(SFR)并不像51系列那样都集中在一个固定的地址区间内(80～FFH)，而是分散在四个地址区间内。只有5个专用寄存器PCL、STATUS、FSR、PCLATH、INTCON在4个存储体内同时出现，但是在编程过程中，少不了要与专用寄存器打交道，得反复地选择对应的存储体，也即对状态寄存器STATUS的第6位(RP1)和第5位(RP0)置位或清零。
• 数据的传送和逻辑运算基本上都得通过工作寄存器W(相当于51系列的累加器A)来进行，而51系列的还可以通过寄存器相互之间直接传送，因而PIC单片机的瓶颈现象比51系列还要严重，这在编程中的朋友应该深有体会。

AVR单片机

AVR单片机是Atmel公司推出的较为新颖的单片机，其显著的特点为高性能、高速度、低功耗。它取消机器周期，以时钟周期为指令周期，实行流水作业。AVR单片机指令以字为单位，且大部分指令都为单周期指令。而单周期既可执行本指令功能，同时完成下一条指令的读取。通常时钟频率用4～8MHz，故最短指令执行时间为250～125ns。

特点​

AVR单片机能成为最近仍是比较火热的单片机，主要的特点：

• AVR系列没有类似累加器A的结构，它主要是通过R16～R31寄存器来实现A的功能。在AVR中，没有像51系列的数据指针DPTR，而是由X(由R26、R27组成)、Y(由R28、R29组成)、Z(由R30、R31组成)三个16位的寄存器来完成数据指针的功能(相当于有三组DPTR)，而且还能作后增量或先减量等的运行，而在51系列中，所有的逻辑运算都必须在A中进行；而AVR却可以在任两个寄存器之间进行，省去了在A中的来回折腾，这些都比51系列出色些。
• AVR的专用寄存器集中在00～3F地址区间，无需像PIC那样得先进行选存储体的过程，使用起来比PIC方便。AVR的片内RAM的地址区间为0～00DF(AT90S2313) 和0060～025F(AT90S8515、AT90S8535)，它们占用的是数据空间的地址，这些片内RAM仅仅是用来存储数据的，通常不具备通用寄存器的功能。当程序复杂时，通用寄存器R0～R31就显得不够用；而51系列的通用寄存器多达128个(为AVR的4倍)，编程时就不会有这种感觉。
• AVR的I/O脚类似PIC，它也有用来控制输入或输出的方向寄存器，在输出状态下，高电平输出的电流在10mA左右，低电平吸入电流20mA。这点虽不如PIC，但比51系列还是要优秀的。

缺点

• 是没有位操作，都是以字节形式来控制和判断相关寄存器位的。
• C语言与51的C语言在写法上存在很大的差异，这让从开始学习51单片机的朋友很不习惯。
• 通用寄存器一共32个(R0～R31)，前16个寄存器(R0～R15)都不能直接与立即数打交道，因而通用性有所下降。而在51系列中，它所有的通用寄存器(地址00～7FH)均可以直接与立即数打交道，显然要优于前者。

Freescale单片机

主要针对S08，S12这类单片机，当然Freescale单片机远非于此。Freescale系列单片机采用哈佛结构和流水线指令结构，在许多领域内都表现出低成本，高性能的的特点，它的体系结构为产品的开发节省了大量时间。此外Freescale提供了多种集成模块和总线接口，可以在不同的系统中更灵活的发挥作用。

特点​

Freescale单片机的特有的特点如下：

• 全系列：从低端到高端，从8位到32位全系列应有尽有，其推出的8位/32位管脚兼容的QE128，可以从8位直接移植到32位，弥补单片机业界8/32 位兼容架构中缺失的一环。
• 多种系统时钟模块：三种模块，七种工作模式。多种时钟源输入选项，不同的mcu具有不同的时钟产生机制，可以是RC振荡器，外部时钟或晶振，也可以是内部时钟，多数CPU同时具有上述三种模块；可以运行在FEI，FEE，FBI，FBILP，FBE，FBELP，STOP这七种工作模式。
• 多种通讯模块接口：Freescale单片机几乎在内部集成各种通信接口模块：包括串行通信接口模块SCI，多主I2C总线模块，串行外围接口模块 SPI，MSCAN08控制器模块，通用串行总线模块(USB/PS2)。
• 具有更多的可选模块：具有LCD驱动模块，带有温度传感器，具有超高频发送模块，含有同步处理器模块，含有同步处理器的MCU还具有屏幕显示模块OSD，还有少数的MCU具有响铃检测模块RING和双音多频/音调发生器DMG模块。
• 可靠性高，抗干扰性强，多种引脚数和封装选择。
• 低功耗、也许Freescale系列的单片机的功耗没有MSP430的低，但是他具有全静态的"等待"和"停止"两种模式，从总体上降低您的功耗!新近推出的几款超低功耗已经与MSP430的不相上下。

STC单片机

说到STC单片机有人会说到，STC也能算主流？基于它是国内还算是比较不错的单片机来说。STC是单时钟/机器周期的单片机，说白了STC单片机是51与AVR的结合体，有人说AVR是51的替代单片机，但是AVR单片机在位控制和C语言写法上存在很大的差异。

而STC单片机结合了51和AVR的优点，虽然功能不及AVR那么强大，但是在AVR能找到的功能，在STC上基本都有，同时STC单片机是51内核，这给以51单片机为基础的工程师们提供了极大的方便，省去了学习AVR的时间，同时也不失AVR的各种功能。

STC单片机是高速、低功耗、超强抗干扰的新一代8051单片机51单片机，指令代码完全兼容传统8051，但速度快8~12倍，内部集成MAX810专用复位电路。4路PWM 8路高速10位A、D转换，针对电机电机 的供应商控制，强干扰场合，成为继51单片机后一个全新系列单片机。

特点

• 下载烧录程序用串口方便好用，容易上手，拥有大量的学习资料及视频，同时具有宽电压：5.5～3.8V、2.4～3.8V， 低功耗设计：空闲模式，掉电模式(可由外部中断唤醒)。
• STC单片机具有在应用编程，调试起来比较方便；带有10位AD，内部EEPROM，可在1T/机器周期下工作，速度是传统51单片机的8~12倍，价格也较便宜。
• 4通道捕获/比较单元，STC12C2052AD系列为2通道，也可用来再实现4个定时器或4个外部中断，2个硬件16位定时器，兼容普通8051的定时器。4路PCA还可再实现4个定时器，具有硬件看门狗、高速SPI通信端口、全双工异步串行口，兼容普通8051的串口，同时还具有先进的指令集结构，兼容普通8051指令集。

八、单片机固件~破解

1 什么是单片机解密?

单片机（MCU）一般都有内部程序区和数据区（或者其一）供用户存放程序和工作数据（或者其一）。为了防止未经授访问或拷贝单片机的机内程序，大部分单片机都带有加密锁定位或者加密字节，以 保护片内程序。

如果在编程时加密锁定位被使能（锁定），就无法用普通编程器直接读取单片机内的程序，这就叫单片机加密。

单片机程序基本上都存在于Flash中，大部分能够读取或者识别Flash上的数据就能够获得Firmware文件，从而给复制产品带来了机会。

单片机攻击者借助专用设备或者自制设备，利用单片机芯片设计上的漏洞或软件缺陷，通过多种技术手段，就可以从芯片中提取关键信息，获取单片机内程序这就叫单片机解密。

单片机解密又叫单片机破解、芯片解密、IC解密，但是严格说来这几种称呼都不科学，但已经成了习惯叫法，我们把CPLD解密、DSP解密都习惯称为单片机解密。单片机只是能装载程序芯片的其中一个类。

能烧录程序并能加密的芯片还有 DSP、CPLD、PLD、AVR、ARM等。当然具有存储功能的存储器芯片也能加密，比如DS2401、DS2501、AT88S0104、DM2602、AT88SC0104D等，当中也有专门设计有加密算法用于专业加密的芯片或设计验证厂家代码工作等功能芯片，该类芯片也能实现防止电子产品复制的目的。

2 单片机解密方法

2.1 软件攻击

该技术通常使用处理器通信接口并利用协议、加密算法或这些算法中的安全漏洞来进行攻击。

比如一个典型事例是对早期XXX系列单片机的攻击。攻击者利用了该系列单片机擦除操作时序设计上的漏洞，使用自编程序在擦除加密锁定位后，停止下一步擦除片内程序存储器数据的操作，从而使加过密的单片机变成没加密的单片机，然后利用编程器读出片内程序。

目前在其他加密方法的基础上，可以研究出一些设备，配合一定的软件，来做软件解密。

还有比如利用某些编程器定位插字节，通过一定的方法查找芯片中是否有连续空位，也就是说查找芯片中连续的FFFF字节，插入的字节能够执行把片内的程序送到片外的指令，然后用解密的设备进行截获，这样芯片内部的程序就被解密完成了。

2.2 电子探测攻击

该技术通常以高时间分辨率来监控处理器在正常操作时所有电源和接口连接的模拟特性，并通过监控它的电磁辐射特性来实施攻击。

因为单片机是一个活动的电子器件，当它执行不同的指令时，对应的电源功率消耗也相应变化。这样通过使用特殊的电子测量仪器和数学统计方法分析和检测这些变化，即可获取单片机中的特定关键信息。

2.3 过错产生技术

该技术使用异常工作条件来使处理器出错，然后提供额外的访问来进行攻击。使用最广泛的过错产生攻击手段包括电压冲击和时钟冲击。

低电压和高电压攻击可用来禁止保护电路工作或强制处理器执行错误操作。时钟瞬态跳变也许会复位保护电路而不会破坏受保护信息。电源和时钟瞬态跳变可以在某些处理器中影响单条指令的解码和执行。

该办法就是使得单片机异常运行从而使得单片机处于非保护状态。

2.4 探针技术

该技术是直接暴露芯片内部连线，然后观察、操控、干扰单片机以达到攻击目的。

芯片内部都完全暴露了，芯片正在瑟瑟发抖！

3 单片机解密分类

为了方便起见，人们将以上四种攻击技术分成两类，一类是侵入型攻击（物理攻击），这类攻击需要 破坏封装，然后借助半导体测试设备、显微镜和微定位器，在专门的实验室花上几小时甚至几周时间才能完成。

解密单片

机程序相关

​​如何解密单片机内程序​​？

所有的微探针技术都属于侵入型攻击。

另外三种方法属于非侵入型攻击，被攻击的单片机不会被物理损坏。在某些场合非侵入型攻击是特别危险的，这是因为非侵入型攻击所需设备通常可以自制和升级，因此非常廉价。

大部分非侵入型攻击需要攻击者具备良好的处理器知识和软件知识。与之相反，侵入型的探针攻击则不需要太多的初始知识，而且通常可用一整套相似的技术对付宽范围的产品。

因此，对单片机的攻击往往从侵入型的反向工程开始，积累的经验有助于开发更加廉价 和快速的非侵入型攻击技术。

4 侵入式解密过程

侵入型攻击的第一步是揭去芯片封装（简称"开盖"有时候称"开封"，英文为 "DECAP"，decapsulation）。有两种方法可以达到这一目的。

第一种是完全溶解掉芯片封装，暴露金属连线。

第二种是只移掉硅核上面的塑料封装。

第一种方法需要将芯片绑定到测试夹具上，借助绑定台来操作。第二种方法除了需要具备攻击者一定的知识和必要的技能外，还需要个人的智慧和耐心，但操作起来相对比较方便，完全实验室中操作。

芯片上面的塑料可以用小刀揭开，芯片周围的环氧树脂可以用浓硝酸腐蚀掉。热的浓硝酸会溶解掉芯片封装而不会影响芯片及连线。该过程一般在非常干燥的条件下进行，因为水的存在可能会侵蚀已暴露的铝线连接 （这就可能造成解密失败）。

接着在超声池里先用丙酮清洗该芯片以除去残余硝酸，并浸泡。

最后一步是寻找保护熔丝的位置并将保护熔丝暴露在紫外光下。一般用一台放大倍数至少100倍的显微镜，从编程电压输入脚的连线跟踪进去，来寻找保护熔丝。若没有显微镜，则采用将芯片的不同部分暴露到紫外光下并观察结果的方式进行简单的搜索。

操作时应用不透明的物体覆盖芯片以保护程序存储器不被紫外光擦除。将保护熔丝暴露在紫外光下５～10分钟就能破坏掉保护位的保护作用，之后，使用简单的编程器就 可直接读出程序存储器的内容。

对于使用了防护层来保护EEPROM单元的单片机来说，使用紫外光复位保护电路是不可行的。对于这种类型的单片机，一般使用微探针技术来读取存储器内容。在芯片封装打开后，将芯片置于显微镜下就能够很容易的找到从存储器连到电路其它部分的数据总线。

由于某种原因，芯片锁定位在编程模式下并不锁定对存储器的访问。利用这一缺陷将探针放在数据线的上面就能读到所有想要的数据。在编程模式下，重启读过程并连接探针到另外的数据线上就可以读出程序和数据存储器中的所有信息。

还有一种可能的攻击手段是借助显微镜和激光切割机等设备来寻找保护熔丝，从而寻查和这部分电路相联系的所有信号线。

由于设计有缺陷，因此，只要切断从保护熔丝到其它电路的某一根信号线（或切割掉整个加密电路）或连接1～3根金线（通常称 FIB：focused ion beam)，就能禁止整个保护功能，这样使用简单的编程器就能直接读出程序存储器的内容。

虽然大多数普通单片机都具有熔丝烧断保护单片机内代码的功能，但由于通用低档的单片机并非定位于制作安全类产品，因此，它们往往没有提供有针对性的防范措施且安全级别较低。

加上单片机应用场合广泛，销售量大，厂商间委托加工与技术转让频繁，大量技术资料外泻，使得利用该类芯片的设计漏洞和厂商的测试接口，并通过修改熔丝保护位等侵入型攻击或非侵入型攻击手段来读取单片机的内部程序变得比较容易。

5 单片机解密几点建议

任何一款单片机从理论上讲，攻击者均可利用足够的投资和时间使用以上方法来解密。这是系统设计者应该始终牢记的基本原则。

因此，作为电子产品的设计工程师非常有必要了解当前单片机攻击的最新技术，做到知己知彼，心中有数，才能有效防止自己花费大量金钱和时间辛辛苦苦设计出来的产品被人家一夜之间仿冒的事情发生。相关推荐：STM32等单片机程序加密的方法。下面是根据某公司的解密实践提出的建议：

（1）在选定加密芯片前，要充分调研，了解单片机破解技术的新进展，包括哪些单片机是已经确认可以破解的。尽量不选用已可破解或同系列、同型号的芯片选择采用新工艺、新结构、上市时间较短的单片机。

（2）对于安全性要求高的项目，尽量不要使用普及程度最高，被研究得也最透的芯片。

（3）产品的原创者，一般具有产量大的特点，所以可选用比较生僻、偏冷门的单片机来加大仿冒者采购的难度，选用一些生僻的单片机。

（4）在设计成本许可的条件下，应选用具有硬件自毁功能的智能卡芯片，以有效对付物理攻击；另外程序设计的时候，加入时间到计时功能，比如使用到1年，自动停止所有功能的运行，这样会增加破解者的成本。

（5）如果条件许可，可采用两片不同型号单片机互为备份，相互验证，从而增加破解成本。

（6）打磨掉芯片型号等信息或者重新印上其它的型号，以假乱真。

（7）可以利用单片机未公开,未被利用的标志位或单元,作为软件标志位。

（8）你应在程序区写上你的大名单位开发时间及仿制必究的说法,以备获得法律保护；另外写上你的大名的时候，可以是随机的，也就是说，采用某种算法，外部不同条件下，你的名字不同，比如www.XXXXX.com、www.XXXXX.cn, www.XXXXX.com.cn 等，这样比较难反汇编修改。

（9）采用高档的编程器，烧断内部的部分管脚，还可以采用自制的设备烧断金线，这个目前国内几乎不能解密，即使解密，也需要上万的费用，需要多个母片。

（10）采用保密硅胶（环氧树脂灌封胶）封住整个电路板，PCB上多一些没有用途的焊盘，在硅胶中还可以掺杂一些没有用途的元件，同时把MCU周围电路的电子元件尽量抹掉型号。

（11）可以用编程器把空白区域中的FF改成00，也就是把一些未使用的空间都填充好,这样一般解密器也就找不到芯片中的空位,也就无法执行以后的解密操作。

当然，要想从根本上防止单片机被解密，那是不可能的，加密技术不断发展，解密技术也不断发展，现在不管哪个单片机，只要有人肯出钱去做，基本都可以做出来，只不过代价高低和周期长短的问题，编程者还可以从法律的途径对自己的开发作出保护（比如专利）。

九、STM32外部中断实例

本文用STM32CubeIDE软件实现STM32外部中断实例。

新建工程

"File"-"New"-"STM32 Project"。

输入芯片型号STM32F103ZE。

选择相应封装，下一步。

填写项目名，选择工程位置，下一步。

配置时钟、调试模式

选择高速外部时钟。

HCLK总线时钟处输入72，回车，配置使用最高时钟频率。

调试模式选择串行，方便下载程序。

配置管脚外设

本实例中用到了LED1与KEY_LEFT，找到相应电路图。

可见LED1对应PC0管脚，低电平点亮。按键K1对应PE2管脚，低电平有效。

PC0配置为GPIO_Output，GPIO输出模式。

PE2配置为GPIO_EXTI2，GPIO中断线2。

对GPIO进行配置，可以看到PC0、PE2两个管脚。

PC0管脚的配置：

• GPIO输出电平，"High"，复位后高电平，LED1熄灭状态。
• GPIO模式，"Output Push Pull"，推挽输出，相关文章:​梳理清楚推挽、开漏、OC、OD​。
• GPIO上拉下拉，"Pull-up"，上拉，默认高电平，避免管脚电平状态不稳定

PE2管脚的配置，GPIO模式这里有6个选项，分别是：

• 上升沿触发的外部中断
• 下降沿触发的外部中断
• 上升/下降沿触发的外部中断
• 上升沿触发的事件中断
• 下降沿触发的事件中断
• 上升/下降沿触发的事件中断

"外部中断"与"事件中断"的区别：

• "事件中断"可以由硬件自动完成这个事件产生的结果，比如引起DMA操作、AD转换等，响应速度更快。
• 而本例中需要中断服务函数才能完成中断后产生的结果，是"外部中断"

由电路图可知，KEY1按键按下时为低电平，过程中会产生一个下降沿，所以选择"下降沿外部中断"这一项。

按键低电平有效，选择上拉，给管脚一个稳定的电平状态，不按下时为默认的高电平。

配置NVIC嵌套向量中断控制器

NVIC就是用来控制中断响应的，如下图列出了各个中断。可以分别配置其使能状态、抢占优先级与响应优先级。

因为PE2配置为GPIO_EXTI2中断，它出现在了列表中。同时出现的还有SysTick，它是HAL_Delay的时基来源，如下图note处所说的，每隔一个固定时间产生一次中断。

因为下文中断服务函数代码中用到了HAL_Delay延时函数，把SysTick与EXTI2的抢占优先级分别设置为0与2。在这里，数值越大优先级越小。

配置中断服务函数

进行上述配置之后，点击生成代码。

本实例中的中断类型是"外部中断"，通过中断服务函数来实现。

打开stm32f1xx_it.c文件，找到中断服务函数，它调用了GPIO中断服务函数。

F3找到这个函数的定义，在清除中断标志位后，进入了Callback回调函数。

这个Callback函数也是一个弱化函数，，可以重写，如下图的__weak标识。

回到stm32f1xx_it.c文件，在末尾user code处写上中断发生时要实现的结果。

十、嵌入式开发，出现了Bug该怎么定位解决？​

1)、问题复现

稳定复现问题才能正确的对问题进行定位、解决以及验证。一般来说，越容易复现的问题越容易解决。

1.1 模拟复现条件

有的问题存在于特定的条件下，只需要模拟出现问题的条件即可复现。对于依赖外部输入的条件，如果条件比较复杂难以模拟可以考虑程序里预设直接进入对应状态。​

1.2 提高相关任务执行频率

例如某个任务长时间运行才出现异常则可以提高该任务的执行频率。​

1.3 增大测试样本量

程序长时间运行后出现异常，问题难以复现，可以搭建测试环境多套设备同时进行测试。​

2)、问题定位

缩小排查范围，确认引入问题的任务、函数、语句。​

2.1 打印LOG

根据问题的现象，在抱有疑问的代码处增加LOG输出，以此来追踪程序执行流程以及关键变量的值，观察是否与预期相符。​

2.2 在线调试

在线调试可以起到和打印LOG类似的作用，另外此方法特别适合排查程序崩溃类的BUG，当程序陷入异常中断(HardFault，看门狗中断等)的时候可以直接STOP查看call stack以及内核寄存器的值，快速定位问题点。​

2.3 版本回退

使用版本管理工具时可以通过不断回退版本并测试验证来定位首次引入该问题的版本，之后可以围绕该版本增改的代码进行排查。​

2.4 二分注释

二分注释即以类似二分查找法的方式注释掉部分代码，以此判断问题是否由注释掉的这部分代码引起。

具体方法为将与问题不相干的部分代码注释掉一半，看问题是否解决，未解决则注释另一半，如果解决则继续将注释范围缩小一半，以此类推逐渐缩小问题的范围。​

2.5 保存内核寄存器快照

Cortex M内核陷入异常中断时会将几个内核寄存器的值压入栈中，如下图：

我们可以在陷入异常中断时将栈上的内核寄存器值写入RAM的一段复位后保留默认值的区域内，执行复位操作后再从RAM将该信息读出并分析，通过PC、LR确认当时执行的函数，通过R0-R3分析当时处理的变量是否异常，通过SP分析是否可能出现栈溢出等。STM32堆栈相关文章请移步:详解STM32单片机的堆栈。​

3)、问题分析处理

结合问题现象以及定位的问题代码位置分析造成问题的原因。​

3.1 程序继续运行

3.1.1 数值异常

3.1.1.1 软件问题

1、数组越界

写数组时下标超出数组长度，导致对应地址内容被修改。如下：

此类问题通常需要结合map文件进行分析，通过map文件观察被篡改变量地址附近的数组，查看对该数组的写入操作是否存在如上图所示不安全的代码，将其修改为安全的代码。

2、栈溢出

如上图，此类问题也需要结合map文件进行分析。假设栈从高地址往低地址增长，如果发生栈溢出，则g_val的值会被栈上的值覆盖。

出现栈溢出时要分析栈的最大使用情况，函数调用层数过多，中断服务函数内进行函数调用，函数内部申明了较大的临时变量等都有可能导致栈溢出。

解决此类问题有以下方法：

• 在设计阶段应该合理分配内存资源，为栈设置合适的大小；
• 将函数内较大的临时变量加"static"关键字转化为静态变量，或者使用malloc()动态分配，将其放到堆上；
• 改变函数调用方式，降低调用层数。

3、判断语句条件写错

判断语句的条件容易把相等运算符"=="写成赋值运算符"="导致被判断的变量值被更改，该类错误编译期不会报错且总是返回真。

建议将要判断的变量写到运算符的右边，这样错写为赋值运算符时会在编译期报错。还可以使用一些静态代码检查工具来发现此类问题。

4、同步问题

例如操作队列时，出队操作执行的过程中发生中断(任务切换)，并且在中断(切换后的任务)中执行入队操作则可能破坏队列结构，对于这类情况应该操作时关中断（使用互斥锁同步）。

5、优化问题

如上图程序，本意是等待irq中断之后不再执行foo()函数，但被编译器优化之后，实际运行过程中flg可能被装入寄存器并且每次都判断寄存器内的值而不重新从ram里读取flg的值，导致即使irq中断发生foo()也一直运行，此处需要在flg的申明前加"volatile"关键字，强制每次都从ram里获取flg的值。​

3.1.1.2 硬件问题

1、芯片BUG

芯片本身存在BUG，在某些特定情况下给单片机返回一个错误的值，需要程序对读回的值进行判断，过滤异常值。

2、通信时序错误

例如电源管理芯片Isl78600，假设现在两片级联，当同时读取两片的电压采样数据时，高端芯片会以固定周期通过菊花链将数据传送到低端芯片，而低端芯片上只有一个缓存区.

如果单片机不在规定时间内将低端芯片上的数据读走那么新的数据到来时将会覆盖当前数据，导致数据丢失。此类问题需要仔细分析芯片的数据手册，严格满足芯片通信的时序要求。​

3.1.2 动作异常

3.1.2.1 软件问题

1、设计问题

设计中存在错误或者疏漏，需要重新评审设计文档。

2、实现与设计不符

代码的实现与设计文档不相符需要增加单元测试覆盖所有条件分支，进行代码交叉review。

3、状态变量异常

例如记录状态机当前状态的变量被篡改，分析该类问题的方法同前文数值异常部分。​

3.1.2.2 硬件问题

1、硬件失效

目标IC失效，接收控制指令后不动作，需要排查硬件。

2、通信异常

与目标IC通信错误，无法正确执行控制命令，需要使用示波器或逻辑分析仪去观察通信时序，分析是否发出的信号不对或者受到外部干扰。​

3.2 程序崩溃

3.2.1 停止运行

3.2.1.1 软件问题

1、HardFault

以下情况会造成HardFault：

• 在外设时钟门未使能的情况下操作该外设的寄存器；
• 跳转函数地址越界，通常发生在函数指针被篡改，排查方法同数值异常；
• 解引用指针时出现对齐问题：

以小端序为例，如果我们声明了一个强制对齐的结构体如下：

此时a.val1的地址为0x00000001，如果以uint16_t类型去解引用此地址则会因为对齐问题进入HardFault，如果一定要用指针方式操作该变量则应当使用memcpy()。

2、中断服务函数中未清除中断标志

中断服务函数退出前不正确清除中断标志，当程序执行从中断服务函数内退出后又会立刻进入中断服务函数，表现出程序的"假死"现象。

3、NMI中断

调试时曾遇到SPI的MISO引脚复用NMI功能，当通过SPI连接的外设损坏时MISO被拉高，导致单片机复位后在把NMI引脚配置成SPI功能之前就直接进入NMI中断，程序挂死在NMI中断中。这种情况可以在NMI的中断服务函数内禁用NMI功能来使其退出NMI中断。​

3.2.1.2 硬件问题

• 晶振未起振
• 供电电压不足
• 复位引脚拉低

3.2 .2 复位3.2.2.1 软件问题

1、看门狗复位

除了喂狗超时导致的复位以外，还要注意看门狗配置的特殊要求，以Freescale KEA单片机为例，该单片机看门狗在配置时需要执行解锁序列（向其寄存器连续写入两个不同的值），该解锁序列必须在16个总线时钟内完成，超时则会引起看门狗复位。此类问题只能熟读单片机数据手册，注意类似的细节问题。​

3.2.2.2 硬件问题

• 供电电压不稳
• 电源带载能力不足

4)、回归测试

问题解决后需要进行回归测试，一方面确认问题是否不再复现，另一方面要确认修改不会引入其他问题。​

5)、经验总结

总结本次问题产生的原因及解决问题的方法，思考类似问题今后如何防范，对相同平台产品是否值得借鉴，做到举一反三，从失败中吸取经验。