rt-thread 優(yōu)化系列（六）啟動(dòng)流程重構(gòu)

前言

去年此時(shí)，筆者剛接觸 rt-thread 的時(shí)候，被它的初始化過(guò)程深深折服了。第一次打開一個(gè) rt-thread 的項(xiàng)目，竟然沒找到多線程在哪兒初始化的，"main" 函數(shù)里沒有！
進(jìn)而發(fā)現(xiàn)，"main" 函數(shù)不是我們認(rèn)識(shí)的 "main" 函數(shù)了。在 rt-thread 里，程序進(jìn)入 "main" 函數(shù)之前還有很長(zhǎng)一段路。

目前的初始化流程

見下圖吧，一些主要的過(guò)程已經(jīng)被列出來(lái)了。

從圖中可以看出來(lái)：
1. 任務(wù)調(diào)度器啟動(dòng)前，有很多的初始化工作。
2. `rt_components_board_init` 里還有很多隱含的外設(shè)初始化操作。這個(gè)時(shí)候沒有進(jìn)入多線程環(huán)境。
3. 先創(chuàng)建了三個(gè)默認(rèn)線程（如果啟用了軟定時(shí)器），但并未立馬運(yùn)行，任務(wù)調(diào)度器啟動(dòng)后從中選擇優(yōu)先級(jí)最高的那個(gè)運(yùn)行（可能是 "main" 可能是 "timer"）。
4. "main" 線程啟動(dòng)后，還有很多初始化工作，這個(gè)時(shí)候已經(jīng)進(jìn)入多線程環(huán)境。

這個(gè)流程存在的問(wèn)題：
1. 堆申請(qǐng)被設(shè)計(jì)成多線程安全訪問(wèn)，內(nèi)部有加鎖動(dòng)作，而鎖也是限于在線程上下文使用的。串口驅(qū)動(dòng)申請(qǐng)緩存內(nèi)存卻是在任務(wù)調(diào)度器啟動(dòng)前！
2. 開啟 ulog 后，也有可能出現(xiàn)在任務(wù)調(diào)度器啟動(dòng)之先使用鎖的現(xiàn)象。
3. 還有線程安全版 `rt_kprintf` ，這個(gè)也是考慮只在線程上下文使用，如果開啟了它，任務(wù)調(diào)度器啟動(dòng)前的 `rt_kprintf` 需求被忽略了。

`rt_components_board_init` `rt_components_init` 兩個(gè)函數(shù)可能有很多隱含操作。但是因?yàn)?`rt_components_board_init` 處于非多任務(wù)環(huán)境中，它比 `rt_components_init` 更容易出問(wèn)題。

例如，不能使用加鎖操作、不能使用 `rt_thread_mdelay` `rt_thread_delay` 等延時(shí)操作。

在之前的一篇文章里，[rt-thread 驅(qū)動(dòng)篇（六）serialX弊端及解決方法]( http://wenjunhu.com/d/1850548.html ) 比較全面的梳理了一下串口終端設(shè)備怎么用中斷發(fā)送模式。首先，任務(wù)調(diào)度器啟動(dòng)前是不會(huì)有中斷的，用中斷發(fā)送，可能不會(huì)輸出數(shù)據(jù)，如果是阻塞模式，可能會(huì)永久卡死到這里；如果是非阻塞模式，可能有很多信息被扔掉。

**所以，任務(wù)調(diào)度器啟動(dòng)前，串口終端輸出要么用輪詢輸出，要么給個(gè)很大的輸出緩存**，至于多大合適，這個(gè)誰(shuí)也說(shuō)不好。

還有一個(gè)折中的方法是降低任務(wù)調(diào)度器啟動(dòng)前的打印輸出需求。怎么降低？調(diào)整初始化流程，先啟動(dòng)一個(gè)無(wú)依賴的 idle 線程，把其它操作放到線程中。

新初始化流程設(shè)想

這樣一來(lái)，初始化注冊(cè)外設(shè)設(shè)備的過(guò)程也是在線程上下文環(huán)境了，這個(gè)時(shí)候想用加鎖操作也可以，申請(qǐng)堆內(nèi)存也不會(huì)出現(xiàn) `Function[rt_sem_take] shall not be used before scheduler start`

如果不開啟 RT_DEBUG，堆、pin、UART、控制臺(tái)初始化部分也可以放到 idle 線程里。一年前，筆者在 rt-thread 論壇上提出過(guò)這個(gè)設(shè)想——[
rt-thread 系統(tǒng)啟動(dòng)及 SysTick 初始化流程優(yōu)化可行性分析]( https://club.rt-thread.org/ask/article/ab1c5556dd9f186a.html )。
稍作修改，如下：
1. 配置系統(tǒng)時(shí)鐘，同時(shí)配置 SysTick（同前）；
2. 初始化 rtt 系統(tǒng)調(diào)度器，定時(shí)器鏈表等全局變量；
3. 創(chuàng)建 idle 線程；
4. 啟動(dòng) idle 線程并啟動(dòng) rtt 系統(tǒng)調(diào)度；
5. 由 idle 線程啟用 SysTick 中斷；
6. 由 idle 線程初始化調(diào)試串口；
7. 由 idle 線程初始化內(nèi)存堆；
8. 由 idle 線程調(diào)用執(zhí)行 rt_components_board_init 初始化板級(jí)外設(shè)配置；
9. 由 idle 線程創(chuàng)建 main 和 soft timer 線程。
10. main 線程進(jìn)行組件初始化配置，以及創(chuàng)建其它應(yīng)用線程。

和上面鏈接里提到的流程，修改了開啟 systick 中斷節(jié)點(diǎn)。
同時(shí)如果放棄在初始化配置系統(tǒng)時(shí)鐘時(shí)調(diào)試輸出信息的想法，放棄創(chuàng)建 idle 線程過(guò)程中調(diào)試輸出錯(cuò)誤信息的想法，放棄啟動(dòng)系統(tǒng)任務(wù)調(diào)度器過(guò)程調(diào)試輸出錯(cuò)誤信息的想法后，控制臺(tái)輸出信息也就全處于線程上下文了。

最起碼，我們有以下幾點(diǎn)收獲：
1. 任務(wù)調(diào)度器啟動(dòng)前，不需要開全局中斷。
2. 申請(qǐng)堆內(nèi)存的操作都可以是在線程上下文。
3. 控制臺(tái)串口輸出數(shù)據(jù)可以使用中斷或者 DMA 任意模式。

缺點(diǎn)：idle 線程?？赡鼙戎耙笠恍?。而且，這些內(nèi)存只有一次使用機(jī)會(huì)，切換到 “main” 線程后多了些“閑置”內(nèi)存。

實(shí)踐驗(yàn)證

目前，筆者在自己的項(xiàng)目上，使用 NUC970 系列芯片，驗(yàn)證了上述想法，目前系統(tǒng)啟動(dòng)過(guò)程未發(fā)現(xiàn)出現(xiàn)異常。

結(jié)束語(yǔ)

很多問(wèn)題是時(shí)序的原因，打亂了某件東西本該有的操作 [#5584]( https://github.com/RT-Thread/rt-thread/issues/5584 )。
對(duì)系統(tǒng)啟動(dòng)流程做些修改，我們發(fā)現(xiàn)很多概念可以理直氣壯的講出來(lái)，比如，鎖只能在線程上下文使用。當(dāng)我們通過(guò)補(bǔ)丁的方式，使得在任務(wù)調(diào)度器啟動(dòng)前進(jìn)行了鎖操作而不出異常，那么這樣就讓人迷惑了。