前言

去年此時，筆者剛接觸 rt-thread 的時候，被它的初始化過程深深折服了。第一次打開一個 rt-thread 的項目，竟然沒找到多線程在哪兒初始化的，"main" 函數里沒有！
進而發現，"main" 函數不是我們認識的 "main" 函數了。在 rt-thread 里，程序進入 "main" 函數之前還有很長一段路。

目前的初始化流程

見下圖吧，一些主要的過程已經被列出來了。

從圖中可以看出來：
1. 任務調度器啟動前，有很多的初始化工作。
2. `rt_components_board_init` 里還有很多隱含的外設初始化操作。這個時候沒有進入多線程環境。
3. 先創建了三個默認線程（如果啟用了軟定時器），但并未立馬運行，任務調度器啟動后從中選擇優先級最高的那個運行（可能是 "main" 可能是 "timer"）。
4. "main" 線程啟動后，還有很多初始化工作，這個時候已經進入多線程環境。

這個流程存在的問題：
1. 堆申請被設計成多線程安全訪問，內部有加鎖動作，而鎖也是限于在線程上下文使用的。串口驅動申請緩存內存卻是在任務調度器啟動前！
2. 開啟 ulog 后，也有可能出現在任務調度器啟動之先使用鎖的現象。
3. 還有線程安全版 `rt_kprintf` ，這個也是考慮只在線程上下文使用，如果開啟了它，任務調度器啟動前的 `rt_kprintf` 需求被忽略了。

`rt_components_board_init` `rt_components_init` 兩個函數可能有很多隱含操作。但是因為 `rt_components_board_init` 處于非多任務環境中，它比 `rt_components_init` 更容易出問題。

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

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

**所以，任務調度器啟動前，串口終端輸出要么用輪詢輸出，要么給個很大的輸出緩存**，至于多大合適，這個誰也說不好。

還有一個折中的方法是降低任務調度器啟動前的打印輸出需求。怎么降低？調整初始化流程，先啟動一個無依賴的 idle 線程，把其它操作放到線程中。

新初始化流程設想

這樣一來，初始化注冊外設設備的過程也是在線程上下文環境了，這個時候想用加鎖操作也可以，申請堆內存也不會出現 `Function[rt_sem_take] shall not be used before scheduler start`

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

和上面鏈接里提到的流程，修改了開啟 systick 中斷節點。
同時如果放棄在初始化配置系統時鐘時調試輸出信息的想法，放棄創建 idle 線程過程中調試輸出錯誤信息的想法，放棄啟動系統任務調度器過程調試輸出錯誤信息的想法后，控制臺輸出信息也就全處于線程上下文了。

最起碼，我們有以下幾點收獲：
1. 任務調度器啟動前，不需要開全局中斷。
2. 申請堆內存的操作都可以是在線程上下文。
3. 控制臺串口輸出數據可以使用中斷或者 DMA 任意模式。

缺點：idle 線程棧可能比之前要大一些。而且，這些內存只有一次使用機會，切換到 “main” 線程后多了些“閑置”內存。

實踐驗證

目前，筆者在自己的項目上，使用 NUC970 系列芯片，驗證了上述想法，目前系統啟動過程未發現出現異常。

結束語

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