前言

接觸 rt-thread 已有半年，混論壇也5個半月了，期間遇到過各種奇奇怪怪的棘手問題，有過尷尬，也自信曾經提供過比較妙的應對方案。所以產生了將一些典型的使用技巧匯總分享出來的想法，遂有此篇。

PS: 接觸 rt-thread一年多了，這篇文章也經歷了多次增補

入門篇

Q1. 剛下載的 SDK 啥也沒干，編譯沒錯，為啥程序跑不起來？

如果使用 keil + env 環境，下載源碼后的**第一件事就是 `menuconfig`** ；
如果使用 RT-Studio ，創建項目后的**第一件事就是打開 Settings** ；
把其中所有配置頁面所有配置項全瀏覽一遍，取消掉所有不相干的配置，最后只留一個內核。

先保證最小系統跑起來，用點燈程序驗證最小系統運行正常。然后再添加自己需要用到的功能和底層外設等等。

Q2. 剛下載的 SDK 啥也沒干，編譯沒錯，為啥程序跑起來 hard fault on thread？

**同上**

Q3. 剛下載的 SDK 啥也沒干，編譯為啥報錯了？

**同上**

內核篇

Q1. RT_NAME_MAX 定義多少合適

原則上越少越省內存，以內核對象 100 個為例，一個對象名占用 8 字節，總共是 800 字節。但是考慮到 `struct rt_object` 結構體定義，后面跟了兩個 rt_uint8_t 型變量。

RT_NAME_MAX 可以定義成 2ⁿ + 2

Q2. RT_DEBUG

如非必要，不要開啟內核調試。除非，你真的想學習內核，或者調試內核的問題。

Q3. 線程棧大小定義多少合適？

這個問題和應用有很大關系，如果僅僅是一個最小內核系統，除了 idle 線程，沒有使用其它中斷和應用，256 也將將夠。如果添加了應用代碼，還有中斷和消息機制。建議 1024 起步。

Q4. 怎么快速計算 GET_PIN 返回的編號？

我們知道，芯片的 GPIO 分組往往是從 PA 開始，往后依次是 PB PC PD PE ... PZ。往往的，每組端口或者是 16bit 或者是 8bit （分別對應 16 個 IO 和 8 個 IO）。下面給出 `GET_PIN` 的簡化公式：

16bit 是 `(X - A) * 16 + n`

> A10 就是 10.
C9 就是 2*16+9=41.
H1 就是 7*16+1=113.

8bit 是 `(X - A) * 8 + n`

這個公式別忘啊，別忘了！

