解决FreeRTOS移植MQTT时的DEBUG

创建多任务的时候，要估算堆栈大小，防止溢出。

我们在成功创建任务后，第一步去做的还是我们最熟悉的，点灯，点灯的控制是在MQTT的订阅消息处理回调函数种，通过判断topic和payload，发送通知给LED任务去控制LED亮灭的

 使用的任务通知API是：

 

 

xTaskNotifyWait 既可以让我们获取到一个更新后的任务通知值，又可以顺便让任务进入阻塞状态，在大多数场合下，效果更佳

我在写完MQTT通知LED任务控制LED时，遇到了一个问题：LED任务根本没有被调度执行,我在MQTT任务和按键任务中没有做任何让步动作，又我们在FreeRTOSConfig.h中使能了抢占调度算法：就导致MQTT任务在一直运行,低优先级的任务根本没有机会被调度,所以我在MQTT任务的while(1)中加了一个vTaskDelay，这样这个bug就解决了

然后是去写按键的控制任务，按键我们的做法是将按键信息读取到之后写入到队列中，MQTT任务的while(1)中读取队列消息，然后publish给服务器,队列的使用又三个动作：创建队列、写队列和读队列

 

 写队列有三个API供我们使用：

 

 

我们是在按键任务中创建了队列，使得队列xKeyQueue这个句柄不是NULL;但是MQTT任务的优先级比按键任务要高

他会先执行到自己的while(1)那里，在没开始调度按键任务的时候就先去对一个为NULL的xKeyQueue队列进行了读，也就是去访问了一个空指针,那肯定就会导致一个hardfault了,所以我的处理方式是：

先来判断下队列是否创建好了，如果没有就让步，让按键任务去执行创建好队列了来

 

 我们调用MQTTYeild的时候会尝试去读取网络接受数据漏指令指的是有时候手机操作板子没响应？读取网络接收数据实际调用的接口就是

 我们在这里面调用的

底层用了HAL库的延时

这就导致，我们从mobile发送指令到服务器，服务器再转发给开发板的时候，可能会导致我们在

 

 这个地方阻塞了某次接收，怎么阻塞的呢？我们在HAL_Delay做超时的时候，freertos的systick也是在运行的，那么在

 

 这里超时的时候，

 这个timeout也会在计数的

当我们的

 因为超时退出后也有可能已经计数递减到了0，退出，

 

这个函数的时候，返回一个为0的接收长度值，导致MQTT这个库在后面的流程中不会将我们读取出来的

 这个buffer放到外面在MQTT任务一开始初始化客户端的时候定义的那个readbuf中

 那我们的MQTTYeild

 就会在这次尝试读之后直接返回一个0

 不管是在哪一步被阻塞返回一个0值，都是有可能会使得我们读不到一个完整的订阅消息的，所以我将底层读取网络数据的驱动改了下

 改过之后没有在底层堵塞了，就是因为在底层用了HAL_Delay做了超时堵塞才导致的漏消息，在那三个步骤过程中任意地方xTimeout已经计数成0了的话

 

 就会随时中断读取消息，从而导致漏掉消息，其实消息还是保存到最底层的ringbuffer里面的，只是因为在下层堵塞导致上面的软件定时器的超时计数xTimeout提前被计数到0了，导致MQTT没有继续读取，超时退出了，才导致的漏掉一次消息，解决了这个bug后，我们本期的物联网智能家居就算是完成了