前言
控制台,做为一种人机交互接口,相较于其他接口(显示器、网络终端),可能是最简单的。它耗用资源少,容易配置,几乎是任何芯片会自带的外设。而且可以很容易和计算机建立连接。因而,串口控制台可能是程序员进行人机交互的首选。
启用控制台,可以帮我们在系统全速运行时窥探系统运行状况。可以监测其它外设或者组件初始化过程。
一月份,笔者在论坛发的 serialX 串口驱动反响很大,应该会让很多人眼前一亮(老王卖瓜)。当初,决定费力研究它的初衷很简单 —— 应用和驱动弱耦合、真阻塞非阻塞特性。这两个月来,笔者一直在实际项目中使用它,而且应用到了控制台上,同时发现了一些问题。
控制台串口问题汇总
问题一、任务调度器启动前 `rt_kprintf` 死循环到 tx 函数
问题原因是,笔者打开控制台串口设定的 flag 是阻塞写方式,无论是中断发送还是 DMA 发送都依赖中断。但是任务调度器启动前是关全局中断的,这样导致触发发送失败,发送缓冲区满了以后再有写动作就会永久死到 tx 函数里。
> 应对之策:任务调度器启动前只能使用 poll 发送模式。任务调度器启动后或临启动时切换到中断或 DMA 模式。
问题二、出现异常后,`rt_kprintf` 无输出
这个现象和上一条有点儿类似。不同的是,虽然全局中断是开着的,但是串口中断优先级不足,导致控制台设备停止工作。
在 arm9 架构上出现 Undef SWI PAbt DBbt 等等 trap 后,串口外设中断级别不足,导致这些 trap 中的 printf 输出失效。
> 应对之策:unset 控制台串口设备,或者将控制台串口切换到 poll 发送模式。
问题三、`rt_hw_interrupt_disable` 之后 `rt_kprintf` 无输出
这个和“问题一”是一样的,根本原因是,非 poll 模式必须有中断它才能工作,关中断以后设备停止工作。
> 应对之策:尽量减少关中断时间;避免在关中断之后写串口设备。
问题四、遇到 `_rt_scheduler_stack_check` 也会停止输出
因为 `_rt_scheduler_stack_check` 函数最后先关全局中断,然后进入 while 死循环。这个时候串口中断肯定也失效了。
> 应对之策:关全局中断前,先 flush 串口设备。让串口把 “stack overflow” 的提示信息输出完。
问题五、打断点后 `rt_kprintf` 输出不完整,部分数据没输出到控制台
因为 debug 断点停止的时候,前边 printf 缓存的数据可能还没来得及送到串口移位寄存器,cpu 的时钟被断点打断停止运行了,导致部分数据没输出。继续运行程序就可以出现剩余信息输出。这是非阻塞设备的特性。
以上这些问题是所有非 poll 非阻塞设备输出都会遇到的现象。在 RTOS 系统里,应用程序不可避免地要和中断打交道,了解中断对我们编程思想的影响很重要。
完整解决方案
rt_device 增加 flush 接口
flush 接口对带缓存设备是极其有用的,无论是阻塞还是非阻塞模式,我们总有需求要求*在某个代码节点设备的缓存已经是空的*,*或者要求实现通信同步*。
`struct rt_device` 增加 `flush` 接口
struct rt_device
{
...
rt_err_t (*flush) (rt_device_t dev);
...
};
serialX.c 添加 `flush` 回调函数实现 `static rt_err_t rt_serial_flush(struct rt_device *dev)` ,用于等待串口驱动层发送缓存发完数据。另外底层外设也增加 flush 接口,用于等待串口发送寄存器中的*最后一个字节数据*被搬到了移位发送寄存器中。
console 添加 unset flush 控制台设备接口
void rt_console_unset_device()
{
if (_console_device != RT_NULL)
{
/* close old console device */
rt_device_close(_console_device);
_console_device = RT_NULL;
}
}
RT_WEAK void rt_hw_console_flush()
{
/* empty console output */
}
void rt_console_flush()
{
#ifdef RT_USING_DEVICE
if (_console_device == RT_NULL)
{
rt_hw_console_flush();
}
else
{
rt_device_flush(_console_device);
}
#else
rt_hw_console_flush();
#endif /* RT_USING_DEVICE */
}
有 set 也有 unset, 不是吗? unset 是为了调用 `rt_hw_console_output` 而不是 `rt_device_write` 输出打印信息。
`rt_console_flush` 既考虑启用设备框架也考虑未启用设备框架两种情况。`rt_device_flush(_console_device)` 会调用上文的 `rt_serial_flush` ;`rt_hw_console_flush` 和 `rt_hw_console_output` 类似用于不使用设备框架,自定义 `rt_kprintf` 底层接口时要实现的。视实际情况实现 `rt_hw_console_flush` 。例如 NUC970 UART 自带了 FIFO ,需要实现 `rt_hw_console_flush`
> 如果使用了 DMA 模式,底层实现 flush 还是有点儿难度的。需要花点儿心思。
延迟 `rt_console_set_device` 调用
挪到任务调度器启动前,那么之前的控制台输出怎么实现?答案是使用 `rt_hw_console_output`。如上所说,第一次使用 poll 模式打开控制台串口,到这里临启动任务调度器的时候再次用 中断/DMA 模式打开控制台串口也可以。但是,多次用不同模式打开同一个设备会引入另外的问题,要不要先关闭上次的 open 呢?假如之前没有打开过呢?
/* Set the shell console output device */
#ifdef RT_USING_CONSOLE
rt_console_flush();
rt_console_set_device(RT_CONSOLE_DEVICE_NAME);
#endif
/* start scheduler */
rt_system_scheduler_start();
这时候,我们的 `rt_console_set_device` 可以用任何模式打开控制台串口设备
if (rt_device_open(new_device, RT_DEVICE_OFLAG_RDWR | RT_DEVICE_FLAG_STREAM
| RT_DEVICE_FLAG_INT_RX
| RT_DEVICE_FLAG_INT_TX
) == RT_EOK) {
_console_device = new_device;
}
或者,先用 poll 模式 set console device
/* set new console device */
if (rt_device_open(new_device, RT_DEVICE_OFLAG_RDWR | RT_DEVICE_FLAG_STREAM
) == RT_EOK) {
_console_device = new_device;
}
当第二次 reset 的时候,需要先 unset (用到了上面提到的 `rt_console_unset_device`),因为 `rt_console_set_device` 不允许重复 set 同一个设备,也没法修改打开设备的参数。写另外一个 set api 也就变的必要了
if (rt_device_open(new_device, RT_DEVICE_OFLAG_RDWR | RT_DEVICE_FLAG_STREAM
| RT_DEVICE_FLAG_INT_RX
| RT_DEVICE_FLAG_INT_TX
) == RT_EOK) {
_console_device = new_device;
}
但是,我为什么不喜欢这种方式呢?
1. board 初始化阶段需要初始化系统时钟、倍频 cpu 时钟、 `rt_hw_systick_init`、 `rt_system_heap_init`、 `rt_hw_pin_init`、还有 `rt_hw_usart_init` 设备,可能还有 `rt_console_set_device`。为了能第一时间使用上控制台串口,`rt_hw_usart_init` 必须尽早执行,然后是 `rt_console_set_device` 。
2. 但是 uart 设备可能用到动态申请内存,这样就必然要求 `rt_system_heap_init` 先于 `rt_hw_usart_init` 。
3. 初始化系统时钟、倍频 cpu 时钟、 `rt_hw_systick_init`、 `rt_system_heap_init`、 `rt_hw_usart_init` 。也只能这样了,前边几步的串口打印需求就忽略了吧,`rt_system_heap_init`->`rt_memheap_init` 里的 `RT_DEBUG_LOG` 调试信息就忽略了吧。
如果不着急用串口设备,先简单初始化串口外设,让 `rt_hw_console_output` 以最快的速度工作起来。如此一来,初始化流程可能就可以变成,初始化系统时钟、倍频 cpu 时钟、 **`rt_hw_console_init`**、 `rt_hw_systick_init`、... 。后面是初始化顺序都无关紧要了,而且所有的打印信息需求都可以满足。最后在任务调度器启动前选择某个串口设备做控制台串口,将会避免前文说到的*问题一*。
进入不可恢复状态的处理
- 以 `_rt_scheduler_stack_check` 为例,关中断前先 flush 控制台。
rt_console_flush();
level = rt_hw_interrupt_disable();
while (level);
- 还比如 SWI 异常,`rt_hw_cpu_shutdown` 也会关中断,进入 while 死循环。先 unset 控制台,使用 `rt_hw_console_output` 进行 poll 输出之后的输出需求。
void rt_hw_trap_swi(struct rt_hw_register *regs)
{
rt_console_unset_device();
rt_hw_show_register(regs); rt_kprintf("software interrupt\n");
rt_hw_cpu_shutdown();
}
**注:为避免因中断优先级,引起串口设备中断得不到响应,在中断响应里切忌调用 `rt_console_flush` 函数**
结束
控制台串口在系统中扮演着极其重要的角色,对其处理不当,会引起各种依赖问题。有人就有疑虑了,做其它通信用时 serialX 会不会存在同样的隐患?笔者保证,您不在中断响应里调用 `rt_device_flush` 就不会出现以上所有列出来的问题。
笔者下一篇计划聊聊内核启动流程的问题,虽然之前发过一篇文章 [rt-thread 系统启动及 SysTick 初始化流程优化可行性分析]( https://club.rt-thread.org/ask/article/2881.html ),里面提了一种可能的系统启动流程,当时只是一种想法,并不系统。再写一篇,笔者希望把需要考虑的问题以及优缺点系统化地说明白,可能还会提及控制台串口设备,以及控制台对内核启动流程的影响。
相关文章:
rt-thread 驱动篇(一) serialX 框架理论
rt-thread 驱动篇(二) serialX 理论实现
rt-thread 驱动篇(三) serialX 压力测试
rt-thread 驱动篇(四)serialX 多架构适配
rt-thread 驱动篇(五)serialX 小试牛刀
审核编辑:汤梓红
-
人机交互
+关注
关注
12文章
1206浏览量
55384 -
控制台
+关注
关注
0文章
85浏览量
10349 -
串口
+关注
关注
14文章
1551浏览量
76439 -
RT-Thread
+关注
关注
31文章
1285浏览量
40093 -
serialX
+关注
关注
0文章
7浏览量
808
发布评论请先 登录
相关推荐
评论