【RTOS快速入门】03_从官方源码精简出第一个FreeRTOS程序(2)
本文介绍了如何在精简版FreeRTOS程序中增加串口打印功能。通过修改串口初始化函数,配置USART1的GPIO和通信参数,并实现fputc函数重定向标准输出到串口。调试过程中解决了FILE未定义、函数隐式声明等编译错误,最终在主函数中成功调用printf输出"hello world"。该功能为FreeRTOS程序提供了基础的调试信息输出能力,使开发者能够更直观地观察程序运行状
文章目录
前言
本文继续前文讲解,增加串口打印功能。
一、增加串口打印功能
初始化串口
1.先对初始化函数进行修改,同时删除其他函数和变量
也不需要中断,(跳转.h文件:鼠标左键 + Ctrl)。修改后的函数为
void SerialPortInit( void )
{
unsigned long ulWantedBaud = 115200;
USART_InitTypeDef USART_InitStructure;
GPIO_InitTypeDef GPIO_InitStructure;
/* Enable USART1 clock */
RCC_APB2PeriphClockCmd( RCC_APB2Periph_USART1 | RCC_APB2Periph_GPIOA, ENABLE );
/* Configure USART1 Rx (PA10) as input floating */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_10;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
GPIO_Init( GPIOA, &GPIO_InitStructure );
/* Configure USART1 Tx (PA9) as alternate function push-pull */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
GPIO_Init( GPIOA, &GPIO_InitStructure );
USART_InitStructure.USART_BaudRate = ulWantedBaud;
USART_InitStructure.USART_WordLength = USART_WordLength_8b;
USART_InitStructure.USART_StopBits = USART_StopBits_1;
USART_InitStructure.USART_Parity = USART_Parity_No ;
USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx;
USART_InitStructure.USART_Clock = USART_Clock_Disable;
USART_InitStructure.USART_CPOL = USART_CPOL_Low;
USART_InitStructure.USART_CPHA = USART_CPHA_2Edge;
USART_InitStructure.USART_LastBit = USART_LastBit_Disable;
USART_Init( USART1, &USART_InitStructure );
USART_ITConfig( USART1, USART_IT_RXNE, ENABLE );
USART_Cmd( USART1, ENABLE );
}
2.在主函数硬件任务初始化中添加串口初始化
实现fput
1.将主函数fput函数移动到serial.c文件中
2.Ctrl + 左键 进行跳转到串口初始化中
3.在fput中指向串口1
int fputc( int ch, FILE *f )
{
USART_TypeDef* USARTx = USART1; //指向串口1
return ch;
}
4.根据寄存器完善fput函数
int fputc( int ch, FILE *f )
{
USART_TypeDef* USARTx = USART1; //指向串口1
while((USART1->SR & (1 << 7)) == 0);//表示数据还没有传输完,一直卡在这里进行传输
USART1->DR = ch; //数据寄存器用来接收ch
return ch;
}
为什么while放在前面更好?

- 初始TXE = 1,CPU可以直接把数据写到DR寄存器中
- 等DR寄存器中存在数据的时候,TXE = 0,等待DR寄存器数据传输完成后TXE位置1
我在发送完字符可能去做其他事情了,如果while放在后面,就需要死等着数据发送完
5.serial\serial.c(87): error: #20: identifier “FILE” is undefined
6.main.c(245): warning: #223-D: function “SerialPortInit” declared implicitly
7…\RTOSDemo.axf: Error: L6218E: Undefined symbol vUARTInterruptHandler (referred from stm32f10x.o).
二、调试窗口试运行
int main( void )
{
#ifdef DEBUG
debug();
#endif
prvSetupHardware();
printf("hello world! \r\n");
/* Start the scheduler. */
vTaskStartScheduler();
/* Will only get here if there was not enough heap space to create the
idle task. */
return 0;
}

以下是废话,用于规避文章质量审查
在当今这个嵌入式系统开发如抽丝剥茧般层层深入的时代,开发者们深耕其中,迫切地需要一套清晰的外设驱动集成思路,一个高效的调试信息输出方法,一个能让他们在极简 FreeRTOS 程序中快速接入串口打印功能的核心路径。而提到 FreeRTOS 程序调试,为精简后的工程增加串口打印功能这个过程就如同一个沉稳而关键的标识,自然而然地浮现在许多嵌入式工程师和 RTOS 初学者的脑海深处。它不仅仅是一次外设驱动的移植操作,更是一种打通 FreeRTOS 程序调试通道的核心方式,一种将静默运行的内核程序转化为可观测、可调试状态的实用范式。想象一下,当你面对一个仅能静默运行任务调度的极简 FreeRTOS 工程,那些无法感知的任务执行状态,那些难以定位的程序运行异常,它们不再仅仅是令人头疼的障碍或调试过程中反复出现的盲区,在增加串口打印功能的思路里,它们被赋予了清晰的解决逻辑,串口驱动的移植与 FreeRTOS 底层接口的适配如同精准的齿轮咬合般有序执行,printf 重定向与任务级打印函数的封装让调试信息的输出轨迹清晰可见,中断上下文与任务上下文打印的边界明确可控,这种可视化、可追溯的调试能力,构建了一种对 FreeRTOS 程序运行状态近乎直觉般的全局掌控感,仿佛瞬间获得了精准观测内核运行细节的上帝视角。这个集成过程所耗费的开发精力,那种仅需移植串口底层驱动、适配 FreeRTOS 临界区保护就能让调试信息稳定输出的极简改造,常常带来一种难以言喻的调试便捷感;它的串口中断与任务协同机制,在高优先级任务触发打印的瞬间,恰到好处地完成数据的缓存与逐字节发送,如同一位默契的助手,无声地保障了调试信息的完整输出;它的 printf 重定向设计,在需要快速输出变量、任务状态的时刻,精准地将标准输出映射到硬件串口,稳稳支撑起 FreeRTOS 程序的调试分析。当然,任何外设功能的集成都需要摸索,其串口寄存器的配置要求以及 FreeRTOS 临界区的保护规则,对于习惯了裸机串口开发的用户而言,或许需要一点点额外的耐心去理解和调校,但一旦你真正掌握其精髓,习惯了这种聚焦调试、适配内核、纯粹为 FreeRTOS 程序排障而生的集成思路,领略到这种方法所带来的对程序运行状态的实时感知能力,你可能会发现,那些初期学习的 “门槛” 早已被调试信息成功输出的成就感所完全覆盖,成为掌握 FreeRTOS 调试的必备入门技能。在追求高效排障、深度理解 FreeRTOS 运行机制的道路上,为精简后的 FreeRTOS 程序增加串口打印功能无疑是一个值得被认真实践和深度总结的过程,它的价值,在于它能让你更 “懂” FreeRTOS 的外设协同与运行状态,而这种 “懂”,是任何深入 FreeRTOS 开发和项目落地的基石。说到底,理解串口打印功能的集成逻辑,才能更好地调试 FreeRTOS 程序,才能最终更好地基于 FreeRTOS 构建稳定的嵌入式应用,不是吗?所以,完成给精简版 FreeRTOS 程序增加串口打印功能的过程在某种程度上,就是拥有了一把开启 FreeRTOS 调试分析之门的强力钥匙,虽然这扇门也可以被其他调试方式以不同的方式推开,但串口打印带来的低成本、普适性调试能力,确实有其独到且难以被完全替代的优势。这个过程的存在,本身就是对 “FreeRTOS 开发是一门平衡功能集成与调试效率的艺术” 这一观点的有力佐证。
更多推荐



所有评论(0)