1261_CubeIDE中的任务创建代码分析

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

这里包含两部分代码，被注释掉的133-134行是CubeIDE生成的代码。跟FreeRTOS原始的接口有些不同了，我觉得这部分倒是可以去掉生成代码自己处理。一者是能够对FreeRTOS更熟悉，换平台也依然可以通用。另一方面，多了一层接口的封装总归是一些资源的浪费。

这里根据几种常用的配置模式来实现了上面截图我在注释中提到的线程的定义，理解这部分信息，关键的梳理点其实是thread。所有的信息都是围绕这样的一个概念来整理的。当然，最终的概念实现还是落实到了FreeRTOS的任务上。

这个把线程的名字按照字符串展开，而展开后的信息就是上面的thread的定义信息。后面，进行任务创建的时候会从里面提取相应的信息。

这里是线程创建的实现，几种不同的配置模式全都在这样的接口里面实现了。从某种程度上来说，这样简化了一些功能，但是，嵌入式的系统中存储还是很宝贵的，我如果做设计的话这样的接口可能会直接放弃不用了。

这里面有一个判断就是关于静态创建时候buffer的指定判断，如果buffer已经分配了那么就以静态的方式创建。接下来，测试一下buffer的具体信息。

把任务创建时候的信息以全局变量的形式保存下来，之后在任务中打印出来。在修改这段代码的时候我发现了一个错误的惯性思维。当我看了CubeIDE封装的线程创建的函数中，定义信息使用了const，就错误的以为这个肯定会存储在flash之中占用一部分存储信息，而且会是全局变量。其实，这里的存储信息占用还是有的，flash也用到了，但是不是全局变量的区域。因此，在打印这部分信息的时候需要通过一个全局量临时传递一下。

这里打印出来的buffer信息看，的确是无效的。也就是说，默认的线程创建方式中任务以动态的形式进行了创建。这也说明，前面采用的FreeRTOS的原始的接口形式是正确的。

回看原来的接口，我发现其实任务的优先级可能是做了处理的并不是直接的一个数字。这里做一个测试，看看默认的配置下的任务优先级。

任务优先级的设置以及获取的接口这里都使能了，由此，可以增加如下的测试代码进行测试。

以上是增加的测试代码。

以上是测试结果。从测试结果看得出来，采用CubeIDE创建出来的osPriorityNormal优先级的任务优先级是3，尽管这个osPriorityNormal的数值是0。

为了做一个对比测试，我采用FreeRTOS创建任务的时候直接采用0优先级，出现的就是优先级为0的task。接下来看看，CubeIDE的代码在什么地方修改了优先级。

从代码设计的部分，可以看到这里的优先级其实是有一个计算过程的。

通过上面的代码分析，能够知道这个优先级数值传入之后，其实是进行了一个优先级数值的提升的。提升的数值为3，也就是增加3，因此能够得出前面的测试数据。

因此，一个对等的FreeRTOS的任务创建应该是这样子。而上面的优先级计算函数由于是一个static修饰的，因此无法在这里直接调用。

这是修改后的测试效果，看得出来已经一致了。