rt-thread 驅(qū)動(dòng)篇（六）serialX弊端及解決方法

前言

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

啟用控制臺(tái)，可以幫我們?cè)谙到y(tǒng)全速運(yùn)行時(shí)窺探系統(tǒng)運(yùn)行狀況?？梢员O(jiān)測(cè)其它外設(shè)或者組件初始化過(guò)程。

一月份，筆者在論壇發(fā)的 serialX 串口驅(qū)動(dòng)反響很大，應(yīng)該會(huì)讓很多人眼前一亮（老王賣瓜）。當(dāng)初，決定費(fèi)力研究它的初衷很簡(jiǎn)單 —— 應(yīng)用和驅(qū)動(dòng)弱耦合、真阻塞非阻塞特性。這兩個(gè)月來(lái)，筆者一直在實(shí)際項(xiàng)目中使用它，而且應(yīng)用到了控制臺(tái)上，同時(shí)發(fā)現(xiàn)了一些問(wèn)題。

控制臺(tái)串口問(wèn)題匯總

問(wèn)題一、任務(wù)調(diào)度器啟動(dòng)前 `rt_kprintf` 死循環(huán)到 tx 函數(shù)

問(wèn)題原因是，筆者打開(kāi)控制臺(tái)串口設(shè)定的 flag 是阻塞寫方式，無(wú)論是中斷發(fā)送還是 DMA 發(fā)送都依賴中斷。但是任務(wù)調(diào)度器啟動(dòng)前是關(guān)全局中斷的，這樣導(dǎo)致觸發(fā)發(fā)送失敗，發(fā)送緩沖區(qū)滿了以后再有寫動(dòng)作就會(huì)永久死到 tx 函數(shù)里。

> 應(yīng)對(duì)之策：任務(wù)調(diào)度器啟動(dòng)前只能使用 poll 發(fā)送模式。任務(wù)調(diào)度器啟動(dòng)后或臨啟動(dòng)時(shí)切換到中斷或 DMA 模式。

問(wèn)題二、出現(xiàn)異常后，`rt_kprintf` 無(wú)輸出

這個(gè)現(xiàn)象和上一條有點(diǎn)兒類似。不同的是，雖然全局中斷是開(kāi)著的，但是串口中斷優(yōu)先級(jí)不足，導(dǎo)致控制臺(tái)設(shè)備停止工作。

在 arm9 架構(gòu)上出現(xiàn) Undef SWI PAbt DBbt 等等 trap 后，串口外設(shè)中斷級(jí)別不足，導(dǎo)致這些 trap 中的 printf 輸出失效。

> 應(yīng)對(duì)之策：unset 控制臺(tái)串口設(shè)備，或者將控制臺(tái)串口切換到 poll 發(fā)送模式。

問(wèn)題三、`rt_hw_interrupt_disable` 之后 `rt_kprintf` 無(wú)輸出

這個(gè)和“問(wèn)題一”是一樣的，根本原因是，非 poll 模式必須有中斷它才能工作，關(guān)中斷以后設(shè)備停止工作。

> 應(yīng)對(duì)之策：盡量減少關(guān)中斷時(shí)間；避免在關(guān)中斷之后寫串口設(shè)備。

問(wèn)題四、遇到 `_rt_scheduler_stack_check` 也會(huì)停止輸出

因?yàn)?`_rt_scheduler_stack_check` 函數(shù)最后先關(guān)全局中斷，然后進(jìn)入 while 死循環(huán)。這個(gè)時(shí)候串口中斷肯定也失效了。

> 應(yīng)對(duì)之策：關(guān)全局中斷前，先 flush 串口設(shè)備。讓串口把 “stack overflow” 的提示信息輸出完。

問(wèn)題五、打斷點(diǎn)后 `rt_kprintf` 輸出不完整，部分?jǐn)?shù)據(jù)沒(méi)輸出到控制臺(tái)

