自学FreeRTOS+STM32F407经验迭代-优快云博客

本文链接：https://blog.youkuaiyun.com/mapleay/article/details/142592358

0. 持之以恒，坚持走下去的意念。

1. 系统时基：无论是否加载 RTOS , 都必须搞清楚时钟源、分频倍频系数、SysTick timer的1ms中断；STM32的HAL库也进化出了内置时基，RTOS自带系统时基与延迟函数APIs。

2. 外设模块的时钟使能后，就不要关闭了。也不要重复开启，比如DMA，可能导致传输错乱；

3. stm32f407的中断 TXE、RXNE ，以字节为单位中断，但是 TC 可以传输流中断，因为TC关联的是TDR和TSR双寄存器为空，也可以是单字节为单位中断。

4. DMA的普通模式传输（非环形传输），特别需要注意，数据不要被覆盖，关注点在于：在合适的时刻启动数据的传输。

5. FreeRTOS的队列 send/receive/peek 也只能一次处理一个字节的能力。这与 DMA 的功能天然相悖。所以找个Buffer累积好数据后，再交给DMA批量传输.

6. 实验原则：迭代原则：单次引入一个变量因素。遇到困境，合理推测通过实验去验证，如此反复推进。当然掌握 keil 、Jlink 的实时仿真技巧也是非常有价值的。推测的依据是官方参考手册给的知识点。

7. C语言的使用：注意可重入函数的使用价值，有些操作可以放在API接口里，有些操作可以放在RTOS的任务内，合理权衡。不清楚的C细节，可以直接去写代码验证，比如用codeblock IDE，直接验证（数组长度、字符串长度，如何正确过度两者的细节）。

8. 可以使用 USB 转 TTL，直接连接 MCU USARTx 引脚，输出调试信息。

9. RTOS操作系统内，对全局变量的使用应当十分谨慎。RTOS中的全局变量，能不用就尽量不用，否则可能致使资源访问的完整性受到破坏，导致业务逻辑错乱。万一迫不得已必须使用，就应该十分谨慎地操作，保证严格数据访问完整性不被破坏。比如可以使受访问资源和访问对象一对一地单独成对。所以，尽量用内核提供的功能。

10.

/*
** 线程之间的全局变量，是完全不必要的，有任务间通信机制。
** 我觉得若全局变量被需要也是在单线程内部被需要，不允许在任务间使用，保证数据严格一致性。
** 这里引入的事件组，便是任务间通信的另一种重要的通信手段。
*/

11. 不要在没创建内核对象之前去使用该内核对象相关的其他APIs，否则死机，卡死在断言处！RTOS系统内核需要先完全接管系统，期间不能被硬件ISR打断，尤其是TIMx，再初始化硬件。

12. USB转TTL进行串口通信时，必须至少保证连接三条线：发送线、接收线和GND。我就是少了一根共地线GND，在Jlink拔出以后，PC端无法显示接收到的数据了。GND线不能少！！

---------------------------血泪经验---------------------------

13. 可能13真的不是一个吉利的数字。哈哈。困扰我快一个月的事情终于找到了。

平台环境：lwip-v2.1.0 + stm32f407vet + freertos-v10.3.0 + CubeMX-v6.12.0

问题现象：lwip的lwipopts.h参数使用CubeMX默认设置，运行 tcpecho server. 底层ETH/PHY硬件已初始化良好，无异常发现。在不插入rj45网口水晶头的前提下开机可以正常运行；但是在插入rj45水晶头的前提下开启stm32f407开发板，会进入硬中断！

发现问题的经过：机缘巧合，使用printf函数在lwip协议栈初始化过程中做标记，发现是死在了lwip协议栈的初始化过程中。机缘巧合，使用systemview查看defaulTask任务的栈空间已耗尽为0，此任务不运行了，且其他任务可以正常运行。转念一想，defaultTask正是初始化lwip协议栈的任务，会不会因为此任务的栈空间耗尽导致未能正常初始化lwip协议栈，且进入了stm32的硬中断。

验证方法：唯一变量法则，使用原封不动的问题线程代码，只调整增加了defaultTask的堆栈空间，由原来的128增加到256. 随后进行验证，结果整个系统运行稳定。

总结：我也是掉坑！我服！初始化过程，也是一个十分重要的环节，尤其是在使用RTOS的场景中。所以，要保证每个任务的参数配置合理，比如栈空间大小。