1250_FreeRTOS_QEMU_M3_blinky例程梳理分析

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)

前面，QEMU的基础仿真环境已经搭建成功了。能够实现printf这样的提示功能我觉得在软件的调试上就有很多可以尝试的地方了。如果能够改改中断，模拟几个GPIO信息，可能这样的环境会更完善一些。即使是GPIO的信息不支持，pritnf用一个变量模拟一下也有很好的体验。

接下来，分析一下blinky示范工程。可能，这是所有的例程中最简单的一个了吧。

这里的这个注释还是很有价值的，解决了我之前的一个疑惑。感觉我自己第一次尝试的时候运气还是有的，居然直接碰出来了正确的结果。

现在的配置是使能了blinky的例程，其实整个配置的生效很简单，具体如下：

从全工程的角度看，这个配置的信息出现在了3个不同的文件，但是其实只有main.c中涉及到真正的代码。

main函数中，通过这个配置实现了2个main函数的配置分支。

另一个地方则是tick hook函数，这个在blinky的例程中是被禁用掉了的。

main函数这边付恩性需要看两部分信息，一部分是辅助信息，另一部分则是串口初始化。剩下的部分直接进入到了不同的main实现，创建不同的OS例程。上面的注释部分，是我之前看过的一个页面。

串口初始化看起来是一个模拟环境支持的一个成熟的外设，这个让我对QEMU有了更多的期待。

接下来，创建了一个队列对象。判断，如果队列创建成功那么接下来创建2个任务以及一个软件定时器对象。软件定时器对象还注册绑定了一个回调函数，之后启动了定时器和OS的调度。为了能够阅读更舒服，我做了简单的排版，但是尝试了编译执行没有影响。

通过上面的信息，大概可以知道接收队列消息的任务会被来自队列消息发送任务或者定时器回调函数发出来的队列消息激活。其中，按照周期信息看，两者有一个10倍的关系。

发送任务，向队列每200ms发一个消息。

回调函数，每2S中发一个消息。

接收任务，我做了简单的修改，为了能更好看清楚前面分析出来的倍数关系。

最后补充软件定时器的部分配置谢谢你，这个优先级还是很高的，现定时器任务在的优先级是5，高于前面的收发两个任务。

最后看看运行效果，这个可以看出来10倍的关系，但是第一次的执行不是10。应该是定时器启动早于调度器启动导致的吧？可以作为一个问题后面跟踪一下，我想这个等守护程序的配置加上之后可以测试出来。