为什么要串口唤醒STOP模式？如何才能实现串口唤醒STOP模式呢？

前言

STM32常见的低功耗模式有三种：睡眠模式、STOP模式以及待机模式，STM32L系列还有其他低功耗模式。这里主要讲的是STOP模式，STOP模式可以通过外部中断或事件唤醒，但是不能通过串口中断唤醒，因为串口中断本身不是外部中断，那么如何才能实现串口唤醒STOP模式呢？

因为我这里只是为了做验证，为了快速验证，我也就没有用RT-Thread的PM电源管理组件进入STOP模式，感兴趣的读者可以用RT-Thread的电源管理组件去实现进行STOP模式。

一、为什么要串口唤醒STOP模式？

想象一下，在某些场合，如果你有一个无线通信模块（例如ESP8266、SIM800C）和STM32通过串口发送AT命令来对接服务器实现与服务器的数据交互，那么如果在没有进行数据交互的时候，我们是不是可以让STM32进入STOP模式来达到省电的状态，从而让电池续航更长。例如：STM32+ESP8266与后台服务器进行数据交互，当不用发送数据完毕，等待下次发送数据或等待后台下发数据给设备的这段时间可以让STM32进入STOP模式来达到省电，当后台服务器下发数据给设备的时候，我们可以向让后台发送一个唤醒设备的指令，ESP8266接收到后台的这条指令之后通过串口下发给STM32，那么就可以唤醒STM32了，这时候STM32就可以继续接收后台下发的数据。

二、串口唤醒STOP模式的思路

1、我们知道STOP模式只能外部中断或事件唤醒，那么想象一下，在STM32进行STOP模式之前，是不是可以先将UART_RX对应的GPIO引脚配置为外部中断引脚，而串口接收到字符相当于接收到01010…这样的高低电平，从二可以唤醒串口，当唤醒之后，我们再马上重新初始化串口，把UART_RX对应的GPIO引脚配置为接收中断模式？答案当然是可以的。

2、唤醒之后的程序是从哪里开始执行？答案是从进行STOP模式之前的那个地方重新开始执行，一会进行验证。

三、串口唤醒STOP模式实验

光说不练都是假把式，接下来进行实验。

1、 实验平台： 中国移动物联网OneNET NB开发板（板载STM32）。

2、STM32F103RET6、12M外部晶振、串口3进行实验。

3、 操作系统： RT-Thread。

4、用RT-Thread创建两个线程，一个线程用于读取按键是否按下，按下则调用进入STOP模式函数进入STOP模式，另一个线程读取串口接收到的数据。

1、如何进行STOP模式？

实验时用的是标准库，在这里主要实现在进入STOP模式前将RX对应的GPIO引脚配置为外部中断模式以及进入STOP模式，代码如下：

1/**************************************************************
 2函数名称:system_enter_stop
 3函数功能:系统进入STOP模式
 4输入参数:无
 5返 回 值:无
 6备    注:无
 7**************************************************************/
 8void system_enter_stop(void)
 9{
10        uart_exti_init(); /* 进入STOP模式前配置RX引脚为外部中断模式 */
11    RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR , ENABLE); /* 开电源管理时钟 */
12    //PWR_EnterSTOPMode(PWR_Regulator_ON, PWR_STOPEntry_WFI); /* 进入STOP模式，外部中断唤醒 */
13    PWR_EnterSTOPMode(PWR_Regulator_LowPower, PWR_STOPEntry_WFE); /* 进入STOP模式，外部中断或事件唤醒 */
14}

2、配置RX对应的GPIO引脚为外部中断模式

这里采用RT-Thread的PIN设备进行配置，在配置之前需要先关闭UART中断、复位UART、复位GPIO，然后在进行配置为外部中断模式，代码如下：