因?yàn)?debug 斷點(diǎn)停止的時(shí)候，前邊 printf 緩存的數(shù)據(jù)可能還沒(méi)來(lái)得及送到串口移位寄存器，cpu 的時(shí)鐘被斷點(diǎn)打斷停止運(yùn)行了，導(dǎo)致部分?jǐn)?shù)據(jù)沒(méi)輸出。繼續(xù)運(yùn)行程序就可以出現(xiàn)剩余信息輸出。這是非阻塞設(shè)備的特性。

以上這些問(wèn)題是所有非 poll 非阻塞設(shè)備輸出都會(huì)遇到的現(xiàn)象。在 RTOS 系統(tǒng)里，應(yīng)用程序不可避免地要和中斷打交道，了解中斷對(duì)我們編程思想的影響很重要。

完整解決方案

rt_device 增加 flush 接口

flush 接口對(duì)帶緩存設(shè)備是極其有用的，無(wú)論是阻塞還是非阻塞模式，我們總有需求要求*在某個(gè)代碼節(jié)點(diǎn)設(shè)備的緩存已經(jīng)是空的*，*或者要求實(shí)現(xiàn)通信同步*。

`struct rt_device` 增加 `flush` 接口

struct rt_device
{
...
   rt_err_t  (*flush)  (rt_device_t dev);
...
};

serialX.c 添加 `flush` 回調(diào)函數(shù)實(shí)現(xiàn) `static rt_err_t rt_serial_flush(struct rt_device *dev)` ，用于等待串口驅(qū)動(dòng)層發(fā)送緩存發(fā)完數(shù)據(jù)。另外底層外設(shè)也增加 flush 接口，用于等待串口發(fā)送寄存器中的*最后一個(gè)字節(jié)數(shù)據(jù)*被搬到了移位發(fā)送寄存器中。

console 添加 unset flush 控制臺(tái)設(shè)備接口

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 是為了調(diào)用 `rt_hw_console_output` 而不是 `rt_device_write` 輸出打印信息。

`rt_console_flush` 既考慮啟用設(shè)備框架也考慮未啟用設(shè)備框架兩種情況。`rt_device_flush(_console_device)` 會(huì)調(diào)用上文的 `rt_serial_flush` ；`rt_hw_console_flush` 和 `rt_hw_console_output` 類似用于不使用設(shè)備框架，自定義 `rt_kprintf` 底層接口時(shí)要實(shí)現(xiàn)的。視實(shí)際情況實(shí)現(xiàn) `rt_hw_console_flush` 。例如 NUC970 UART 自帶了 FIFO ，需要實(shí)現(xiàn) `rt_hw_console_flush`

> 如果使用了 DMA 模式，底層實(shí)現(xiàn) flush 還是有點(diǎn)兒難度的。需要花點(diǎn)兒心思。

延遲 `rt_console_set_device` 調(diào)用