PS: 有種，他們的引腳號編碼很奇特，比如 RA6M4 ，見[【開發板評測】Renesas RA6M4開發板之GPIO、IIC（模擬）]( https://club.rt-thread.org/ask/article/36fe553196532ddd.html ) 第二節部分。

Q5. 硬定時器、軟定時器、硬件定時器，傻傻分不清楚

rt-thread 內核定義了軟件定時器，和硬件定時器不同，硬件定時器需要占用一個定時器外設，還有各種比較、捕獲等功能。軟件定時器僅僅是簡單的設定一個時間，時間 timeout 的時候執行我們設定的回調函數。

rt-thread 定義的軟件定時器還細分兩種，“硬定時器” “軟定時器”，前一種是在 SysTick 中斷中執行回調函數的，多數用于線程內置定時器，應用層也可以用，但是要時刻謹記它的回調函數是在中斷中執行的。
后一種，是在一個線程中運行的，應用層對定時精度要求不是很高的可以用這種，但是也要注意“定義定時器和執行定時器回調函數的線程是兩個不同的線程！”

Q6. 消息隊列池申請多少內存合適？

rt_err_t rt_mq_init(rt_mq_t mq, const char *name, void *msgpool, rt_size_t msg_size, rt_size_t pool_size, rt_uint8_t flag);
rt_mq_t rt_mq_create(const char *name, rt_size_t msg_size, rt_size_t max_msgs, rt_uint8_t flag)

如果使用 `rt_mq_create` 創建消息隊列，消息隊列池自動根據消息體大小 `msg_size` 和消息隊列最多容納的消息數量 `max_msgs` 計算。

但如果使用 `rt_mq_init` 初始化消息隊列，消息隊列池的內存 `msgpool` 需要用戶提供，這個時候，需要注意消息池內存大小 `pool_size`。根據下面的公式計算得出：

`(RT_ALIGN(msg_size, RT_ALIGN_SIZE) + sizeof(struct rt_mq_message*)) * max_msgs`

其中，`msg_size` 是消息體大小，`max_msgs` 是消息隊列中最多消息容量。

Q7. 使用消息隊列注意

雖然 `rt_mq_send` `rt_mq_send_wait` `rt_mq_urgent` `rt_mq_recv` 幾個 api 有 size 參數，但是請嚴格按照 `rt_mq_init` `rt_mq_create` 中的 msg_size 參數值傳遞相等的實參值。***千萬不要隨意改變 size 參數的數值***。

換種說法，別用消息隊列直接發變長數據。

Q8. INIT_xxx_EXPORT 宏詳解

當初接觸 rt-thread 第一個讓我感觸的地方就是，main 函數里沒有初始化配置，上來直接就是一個單獨的線程。而，其它線程都通過 INIT_APP_EXPORT 自動啟動了。
rt-thread 一共定義了 6 個啟動階段，

/* board init routines will be called in board_init() function */
#define INIT_BOARD_EXPORT(fn)           INIT_EXPORT(fn, "1")
/* pre/device/component/env/app init routines will be called in init_thread */
/* components pre-initialization (pure software initilization) */
#define INIT_PREV_EXPORT(fn)            INIT_EXPORT(fn, "2")
/* device initialization */
#define INIT_DEVICE_EXPORT(fn)          INIT_EXPORT(fn, "3")
/* components initialization (dfs, lwip, ...) */
#define INIT_COMPONENT_EXPORT(fn)       INIT_EXPORT(fn, "4")
/* environment initialization (mount disk, ...) */
#define INIT_ENV_EXPORT(fn)             INIT_EXPORT(fn, "5")
/* appliation initialization (rtgui application etc ...) */
#define INIT_APP_EXPORT(fn)             INIT_EXPORT(fn, "6")

其中, INIT_BOARD_EXPORT 運行在任務調度器啟動前，也是唯一任務調度器運行前被執行的。這里是外設初始化配置階段。
其余幾個階段都是任務調度器啟動以后，由 main 線程（標準版，如果使用了 main 線程）負責執行。

這些階段并不是完全固定，有些是可以調整的，例如，我曾經把 lcd 的初始化從 DEVICE 提前到 BOARD ，而把 emwin 的初始化放到 PREV 。還在 ENV 階段初始化了一些消息隊列等等。

大部分情況下，以上幾個階段可以完成所有定義的初始化工作。但是，也難免出現沖突的可能。

例如，github [#5194]( https://github.com/RT-Thread/rt-thread/pull/5194 ) 上的這個 pr。里面還提供了很多反應這個問題的鏈接。以及很多人提出的解決方案。

個人認為，啟動順序在同一級的，而且之間有依賴/互斥關系的兩個部分。這種情況，應要求開發者自己注意調整代碼執行順序，把兩個部分初始化過程寫到同一個函數里，由開發者自己維護依賴關系。

Q9. 怎么通過 rt_thread_suspend rt_thread_resume 掛起喚醒某線程

盡量不要這么做，在 rt-thread 里，一個線程進入 suspend 態有兩種情況，一種是時間片耗盡自動讓出 cpu；一種是等待資源阻塞讓出 cpu。兩個線程之間并沒有完整透明的了解對方當前狀態的途徑。
假如某線程 A 想顯式掛起線程 B，但是，A 并不知道 B 當前是運行中讓出 cpu，還是等待資源中已經處于掛起狀態，還是資源可用正在從掛起態被喚醒過程中。所以，不明就里地掛起其它線程的做法是危險的。

筆者唯一能想到的，就是 B 線程執行任務比較多，自己不會主動出讓 cpu。而且，它的線程優先級比較低，某高優先級線程 A 在某種條件下使得 B 掛起。但是這樣線程 B 勢必會影響到 idle 線程。
其實，這種場景，完全可以使用線程間同步機制實現，線程 B 通過發信號給 A 而掛起自己；線程 A 再通過另外一個信號喚醒線程 B。

曾經以為自己能找到直接使用這倆 api 的方式，有一天，突然想到 rt-thread 的 ipc 都是針對性的，因信號量掛起的，不可能因為郵箱被喚醒。因為時間片耗盡掛起的線程也別想著會被什么資源喚醒。掛起和喚醒具有唯一性。

Q10. list_thread 或 ps 查看線程狀態不對？

1. error 列的線程錯誤沒有多少參考價值，0 是正常，-2 表示超時，執行一個 `rt_thread_mdelay` 就變 -2 了。但并不表示有錯誤。目前還沒有看到賦值有其它錯誤值的代碼。
2. status 列代表當前線程狀態。但是呢，因為 list_thread 或 ps 兩條命令是在 tshell 線程執行的，所以 tshell 線程肯定是 running ；idle 線程不可能被掛起，肯定顯示的是 ready；其它線程可能會出現 ready，但是多數時候是 suspend。但是這并不表示其它線程一直是 suspend 不被調度了。

Q11. 定時器可以執行長時間操作？

如上所說，rt-thread 中有三種定時器，每種定時器有各自的特點
硬件定時器：回調函數在中斷里，不建議直接執行長時間操作。
硬定時器：同樣也是在中斷執行回調函數，不建議直接執行長時間操作。
軟定時器：由定時器線程執行調用回調函數的軟定時器，是具有執行長時間操作的理論基礎的。定時器線程同樣是一個線程，它也有自己的線程棧，優先級等。如果某些操作是獨立的，把它們放到某特定線程里和在定時器線程運行是沒區別的。

但是，目前定時器線程處理軟定時器的方式不適合執行長時間操作。需要進行修改后才能做到。具體修改方法見 rt-thread優化系列（三）軟定時器的定時漂移問題分析

注意：定時器線程的優先級需要根據需要進行調整；若有多個軟定時器，回調函數執行都比較長，必然存在某回調被延遲執行的可能性，這個是無法避免的。

Q12. "Function[xxx] shall not be used in ISR" 錯誤是怎么回事兒？

以及類似的錯誤 "Function[xxx] shall not be used before scheduler start"
詳見 rt-thread心法系列（一）那些你必須知道的幾類 api

開發環境篇

Q1. 改變 env 或者 RT studio 下載源

rt studio 內置了 env 環境，studio 可能也是借助 env 實現下載更新組件的。有些第三方組件的主倉庫在 github 上，這樣就難為了很多小伙伴，經常因為訪問不了 github 而出現下載更新失敗。其實官方提供了鏡像下載的方式，鏡像倉庫在 gitee 上，我們需要切換 env 下載方式為鏡像下載。見此文章 RT-Studio 切換鏡像服務器下載

文章中 **RTT_逍遙** 大佬提供了個命令 `menuconfig -s` ，這個命令也可以，查看 menuconfig 的幫助信息可以得到詳細說明。

Q2. 生成 MDK5 項目，配置變了怎么辦？

當執行 `scons --target=mdk5` 的時候，scons 從當前目錄下的 "template.uvprojx" 文件為模版生成 "project.uvprojx" 項目配置文件。
我們修改項目配置，啟用了 "Use MicroLIB" "Browse Information" "GNU extensions" 等等之后，重新生成可能導致之前的修改丟失，可以通過修改 "template.uvprojx" 文件

"0" 為 "1"
"0" 為 "1"
"0" 為 "1"

還比如，有人問，“[用Scons 生成keil工程時， 如何導入sct文件？]( https://club.rt-thread.org/ask/question/433781.html )”
打開 "template.uvprojx" 文件找到 “ScatterFile” 的位置，修改里面的文件路徑及文件名就可以了。
`.boardlinker_scriptslink.sct`

其它可類比。

Q3. 修改 scons 使用的編譯器

找到 rtconfig.py 文件，一般和 rtconfig.h 文件同目錄，文件開頭有幾個變量

# toolchains options
ARCH='arm'
CPU='cortex-m4'
CROSS_TOOL='gcc'

分別定義了，cpu 核架構，版本，以及使用的交叉編譯工具鏈平臺。目前支持 gcc keil iar 三種平臺。

接下來，針對每一種平臺，使用不同的交叉編譯工具鏈及其安裝路徑

最后是每種交叉編譯工具鏈編譯選項。

通過修改 `CROSS_TOOL='gcc'` 的定義可以修改編譯器。

Q4. env 下的兩種界面配置姿勢

他人都說 studio 好，我卻獨衷心 env。
以前只知道 menuconfig，從此還有一個 `scons --pyconfig`。

論壇 mysterywolf 大佬發現的這個命令，像撿到一個寶，不習慣 menuconfig 的童鞋，喜歡 studio 配置可以點點點的童鞋，你們可以回來繼續使用 env 啦！

修改完，點 SAVE -》關閉。

還支持搜索跳轉，點 Jump to...，彈出界面里輸入搜索內容，Search。

選項里可以直接配置，或者雙擊跳回原菜單位置。

比 studio 或 menuconfig 里的功能一點兒不少，還更方便操作啦。

Q5. menuconfig 找不到需要的在線包怎么辦？

執行 `pkgs --upgrade` 命令，注意！不是 `pkgs --update` ！
前一條命令用于更新 env 自帶的 RT-Thread online packages 包列表信息。后者用于下載、更新、刪除選擇的包。

Q6. RT-Studio 怎么修改編譯選項？

在 env 環境下，每個 bsp 根目錄下都有個 rtconfig.py 文件，里面是各種開發環境下交差編譯工具鏈配置（上文有提及過）。
修改了 rtconfig.py 文件后，使用 scons 編譯直接使用的修改后的配置；使用 keil 開發需要執行 `scons --target=mdk5`，把新修改同步更新到 keil 項目配置文件里。

如果使用 RT-Studio 呢？。

1. 修改 RT-Studio 里的編譯配置，需要按照 eclipse 的方式來。右鍵項目》》屬性》》C/C++ 構建》》設置》》工具設置，在這里可以修改的有 c 編譯器選項、c++ 編譯器選項、鏈接器選項，blablabla 眼花繚亂的不一定能改對，小心謹慎，多加練習吧。
2. 使用 `scons --target=eclipse`，更新 RT-Studio 項目配置文件。需要注意的是，執行這個命令前先關掉 RT-Studio ，然后打開 env 切換到項目目錄下，刪掉 ".cproject" 項目文件，最后修改 rtconfig.py 文件后執行 `scons --target=eclipse`。

Q7. 添加第三方 lib 及其搜索路徑

添加 lib 和路徑也需要在 rtconfig.py 文件里修改，修改 LFLAGS 變量，增加庫 `-lxxx` 。修改 LPATH 添加庫搜索路徑。
修改 rtconfig.py 之后按照上一小節的操作步驟刷新一下 IDE 工程文件。

還有一些 lib 是跟隨軟件包組件添加的，修改軟件包目錄下的 Scronscript 文件，

pathlib = [cwdlib + '/Lib']
group = DefineGroup('STemWin2RTT', src, depend = [''], CPPPATH = path, LIBS=['STemWin532_CM4_OS_Keil_ot'], LIBPATH = pathlib)

`pathlib` 用于添加 lib 文件路徑。
“DefineGroup” 定義組時，增加兩個參數 `LIBS=['STemWin532_CM4_OS_Keil_ot'], LIBPATH = pathlib` 分別指定庫名稱和庫路徑。

Q8. 添加頭文件包含路徑

因為 rt-thread 源碼默認是 scons 自動化開發環境。源碼中有大量的 Scronscript 腳本文件，這些文件控制著源碼文件是否參與編譯，增加哪些頭文件搜索路徑
`src += ['xxxx.c']` 添加源碼文件。
`path += [cwd + '/ports']` 添加頭文件路徑。

外設驅動篇

Q1. USB Host 不識別 U 盤等設備

詳見 [rt-thread STM32F4 usbhost 調試筆記](https://club.rt-thread.org/ask/article/2878.html)

這里還有另外兩位大佬提供的修改方案，可以都嘗試一下。或者集眾家之長，前一段時間我按照兩位大佬的也修改了一下，感覺都是可以兼容的，暫未發現問題。

PS: STM32 系列的芯片，可能要求 USBHOST 時鐘頻率是 48MHz ，這個要注意。

Q2. NAND Flash 驅動

[gitee](https://gitee.com/thewon/rt_thread_repo) 有完整代碼

Q3. 移植 yaffs2 文件系統

配合上面的 nand flash 驅動使用。
[gitee](https://gitee.com/thewon/rt_thread_repo) 有完整代碼

Q4. 更高效的串口驅動框架 serialX

請移步系列文章，從理論提出到實現，到實踐驗證，測試程序，用法demo，全套的。

rt-thread 驅動篇（一） serialX 框架理論
rt-thread 驅動篇（二） serialX 理論實現
rt-thread 驅動篇（三） serialX 壓力測試
rt-thread 驅動篇（四）serialX 多架構適配
rt-thread 驅動篇（五）serialX 小試牛刀

使用篇

Q1. 串口通訊數據被分多次接收了，怎么辦？

首先說明，串口是一種流設備，無協議接口。它收到一個字節給你一個字節，收到兩個字節給你兩個字節。如果你的數據是整齊的 16 個字節，而且想每收 16 個字節串口驅動給你個信號，這就難為人了。還有一種情況是，前后兩次不同的數據被拼接在一起了。

這個時候，需要我們在應用層進行處理。或者是定長包，或者定義包頭包尾，包長度等等。下面給出我在論壇上多次分享過的代碼，這個是帶包頭包尾的，在這個基礎上可以修改成其它各種形式包協議的。

   rt_uint8_t *recvbuf = RT_NULL;
   static struct serial_configure uart_conf = RT_SERIAL_CONFIG_USER;
   rt_uint8_t *datbuf = RT_NULL;
   rt_size_t rcv_off = 0, recv_sz = 1024, tmp = 0;
   rt_size_t dat_off = 0, dat_len = 0, i;
   rt_tick_t _speed_ctrl = 0;

   recvbuf = rt_malloc(128);
   rt_memset(recvbuf, 0, 128);
   datbuf = rt_malloc(32);
   rt_memset(datbuf, 0, 32);

   busif_speed_ctrl = rt_tick_get();

   rt_sem_init(&rx_sem, "bifrx", 0, 0);
   dev_busif = rt_device_find("uart1");
   if (dev_busif == RT_NULL)
   {
       rt_kprintf("Can not find device: %sn", "uart1");
       return;
   }
   if (rt_device_open(dev_busif, RT_DEVICE_OFLAG_RDWR | RT_DEVICE_FLAG_INT_RX | 
                      RT_DEVICE_FLAG_STREAM) == RT_EOK)
   {
       rt_device_set_rx_indicate(dev_busif, busif_rx_ind);
   }

   while(1) {
       rt_sem_take(&rx_sem, RT_WAITING_FOREVER);
       recv_sz = rt_device_read(dev_busif, -1, &recvbuf[rcv_off], 128-rcv_off);
       if (recv_sz > 0) {
           rt_kprintf("data: %dn", recv_sz);
           if (rcv_off == 0) {
               i = 0;
               while ((recvbuf[i] != 0x1A) && (i < recv_sz)) i++;          // find header
               if (i == 0) {
                   rcv_off = recv_sz;
               } else if (i < recv_sz) {
                   rcv_off = recv_sz-i;
                   rt_memcpy(recvbuf, &recvbuf[i], recv_sz-i);
               } else {                                                    // no header
                   rcv_off = 0;
                   continue;
               }
           } else {
               rcv_off += recv_sz;
           }
           if (rcv_off < 2) {                                              // data not enough
               continue;
           }
           dat_len = recvbuf[1];
           if (dat_len > 16) {                                             // error length
               rcv_off = 0;
               dat_len = 0;
               continue;
           }
           if (rcv_off >= (dat_len + 3)) {                                 // len enough
               float val = 0;
               AdcVal adc_val;

               if (recvbuf[9+2] != 0x1B) {                                 // find tailer error
                   dat_len = 0;
                   rcv_off = 0;
                   continue;
               }
               tmp = rcv_off-(dat_len + 3);
               _speed_ctrl = rt_tick_get();
               if (/*busif_busy > 0 || */(_speed_ctrl - busif_speed_ctrl < 100)) {
                   busif_busy--;
                   if (tmp > 0) {
                       rt_memcpy(recvbuf, &recvbuf[dat_len + 3], tmp);
                       rcv_off = tmp;
                   } else {
                       rcv_off = 0;
                   }
                   dat_len = 0;
                   continue;
               }
               switch(recvbuf[2]){                                         // map function type id
               case 1:
                   adc_val.type = FUNC_DCV;
               break;
               case 2:
                   adc_val.type = FUNC_DCI;
               break;
               default:                                                    // unsupport type id
                   if (tmp > 0) {
                       rt_memcpy(recvbuf, &recvbuf[dat_len + 3], tmp);
                       rcv_off = tmp;
                   } else {
                       rcv_off = 0;
                   }
                   dat_len = 0;
                   rt_kprintf("error type: %dn", adc_val.type);
                   continue;
               break;
               }
               rt_memcpy(datbuf, recvbuf+4, 7);                            // change str 2 float
               datbuf[7] = 0;
               rt_kprintf("%sn", datbuf);        // 數據域 ，可以是字符串，可以是十六進制數據
               // 其它數據處理
               ....
               // prepare next package 準備下一包
               if (tmp > 0) {
                   rt_memcpy(recvbuf, &recvbuf[dat_len + 3], tmp);
                   rcv_off = tmp;
               } else {
                   rcv_off = 0;
               }
               dat_len = 0;
           }
       }
   }

項目代碼，神明保佑，別被老板看到

Q2. 線程間傳輸不定長數據

有兩種消息機制可以傳輸數據，郵箱和消息隊列。以下是一些使用建議：

• 郵箱傳輸的是定長 32bit 數據，或者是一個整型值，或者是一個地址；
• 消息隊列的可伸縮性更強，而且有隊列，消息體大小由用戶決定，但是，一經初始化，消息體大小也是固定長度的了。

1. 對于某些不同類型數據，每種數據長度固定，而且各種類型數據長度差別不是很多的情況，我們可以使用聯合體代替結構體。這樣消息體的長度也是固定的，以最長長度為準。
2. 用郵箱傳遞內存地址，這樣不限定數據長度，但是要求每一次郵箱必須被接收方接收。發送方申請內存，接收方釋放內存。如果出現郵箱發送失敗，由發送方釋放內存。
3. 用消息隊列傳遞內存地址，比郵箱的優勢就在于它能緩存多個地址，降低發送失敗的風險。
4. pipe 管道或 ringbuffer。pipe 內部數據結構也是 ringbuffer。雖然可以讀寫任意長度數據，但是，這樣又將數據變成流了。需要讀取方根據事先約定的協議進行解析拆分。還有個缺陷是它沒有消息機制，寫方需要單獨發消息通知接收方，或者，接收方死等這個數據。鑒于這種方式必須用鎖，不適合中斷和線程之間的數據傳輸。

Q3. 插上 U 盤怎么通知應用程序？

[gitee](https://gitee.com/thewon/rt_thread_repo) 有完整代碼，主要修改在 hub.c 和 udisk.c 兩個文件

Q4. 怎么優雅的掛載多種存儲設備？

內存、片上 flash 、片外 spi flash、sd 卡、U盤... 各式各樣的的設備，掛載的文件系統也可能不一而足。怎么優雅的把多種設備掛載到文件系統就是個需要考慮的問題了。

1. 掛載 rom 根文件系統，同時創建其它可讀寫文件系統掛載點。
2. 其它設備分別掛載到 rom 文件系統的掛載點上。

Q5. rom 文件系統

rt-thread 源碼目錄下 “components/dfs/filesystems/romfs” 有個 romfs.c 文件，是 rom 文件系統配置模板文件，拷貝它到你的應用目錄下，修改 `_root_dirent` 定義。可以創建只讀文件。

RT_WEAK const struct romfs_dirent _root_dirent[] =
{
   {ROMFS_DIRENT_DIR, "dummy", (rt_uint8_t *)_dummy, sizeof(_dummy) / sizeof(_dummy[0])},
   {ROMFS_DIRENT_FILE, "dummy.txt", _dummy_txt, sizeof(_dummy_txt)},
};

或者，只有目錄

RT_WEAK const struct romfs_dirent _root_dirent[] =
{
   {ROMFS_DIRENT_DIR, "mnt", RT_NULL, 0},
   {ROMFS_DIRENT_DIR, "usr", RT_NULL, 0},
   {ROMFS_DIRENT_DIR, "var", RT_NULL, 0},
};

有了只讀文件系統，可以很方便擴展掛載很多其它文件系統。

Q6. 絲滑掛載設備

在嵌入式里很多存儲設備是焊接到電路板上的存儲芯片。如果我們有在存儲芯片上掛載文件系統的需求，出廠生產必須有方式對存儲設備進行格式化。為此，可能難倒一大批流水線工人。可以使用下面的流程進行掛載。

   result = dfs_mount(mtd_dev->parent.parent.name, "/usr", "yaffs", 0, 0);
   if (result == RT_EOK)
   {
       rt_kprintf("Mount YAFFS2 on NAND successfullyn");
   }
   else
   {
       result = dfs_mkfs("yaffs", mtd_dev->parent.parent.name);
       if (result == RT_EOK)
       {
           result = dfs_mount(mtd_dev->parent.parent.name, "/usr", "yaffs", 0, 0);
       }
       else
       {
           rt_kprintf("Mount YAFFS2 on NAND failedn");
           return -RT_ERROR;
       }
       rt_kprintf("Mount YAFFS2 on NAND successfullyn");
   }

掛載失敗，直接格式化，有些比較暴力，但是不需要人工格式化存儲設備了。

Q7. 如何自動掛載文件系統

兩種方式：一種是通過配置，啟用 RT_USING_DFS_MNTTABLE 。這種方式需要使用者自己實現一個結構體數組 `const struct dfs_mount_tbl mount_table[]` 。

另一種就是自己寫代碼掛載不同設備。我喜歡這一種，因為這樣我可以使用上一小節提到的設計。

Q8. assertion failed at function:rt_xxxxx

問題是我沒調用 `rt_xxxxx` 函數啊？！

這種問題分兩種：
一種是，確定這個函數在運行中正常調用的，例如：(tid != RT_NULL) assertion failed at function:rt_applilcation_init，可以確定的是 `rt_applilcation_init` 函數運作于線程調度器啟動前，這個時候肯定不會是多線程非法寫了內存引起的。可以確定是因為 `rt_thread_create` 函數調用返回了空指針。那么，問題來了，堆初始化成功了嗎？內存有多大？
另外一種是，沒有調用那個函數的地方，但是提示這個函數參數檢測出錯。這種情況大概率是 PC 指針飛了。走到了不應該走到的位置。

定位問題方法請見下節。

Q9. hard fault on thread: xxx

考慮了很久，要不要把這個加進來。出現這個錯誤提示的可能性太多了。從現象上看也分兩類，一類比較確定的，程序走到這個位置必然出現；一類不太確定，每次運行可能現象不一樣。

• 環境搭建問題，系統移植有缺陷引起的。
• 線程棧太小，線程棧爆棧。
• 數組越界、野指針、函數參數傳參錯誤...
• 邏輯性錯誤，內存釋放后還有可能被使用。多發生在外設的接收緩存上。

但是，上面這些只是扯淡，并不能定位到錯誤位置。定位問題是個方法論范疇的概念。每個人都應該有自己熟悉的一套做法，我的想法請見 rt-thread 工具講解系列（二） 之 如何排查系統 bug

Q10. 怎么定義變量到指定內存位置？

非 gcc 版
- 定義一個宏

#ifndef      __MEMORY_AT
  #if     (defined (__CC_ARM))
 #define  __MEMORY_AT(x)     __attribute__((at(x)))
  #elif   (defined (__ARMCC_VERSION) && (__ARMCC_VERSION >= 6010050))
 #define  __MEMORY_AT__(x)   __attribute__((section(".ARM.__AT_"#x)))
 #define  __MEMORY_AT(x)     __MEMORY_AT__(x)
  #else
 #define  __MEMORY_AT(x)
 #warning Position memory containing __MEMORY_AT macro at absolute address!
  #endif
#endif

- 使用 `uint8_t blended_address_buffer[480*272*2] __MEMORY_AT(0xC0000000);`

gcc 版
- 修改鏈接文件

/* Program Entry, set to mark it as "used" and avoid gc */
MEMORY
{
 CODE (rx) : ORIGIN = 0x08000000, LENGTH = 1024k /* 1024KB flash */
 RAM1 (rw) : ORIGIN = 0x20000000, LENGTH =  192k /* 192K sram */
 RAM2 (rw) : ORIGIN = 0x10000000, LENGTH =   64k /* 64K sram */
 SDRAM (rw): ORIGIN = 0xC0000000, LENGTH = 8092k /* 1024KB sdram */
}
SECTIONS
{
 ... /* 忽略其它內容 */

 .sdram : 
 {
  KEEP(*(.sdram_section))
 } >SDRAM
}

- 定義一個宏

#ifndef      __MEMORY_AT
  #define  __MEMORY_AT(x)     __attribute__((section(".#x")))
#endif

- 使用 `uint8_t blended_address_buffer[480*272*2] __MEMORY_AT(sdram_section);`

gcc 版本是把變量分配到某 section ，距離地址還有查一點兒。當多個變量放到同一個 section 的時候，它們的順序就不保證了。這種情況只能多定義一些 section。

Q11. 結構體字節對齊

__packed struct __packed_struct{
   ...
};
struct __attribute__((packed)) __packed_struct{
   ...
};
struct __packed_struct{
   ...
} __attribute__((packed));
#pragma pack(push, n)
struct __packed_struct{
   ...
};
#pragma pack(pop)

keil 里可以這么寫，其它開發環境下有差異。gcc 不支持 `__packed` 的寫法
最后的寫法，可以指定按照 n 個字節對齊，n 是一個具體是常數，常用的有 1 2 4 8 ...

Q12. unaligned access 是怎么出現的？

據我所知，當取指令的時候要求比較嚴格，編譯器也往往把指令做了對齊處理。如果出現非對齊訪問，多半是 pc 指針異常了。
還有一種情況，有人說 ARMv7-M 架構設計的時候，0xC0000000-0xDFFFFFFF 這個地址段默認要求必須 4字節（數據總線寬度）對齊訪問。如果這片內存有個壓縮的結構體變量，對此變量讀寫也可能出現 unaligned access 錯誤。解決方法如下：
1. 修改 MPU 讓這個區域變成正常儲存器

   /* Configure the MPU attributes as WT for SRAM */
   LL_MPU_ConfigRegion(LL_MPU_REGION_NUMBER1, 0x00, 0xC0000000UL,
                       LL_MPU_REGION_SIZE_16MB | LL_MPU_REGION_FULL_ACCESS | LL_MPU_ACCESS_NOT_BUFFERABLE |
                       LL_MPU_ACCESS_NOT_CACHEABLE | LL_MPU_ACCESS_NOT_SHAREABLE | LL_MPU_TEX_LEVEL1 |
                       LL_MPU_INSTRUCTION_ACCESS_DISABLE);

2. 映射 SDRAM 到別的地址.(0x60000000, 如果你外掛 NOR Flash,這個方法行不通)

RCC-> APB2ENR | = RCC_APB2ENR_SYSCFGEN;
SYSCFG-> MEMRMP | = SYSCFG_MEMRMP_SWP_FMC_0;

3. 取消未對齊訪問檢測
編譯器添加 `–no_unaligned_access` 編譯選項。
有人介紹這個選項的時候說“強制編譯對齊”或者“禁用未對齊訪問支持”，個人認為這種說法不正確，因為，結構體還是按照咱們的想法按照字節對齊的，只是在訪問這個數據的時候換了種方式，不用4字節（數據總線寬度）對齊的方式訪問了。添加這個選項，恰恰是支持了未對齊數據訪問。

支持未對齊數據訪問的基于 ARM 體系結構的處理器，包括：

• 基于 ARMv6 體系結構的所有處理器
• 基于 ARMv7-A 和 ARMv7-R 體系結構的處理器。

不支持未對齊數據訪問的基于 ARM 體系結構的處理器，包括：

• 基于 ARMv6 以前版本的體系結構的所有處理器
• 基于 ARMv7-M 體系結構的處理器。

Q13. STM32F767 怎么使用 PersimmonUI？

不止 STM32F767，可以使用 PersimmonUI 芯片可以很多，詳情見獨立文章 STM32F767 使用 PersimmonUI 及其它芯片使用可行性分析

結束語

本人能力有限，文中難免有錯誤，或者方法錯誤。望各位同仁不吝賜教。
拜謝拜謝

此寶典不定期更新，希望有朝一日能破萬條。

審核編輯：湯梓紅