前言

控制臺，做為一種人機交互接口，相較于其他接口（顯示器、網絡終端），可能是最簡單的。它耗用資源少，容易配置，幾乎是任何芯片會自帶的外設。而且可以很容易和計算機建立連接。因而，串口控制臺可能是程序員進行人機交互的首選。

啟用控制臺，可以幫我們在系統全速運行時窺探系統運行狀況。可以監測其它外設或者組件初始化過程。

一月份，筆者在論壇發的 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 小試牛刀

審核編輯：湯梓紅