挪到任務(wù)調(diào)度器啟動(dòng)前，那么之前的控制臺(tái)輸出怎么實(shí)現(xiàn)？答案是使用 `rt_hw_console_output`。如上所說(shuō)，第一次使用 poll 模式打開(kāi)控制臺(tái)串口，到這里臨啟動(dòng)任務(wù)調(diào)度器的時(shí)候再次用 中斷/DMA 模式打開(kāi)控制臺(tái)串口也可以。但是，多次用不同模式打開(kāi)同一個(gè)設(shè)備會(huì)引入另外的問(wèn)題，要不要先關(guān)閉上次的 open 呢？假如之前沒(méi)有打開(kāi)過(guò)呢？

   /* 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();

這時(shí)候，我們的 `rt_console_set_device` 可以用任何模式打開(kāi)控制臺(tái)串口設(shè)備

   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;
       }

當(dāng)?shù)诙?reset 的時(shí)候，需要先 unset （用到了上面提到的 `rt_console_unset_device`），因?yàn)?`rt_console_set_device` 不允許重復(fù) set 同一個(gè)設(shè)備，也沒(méi)法修改打開(kāi)設(shè)備的參數(shù)。寫另外一個(gè) 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 初始化階段需要初始化系統(tǒng)時(shí)鐘、倍頻 cpu 時(shí)鐘、 `rt_hw_systick_init`、 `rt_system_heap_init`、 `rt_hw_pin_init`、還有 `rt_hw_usart_init` 設(shè)備，可能還有 `rt_console_set_device`。為了能第一時(shí)間使用上控制臺(tái)串口，`rt_hw_usart_init` 必須盡早執(zhí)行，然后是 `rt_console_set_device` 。
2. 但是 uart 設(shè)備可能用到動(dòng)態(tài)申請(qǐng)內(nèi)存，這樣就必然要求 `rt_system_heap_init` 先于 `rt_hw_usart_init` 。
3. 初始化系統(tǒng)時(shí)鐘、倍頻 cpu 時(shí)鐘、 `rt_hw_systick_init`、 `rt_system_heap_init`、 `rt_hw_usart_init` 。也只能這樣了，前邊幾步的串口打印需求就忽略了吧，`rt_system_heap_init`->`rt_memheap_init` 里的 `RT_DEBUG_LOG` 調(diào)試信息就忽略了吧。

如果不著急用串口設(shè)備，先簡(jiǎn)單初始化串口外設(shè)，讓 `rt_hw_console_output` 以最快的速度工作起來(lái)。如此一來(lái)，初始化流程可能就可以變成，初始化系統(tǒng)時(shí)鐘、倍頻 cpu 時(shí)鐘、 **`rt_hw_console_init`**、 `rt_hw_systick_init`、... 。后面是初始化順序都無(wú)關(guān)緊要了，而且所有的打印信息需求都可以滿足。最后在任務(wù)調(diào)度器啟動(dòng)前選擇某個(gè)串口設(shè)備做控制臺(tái)串口，將會(huì)避免前文說(shuō)到的*問(wèn)題一*。

進(jìn)入不可恢復(fù)狀態(tài)的處理

- 以 `_rt_scheduler_stack_check` 為例，關(guān)中斷前先 flush 控制臺(tái)。

   rt_console_flush();
   level = rt_hw_interrupt_disable();
   while (level);

- 還比如 SWI 異常，`rt_hw_cpu_shutdown` 也會(huì)關(guān)中斷，進(jìn)入 while 死循環(huán)。先 unset 控制臺(tái)，使用 `rt_hw_console_output` 進(jìn)行 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();
}

**注：為避免因中斷優(yōu)先級(jí)，引起串口設(shè)備中斷得不到響應(yīng)，在中斷響應(yīng)里切忌調(diào)用 `rt_console_flush` 函數(shù)**

結(jié)束

控制臺(tái)串口在系統(tǒng)中扮演著極其重要的角色，對(duì)其處理不當(dāng)，會(huì)引起各種依賴問(wèn)題。有人就有疑慮了，做其它通信用時(shí) serialX 會(huì)不會(huì)存在同樣的隱患？筆者保證，您不在中斷響應(yīng)里調(diào)用 `rt_device_flush` 就不會(huì)出現(xiàn)以上所有列出來(lái)的問(wèn)題。

筆者下一篇計(jì)劃聊聊內(nèi)核啟動(dòng)流程的問(wèn)題，雖然之前發(fā)過(guò)一篇文章 [rt-thread 系統(tǒng)啟動(dòng)及 SysTick 初始化流程優(yōu)化可行性分析]( https://club.rt-thread.org/ask/article/2881.html )，里面提了一種可能的系統(tǒng)啟動(dòng)流程，當(dāng)時(shí)只是一種想法，并不系統(tǒng)。再寫一篇，筆者希望把需要考慮的問(wèn)題以及優(yōu)缺點(diǎn)系統(tǒng)化地說(shuō)明白，可能還會(huì)提及控制臺(tái)串口設(shè)備，以及控制臺(tái)對(duì)內(nèi)核啟動(dòng)流程的影響。

相關(guān)文章：

rt-thread 驅(qū)動(dòng)篇（一） serialX 框架理論

rt-thread 驅(qū)動(dòng)篇（二） serialX 理論實(shí)現(xiàn)

rt-thread 驅(qū)動(dòng)篇（三） serialX 壓力測(cè)試

rt-thread 驅(qū)動(dòng)篇（四）serialX 多架構(gòu)適配

rt-thread 驅(qū)動(dòng)篇（五）serialX 小試牛刀

審核編輯：湯梓紅