1309_STM32F103上增加GPIO的翻转并用FreeRTOS调度测试

全部学习汇总： GitHub - GreyZhang/g_stm32f103: some hack for stm32f103

今天的这个测试属于嵌入式的hello world实现，这个在FreeRTOS的一些社区中也这么称呼，可以看得出来这个用法的通用性。之前，我已经尝试了 类似的测试了，但是那时候的测试并不是基于FreeRTOS。因此，这一次还是要做一个新的尝试。

从另一个方面讲，之前我尝试学习S32K144的开发板的时候，很多代码都丢失了。我看很多人看了我的学习笔记之后有疑惑但是找不到当时的代码了，而我的板子卖掉之后也不再关注这样的信息，这样就导致了一些信息难以找回。趁着这一次机会，我会把我调试用的代码传一份到我的GitHub上面。

我的代码驱动基本上是使用CubeIDE来生成的，但是由于中间我需要改一些代码，而CubeIDE在代码生成的时候可能会导致我的一些代码格式的变化或者内容的修改。因此，CubeIDE我只是拿来做代码生成，我的编译直接用了gcc的命令行环境来做编译。我的机器上安装了相对来说比较新的gcc for arm的编译器，通过简单的功能测试发现编译的结果与CubeIDE中所带的gcc的版本没有太大的差异。这样正好也把我的工具链与其他的一些芯片实现了一个统一。

既然增加了OS，而我一直在关注堆栈的使用。趁着这个测试，一起也看一下相应的信息。上面的结果是我在OS的task中还没有增加GPIO的测试代码的情况。

接下来，我增加了一个测试的函数。

相应的函数由OS的task来管理，每次执行之后延时1000ms，这样其实是会看到一个大概2S周期的闪烁效果。

从编译的运行效果看，其实这样的功能增加并没有给OS的堆栈带来什么负担。而且，从板子的运行效果看，现在的LED闪烁已经奏效了。值得一说的是，我上面的资源使用其实是建立在开了编译器后话的前提之下的，在此之前，存储的使用还不是这么乐观。目前，每一个任务的堆栈分配单位是160，但是实际使用的量并不多。

为了对比，看一下没有开启优化的时候的效果。从这个效果看，其实开启编译器的优化对于存储的占用优化还是很有帮助的。