使用CubeIDE增加FreeRTOS的功能
全部学习汇总：GreyZhang/g_stm32f103: some hack for stm32f103 ()
CubeIDE中提供了FreeRTOS的移植模块，印象中之前我尝试了部分STM32F40X的开发板的使用，也用CubeIDE中的FreeRTOS做过简单的调度。那时候的软件了解其实还不是很深，CubeIDE的版本应该也是很老的了。
保存进行代码生成的时候，出现了这样的提示。这么看，可能这个tick时钟并不是很精准，不然的话找不到什么理由必须得切换。
这样，先还掉这个时基源。这么看，或许接下来还得去配置一个timer的驱动出来。
CubeIDE的提示还是很精细的，按照提示来进行修改找配置参数的位置的时候很容易。这里，把这个LIB的使用参数设置为Enable。
之后，查看了一下TIM（timer）的配置，发现FreeRTOS使用的这个定时器已经配置好了。看起来，这个IDE中带的这个配置工具的人性化程度的确是很好。也可以理解，为什么STM32的MCU销量这么好了。在开发简单的功能的时候，极大地降低了开发人员的能力要求，可以把更多的精力放到业务逻辑的开发上。
接下来，测试一下这OS的基础功能。
这是OS任务的创建，看起来不是一个FreeRTOS的官方的接口，而是被这个SDK进行了二次封装。拆解的话肯定也容易，暂时先按照这个模式来处理。后面或许我会直接选择使用FreeRTOS最原始的接口形式，这样在不同的平台中可能会有更好的一致性。
这里，我修改了 堆栈的分配大小，由原来的128设置为了256。因为测试的时候一个简单的printf只有一次打印成功后面直接罢工了。
这里是OS的调度器启动的时候，其实调度器启动了后面的这个死循环应该也就没有执行的机会了。暂时代码先留在这里，后面再做清理。
这是前面创建的任务，任务中的内容我做了修改。这样，这个任务可以以没隔100ms实现一次打印，打印的内容就是上面的这个printf的信息。
这是打印出来的效果，看起来基本的功能是有了。从这个结果看，这里面还有时间偏差存在。这个先不去做细致分析了，先确认一下任务的堆栈占用是不是因为printf导致的。
发现了在CubeIDE中有一个存储的分析工具，从这里看的话其实还是OS用到的delay函数耗费了主要的存储。
进一步测试，发现这个打印函数其实也有很多的消耗。看起来，后面的分析还是需要进一步深入，这些问题的根本原因都应该分析出来，不然FreeRTOS的机理甚至说应用都是浮于表面深入不下去的。
最后看了一下这个捉襟见肘的RAM，现在还真是小有压力。不过，能够完全击败Arduino了就是高强配置了，这一次看看如何能够榨干这个MCU的功能。