1/**************************************************************
 2函数名称:uart_exti_init
 3函数功能:RX引脚配置为外部中断
 4输入参数:无
 5返 回 值:无
 6备    注:无
 7**************************************************************/
 8void uart_exti_init(void)
 9{
10        /* 关闭UART中断、复位UART、复位GPIO */
11    USART_ITConfig(USART3, USART_IT_RXNE, DISABLE);
12    USART_Cmd(USART3, DISABLE);
13    GPIO_DeInit(GPIOB);
14    USART_DeInit(USART3);
15
16    /* 配置RX对应的GPIO引脚为外部中断模式 */
17    rt_pin_mode(PIN_UART3_RX, PIN_MODE_INPUT_PULLUP);
18    rt_pin_attach_irq(PIN_UART3_RX, PIN_IRQ_MODE_FALLING, uart_exti_callback, RT_NULL);
19    rt_pin_irq_enable(PIN_UART3_RX, PIN_IRQ_ENABLE);
20}

3、接收中断回调函数

在上面的配置中，有一个接收回调函数uart_exti_callback，就是在发送中断的时候要执行的事情，在接收回调函数里面，我们主要实现SystemInit，重新初始化串口，代码如下：

1/**************************************************************
 2函数名称:uart_exti_callback
 3函数功能:RX引脚外部中断唤醒回调函数
 4输入参数:args：回调函数入口参数
 5返 回 值:无
 6备    注:无
 7**************************************************************/
 8void uart_exti_callback(void *args)
 9{
10    SystemInit();
11    uart_reinit();      /* 重新初始化串口 */
12    rt_kprintf("wake up\\r\\n");
13
14}

4、进入STOP模式的线程

这里，创建一个线程来实现判断是否按键按下，按下则调用system_enter_stop函数进入STOP模式，同时为了验证唤醒之后时钟正常以及程序是从进行STOP模式之前的那个地方重新开始执行，我们设计LED灯500ms亮500ms灭，再一个计数变量，每隔1秒自动加1并打印，代码如下：

1static void sleep_thread_entry(void *parameter)
 2{
 3    unsigned char key;
 4    unsigned int count=0;
 5
 6    while(1)
 7    {
 8        key = key_scan(0);
 9
10        if(key == KEY4_PRES)
11        {
12            rt_kprintf("system_enter_stop\\r\\n");
13            system_enter_stop();
14        }
15        LED1(1);
16        rt_thread_mdelay(500);
17        LED1(0);
18        rt_thread_mdelay(500);
19        rt_kprintf("count:%d\\r\\n",count);
20        count++;
21    }
22}

5、实验操作和现象

1、开机之后，LED闪烁，串口打印count每隔1秒加1的值，等待一小会按下按键KEY4进入STOP模式：

FinSH抓取的串口打印信息

2、对比进入STOP模式前和STOP模式之后的电流情况（这里进入STOP模式之后电流还是很大是因为我们板子还接了其他耗电的模块，我们这对比电流有没有降下来就可以了），很明显，电流降下来了：

进入STOP模式前的电流

进入STOP模式后的电流

3、通过串口发送一个字符“A”，唤醒了STM32，这时候串口并不会打印字符“A”，因为唤醒之后要重新初始化串口，第二次发送字符“A”才能显示，这时候，我们观察FinSH打印出来的信息，可以看到count是从9开始打印，说明STOP唤醒之后会从原来进入STOP模式之前的地方重新执行代码：

验证代码的执行情况

唤醒之后第二次发一个字符能正常打印

4、接下来，我们再次按下KEY4重新然STM32进入STO模式，然后发送一个比较长的字符串来唤醒STM32，例如发“ABCDEFGHIJKLMNOPQ1234567890”，这时候，我们发现第一次发送之后，竟然会有字符出来，不是说没有吗？而且这些字符和我们发送的不一样，少了，第二次才正常：

唤醒之后打印字符不正常

四、串口唤醒存在的问题

1、上面我们提到，发送一个字符唤醒就很正常，而发送比较长的字符串唤醒却出现了不然正常的现象，这是为什么呢？想象一下m如果你是发一串很长的数据来唤醒串口，这串数据也是通过0101010等二进制来发送的，当RX引脚被触发中断唤醒MCU之后，唤醒之后串口初始化完成了，剩余的数据也就会接着以010101的高低电平发给STM32的串口，有可能导致有些字符的01丢失了一部分（例如上面出现了K567890），从而可以接下来的字符会打印出来。如果是发一个字符，一个字符的01010101其实也就8位，发送很快的，唤醒之后都已经发送结束了，所以就会直接唤醒，也就不会接收这个字符，只有第二次发送的时候才会接收到这个字符。