为STM32F0搭建FreeRTOS实录

最近为实现小应用囤了一点尚属低价的STM32F030C8T6单片机，自制了最小系统板，也就顺带捣鼓在这种小芯片上如何移植FreeRTOS。其实由于这款单片机SRAM容量太小，再上FreeRTOS有点不划算了，但这个移植的过程却对入门FreeRTOS很有帮助。

工具链：Keil MDK 5.34 + STM32CubeMX 6.3.0 + 自制最小系统板（如图）

一、配置管脚+生成代码

打开Keil，选择单片机（我这里就选STM32F030C8T6），接着在Manage Run-Time Environment中选择软件组件，选中CMSIS->CORE、Device->STM32CubeHAL、Device->Startup以及下面STM32Cube Framework (API)里的STM32CubeMX。注意，不要马上点击确定！！！

我们先要点STM32CubeMX旁边的绿色启动按钮，启动CubeMX配置。CubeMX要从意法半导体官网下载安装。

作为一个简单的例子，我们可以只配置最少的管脚，并且只用片内振荡器。我在PC13上挂了一个LED，将该管脚配置为GPIO_Output，然后启用USART1，配置为异步(UART)模式，波特率115200Bits/s。默认条件下，PA9被设置为TX，PA10为RX。
(配置GPIO和UART)

接着我们用STM32CubeMX生成FreeRTOS的代码。左侧目录中点开Middleware，就有FreeRTOS，点中它，接口(Interface)选择CMSIS_V2。在下面设置参数中内存管理里，设置总堆大小(TOTAL_HEAP_SIZE)为2048字节，内存管理方法(Memory Management scheme)为heap_1。
(配置FreeRTOS)

这里我们插句嘴，说明一下我们在设置什么。尽管我们要用FreeRTOS，ARM为Cortex M系列的芯片还另外开发了一套API，就是CMSIS，这样，即使内核操作系统不同，在用户级的代码却可以共享同一套API，降低了代码移植的难度。待会我们也可以看到，我们是用CMSIS的API创建任务线程，而非直接用FreeRTOS的API；但本质上，只是一层封装，最后还是要调用FreeRTOS的API的。

内存管理是这里的关键。FreeRTOS提供了多种内存管理方式，我们这次就用最简单的Heap_1，它只支持malloc，不支持free，也就是说建立线程之后，即使要删除该线程，也没法释放其资源，但对我们已经足够。

接着我们点Tasks and Queues选项卡，去创建任务。这里面已经有一个defaultTask，我把它改名Task1，并把入口函数改名task1fxn；再创建第二个任务task2，入口函数task2fxn。

现在我们看一下FreeRTOS Heap Usage，可以看到每个任务都占了632字节的RAM，堆栈还剩784字节。

至此，其实STM32CubeMX中的设置已经基本完毕。点击GENERATE CODE，它给出提示，在使用RTOS时，强烈建议改用HAL Timebase Source而非直接用Systick。这里我暂时不知道为什么，不过为了尽快拉通，就按它说的做，把Timebase Source改为TIM1。然后生成代码，退出STM32CubeMX，在Keil中Manage Run-Time Environment点击OK。

二、FreeRTOS代码加入工作区

此时代码已经生成，但FreeRTOS的代码却还没加进来。在Project栏中，为我们的工程加入几个分组：CMSIS_V2、FreeRTOS_src和FreeRTOS_inc。命名并不一定如此，只是看着方便。然后找到生成的FreeRTOS代码，在（工程目录）\RTE\Device\STM32F030C8Tx\ STCubeGenerated\Middlewares\Third_Party\FreeRTOS\Source中（对的，非常深）。

其中，CMSIS_RTOS_V2文件夹下定义的就是CMSIS_V2的API，加入CMSIS_V2分组中；这个目录下所有.c文件都是FreeRTOS的代码，加入FreeRTOS_src分组；…/protable/MemMang文件夹下是FreeRTOS的5种内存管理方式源代码，我们采用Heap_1，就把heap_1.c加入FreeRTOS_src，别的不管；接着在…/protable/RVDS/ARM_CM0下是与硬件接口相关的代码，prot.c加入FreeRTOS_src，portmacro.h加入FreeRTOS_inc，再把…/include文件夹下的所有.h文件都加入FreeRTOS中。最后，在编译器选项中把包含了FreeRTOS头文件的3个文件夹加入Include Paths。

此时配置本该成功了，可以编译一次，却编译错误，所有错误都来自port.c。原来，这个接口代码有大量的c语言中嵌套汇编的操作，这些汇编指令编译器都没有被正确识别。查询网上的信息，似乎老版本的MDK编译器还是可以编译这些代码的，STM32CubeMX却还是按老版本生成代码的，但最新的反而不支持了。

此时我猜想，Keil应该是把自己的编译器变得更“标准”导致无法编译的。那什么是最标准的代码呢？当然是GCC能编译的代码就是最标准的代码啦~从网络上下载到FreeRTOSv10.0.1的官方代码，其中portable文件夹就有十几种编译器的代码，包含GCC，用GCC/ARM_CM0的port.c和portmacro.h替换我们工程下的接口，再编译，果然成功。

三、线程代码编写

为了有比较明显的实验现象，我在main.c编写了一个串口输出函数：

void UART_print(UART_HandleTypeDef *huart, uint8_t *pData)
{uint16_t len = 0;while (pData[len]) len++;HAL_UART_Transmit(huart, pData, len, 0x7fff); // enough time to transmit
}

以及两个线程的函数：

void task1_fxn(void *argument)
{/* Infinite loop */for(;;){osDelay(1000); // delay 1000msUART_print(&huart1,"task1: Hello world\n\r");HAL_GPIO_TogglePin(GPIOC,GPIO_PIN_13);}
}

void task2_fxn(void *argument)
{/* Infinite loop */for(;;){osDelay(1000); // delay 1000msUART_print(&huart1,"task2: Hello world\n\r\n\r");}
}

在task1中，我们不仅串口输出，还改变GPIO的电平；task2中，则会换行两次方便识别。osDelay()就是CMSIS的API，提供类似sleep的进程挂起作用，延迟单位是ms。接上串口，看到串口输出数据，表明FreeRTOS已经正常启动，且两个线程被轮流调用了，移植成功。