調研視窗：2026-11-02 08:00 ~ 2026-11-03 08:00（北京時間，24 小時）

信源：RT-Thread 官方新聞介面與官網新聞列表、GitHub 主倉庫 commits / PR / Issue / releases / tags、RT-Thread org 全部 35 個倉庫按推送時間核查、GitHub 倉庫檢索（rt-thread 關鍵詞與 topic:rt-thread）、晶片原廠 GitHub 組織（先楫 HPMicro 64 個倉庫）、Google News 中英文七組查詢（走代理）、HN Algolia、電子工程專輯 RT-Thread 官方專欄、上海市經濟和資訊化委員會網站、club.rt-thread.org 論壇（本期仍受站點 WAF 限制）

本期索引

  • 一、核心與版本動態
    • USB device 兩筆宿主可控長度同時合入：字串描述符索引與 MS OS 相容 ID（11-02）
    • SDHCI 主機初始化的 32 位元組名字緩衝，RT_NAME_MAX 調到 64 就踩棧（11-02）
    • klibc 的位元組迴圈被 GCC 認成 memset，無 libc 目標連結失敗（11-02）
    • tiny vsnprintf 把 long long 走成 long，INT64_MAX 列印成 -1（11-02）
    • SCMI 復位控制器取錯容器，驅動註冊順序一併改到子系統初始化（11-02）
    • X/Y/Z 版本規則進入文件評審，Z 版本配套的 QEMU 測試清單同步掛出（11-02 ~ 11-03）
  • 二、安全跟進與待合併佇列
    • 圖形裝置的負偏移：pread 與 pwrite 繞過位置校驗，直達核心任意讀寫（11-02）
    • pipe 的補丁當天到位，改在驅動側按命令自守（11-02）
    • 維護者親自重做兩筆舊提案：getaddrinfo 與 GPT 分割槽表（11-03）
    • 佇列裡還壓著五筆：cromfs 目錄名、poll 計數、9pfs 長度、DHCP 池耗盡、signalfd（10-21 ~ 11-03）
  • 三、官方與社群活動
    • 上海開源軟體應用創新大賽落幕，睿賽德是 12 道產業命題方之一（10-29 ~ 10-30，11-02 官方釋出）
    • RT-Thread 與恩智浦的使用者問卷開啟，NXP 適配面已列到 MCX A366 與 A156（11-02）
    • 官方新聞介面仍停在 6 月 17 日，釋出出口繼續留在媒體專欄（11-03）
  • 四、生態與廠商適配
    • 先楫半導體一次推 12 個 BSP 倉庫到 v1.13.0，並新開 HPM5100EVK（11-02）
    • AWTK 主線照常迭代，本期提交與 RT-Thread 無專項關聯（11-02）
  • 五、行業應用
    • 工業閘道器開源：FreeModbus 主站、LVGL 面板、4G 上雲與 HTTP OTA 合成一個映象（11-02）
    • Sifli SF32LB52 智慧手錶韌體，把 RT-Thread 放到可穿戴底座上（11-02）
  • 六、本期趨勢與總結
    • 趨勢：一天六筆合入全是老賬，安全佇列開始由維護者接手
    • 侷限性與去重說明

一、核心與版本動態

1.1 USB device 兩筆宿主可控長度同時合入：字串描述符索引與 MS OS 相容 ID（11-02）

日期：2026-11-02 11:47（合入時間）　來源：提案 #11545、提案 #11546、缺陷 #4782、缺陷 #11287

兩筆同作者、同一小時合入，修的都是 USB device 協議棧裡「長度與索引來自主機」的老問題。

#11545 處理字串描述符索引（39 行新增、15 行刪除）。原實現在取字串前不校驗主機給的索引，直接按索引去讀字串表，越界時讀到的是相鄰的介面字串指標，未註冊時還可能解引用空指標。改法有兩條：讀表前先判索引邊界，未知或未註冊的索引一律讓 EP0 返回 STALL；只有註冊過 Microsoft OS 相容 ID 描述符時才返回 OS 字串。對應的缺陷 #4782 開於 2021 年 6 月 10 日，掛了四年多。

#11546 處理 MS OS 相容 ID 響應的長度（4 行新增、1 行刪除）。主機在取該描述符時可以給任意 wLength，原實現照著 wLength 組織 EP0 傳輸，可能把已構造的描述符緩衝區之外的內容發出去。改法是把響應長度鉗到實際構造的描述符尺寸，分配與快取行為不動。對應缺陷 #11287 開於 2026 年 3 月 23 日。

兩筆提案都開於 2026 年 7 月 1 日，同一天進入合入佇列。作者在提案裡如實寫明驗證只做了 git diff --check 與換行符檢查，未跑構建與 USB device utest，原因是手上那臺 Windows 機器沒有 scons、C 編譯器與嵌入式交叉工具鏈。這一點值得記下來：兩筆改動都不大，但 USB 描述符路徑沒有自動化測試覆蓋，合入時的信心主要來自程式碼審閱。

1.2 SDHCI 主機初始化的 32 位元組名字緩衝，RT_NAME_MAX 調到 64 就踩棧（11-02）

日期：2026-11-02 11:24（合入時間）　來源：提案 #11542

6 行新增、4 行刪除，落在 SDHCI 驅動的 dev_sdhci.c。故障現象是 qemu-virt64-aarch64 上開 SDHCI、把 RT_NAME_MAX 設成 64，啟動過程直接 data abort，fault addr 0x228。

根因是區域性緩衝寫死 32 位元組：char dev_name[32]，而 sdio_host_set_name() 按核心物件命名規則最多寫 RT_NAME_MAX 個字元；名字填滿 32 位元組之後，後面兩行 rt_sprintf(&dev_name[len], "-timer") 與 -data-timer 繼續往後寫，溢位到棧上。名字長度一旦超過 32，越界就從「可能」變成「必然」。

改法把緩衝改成 char dev_name[RT_NAME_MAX]，並在 sdio_host_set_name() 返回後補一次 dev_name[sizeof(dev_name) - 1] = '\0' 再重算長度，兩處字尾拼接從 rt_sprintf 換成帶剩餘長度引數的 rt_snprintf。這樣即便 RT_NAME_MAX 被調到 64 或 128，名字與字尾的總長也由緩衝自身兜住。

同一形狀的問題在 RT-Thread 裡不罕見：核心允許 RT_NAME_MAX 配置，但驅動裡寫死小緩衝的地方不少。這一筆是參賽作品的板卡在 QEMU 上跑到 SD 卡初始化時暴露出來的，說明 RT_NAME_MAX 非預設值的組合平時測不到。

1.3 klibc 的位元組迴圈被 GCC 認成 memset，無 libc 目標連結失敗（11-02）

日期：2026-11-02 18:08（合入時間）　來源：提案 #11965、缺陷 #6128

13 行新增、1 行刪除，只改 src/klibc/SConscript，不動任何 C 原始碼。

kstring.c 裡的 rt_memset()、rt_memcpy()、rt_memmove() 都以逐位元組迴圈收尾。GCC 在 -O2 與 -Os 下開啟 -ftree-loop-distribute-patterns，會把這類迴圈識別成標準庫呼叫並改寫成對 memset、memcpy 的引用。目標平臺若沒有 C 庫，這兩個符號就不存在，韌體在連結階段失敗，報的是一串 undefined reference，看不出與字串實現有關。

作者用 arm-none-eabi-gcc 10.3.1 在 QEMU 的 vexpress-a9 板級工程上以 -Os 復現：改前 klibc 的 kstring.o 裡出現 U memset，而且兩處 bl 0 <memset> 就落在 rt_memset() 自身內部——核心自己的 memset 呼叫了不存在的 memset。缺陷 #6128 開於 2022 年 6 月 30 日，最初的報告只說 aarch64-gcc 編譯 rt_memset 有問題。

修法是給 Libc 組追加 -fno-tree-loop-distribute-patterns，且只在 CROSS_TOOL == 'gcc' 時追加，Keil 與 IAR 構建不受影響。代價是這些迴圈不再被向量化或摺疊，但 klibc 的這幾個函式本來就不在熱路徑上。這條經驗對做裸機移植的團隊有普適性：自實現字串函式與編譯器最佳化選項之間存在隱式契約，工具鏈升級時最容易破。

1.4 tiny vsnprintf 把 long long 走成 long，INT64_MAX 列印成 -1（11-02）

日期：2026-11-02 16:25（合入時間）　來源：提案 #11600

20 行新增、3 行刪除，改 rt_vsnprintf_tiny.c 與對應測試。tiny 版本為省空間把 %lld 與 %lli 的 ll 限定符合並進 long 路徑處理，結果 64 位整數被按 32 位截斷，符號判斷也錯位——最直觀的現象是 INT64_MAX 列印成 -1。

改法把內部的 L（代表 ll）與 l 兩條有符號分支拆開：ll 按 long long 取參、按 64 位範圍判符號，l 維持 long 路徑。同時補了 rt_sprintf 的邊界值迴歸用例，覆蓋 INT32_MIN、UINT32_MAX、INT64_MIN、INT64_MAX 四個值。

驗證配置是 qemu-vexpress-a9 加 tiny 版的 long long 支援選項（VSNPRINTF_LONGLONG，未開標準 vsnprintf）。提案開於 2026 年 7 月 9 日，在佇列裡放了近四個月。tiny 版本是很多資源受限專案的預設選擇，這類靜默截斷在列印日誌、格式化時間戳時很難被發現。

1.5 SCMI 復位控制器取錯容器，驅動註冊順序一併改到子系統初始化（11-02）

日期：2026-11-02 18:20（合入時間）　來源：提案 #11946

22 行新增、7 行刪除，改 reset-scmi.c 與 pm-domain-scmi.c 兩個檔案，是本視窗最後一筆推送。

復位側的問題是一處容器轉換用錯了物件。scmi_reset_reset()、assert()、deassert() 與裝置樹解析函式都寫 raw_to_scmi_reset(rstc)，把一個 rt_reset_control 指標當成 SCMI 復位控制器去反推；正確的做法是走 rstc->rstcer，先拿到復位控制器再轉。傳錯指標的後果不是崩潰而是讀到錯位的欄位，表現取決於記憶體佈局，所以這類錯誤往往要等到具體板子上出現「復位不生效」才被發現。

註冊側的兩筆驅動原先用 RT_SCMI_DRIVER_EXPORT，改成了顯式註冊函式加 INIT_SUBSYS_EXPORT。兩個匯出宏的區別是註冊時機：驅動要在復位與電源域基礎設施就緒之後再註冊，否則消費者先 probe 就會拿不到 provider。提案描述裡還提到用裝置樹裡解析出的 reset domain ID 去查屬性，以及在復位控制器例項裡保留 SCMI 裝置引用，避免控制器生命週期短於裝置。

1.6 X/Y/Z 版本規則進入文件評審，Z 版本配套的 QEMU 測試清單同步掛出（11-02 ~ 11-03）

日期：2026-11-02 15:24（清單）/ 2026-11-03 07:23（文件更新）　來源：提案 #11955、缺陷 #11972、提案 #11974、提案 #11976

上一期報過的版本管理提案 #11955 在視窗末尾又更新一次（11-03 07:23），文件內容已經寫實：X/Y/Z 三級版本號的判定規則、Y 版本週期 3 至 6 個月、Z 版本週期 1 個月、各級釋出職責與相容性要求。仍在評審，未合入。

配套的執行清單由 CYFS3 在 11-02 15:24 掛成缺陷 #11972，標題寫得很直白——為 Z 版本的釋出做 CI 的自動化測試。核心思路是「用 QEMU 的模擬裝置替代真實硬體」：以麥克風為例，只需要註冊一組虛擬 ops 造一個模擬麥克風，把框架介面的入參測完整即可，不必等板子。清單按框架逐項列了 utest 與 QEMU 兩側的現狀：SPI 有迴環測試、PWM 有頻率與佔空比測試、RTC 有鬧鐘測試、audio 已有韌體內的模擬麥克風與播放器及 DMA 回撥，adc 與 dac 的框架測試正在補（對應 #11974 與 #11976），而 i2c、can、watchdog、touch、usb、sdio、flash、ethernet 的 QEMU 側基本空白。

這份清單的價值在於把「Z 版本能不能發」從維護者的主觀判斷變成可勾選的表格。它與 #11955 是一套東西的兩半：一半定規則，一半給證據。截稿時 #11972 有 6 條評論，adc 與 dac 兩個 utest 提案已掛出但未合入。

二、安全跟進與待合併佇列

2.1 圖形裝置的負偏移：pread 與 pwrite 繞過位置校驗，直達核心任意讀寫（11-02）

日期：2026-11-02 12:01（報告時間）　來源：缺陷 #11969、提案 #11970

報告者 XueDugu，核對基線是當天 master 08cad4ee。影響面寫得很清楚：v5.3.0 至當前 master，缺陷由 2025-12-12 的提交 5abecc1fd0c3 引入，當前 graphic.c 的 blob 為 14de5a6c。

_graphic_read() 與 _graphic_write() 接受有符號的裝置偏移，卻沒檢查 pos >= 0，也沒檢查 pos < framebuffer_len。剩餘長度用 rt_min_t(rt_ssize_t, plane->framebuffer_len - pos, size) 計算：pos 為負時 framebuffer_len - pos 變成一個大正數，res 直接取 size，隨後 rt_memcpy(plane->framebuffer + pos, buffer, res) 就在幀緩衝之前或之後讀寫。

入口在 RT-Smart 的 pread64() 與 pwrite64()。當前的 rw_verify_area() 只在 count >= -pos 時拒絕負位置，於是 count=8、pos=-210456 這樣的組合能透過校驗，一路落到驅動。報告給了兩層驗證：qemu-virt64-aarch64 配 QEMU 自帶的 ramfb 裝置，證明使用者態到核心的越界路徑；Raspberry Pi Pico 2 W（RP2350）走 USB CDC，驗證板級核心 API 原語本身。

修復提案 #11970 在 31 分鐘後掛出（12:32），作者 usualtreee，10 行新增、只改 graphic.c 一個檔案：兩個函式在計算剩餘長度前先判 pos，負值與大於等於 framebuffer_len 的位置都直接返回 0，合法讀寫的前端裁剪行為保持不變。這是本視窗響應最快的一筆——從報告到補丁半小時，但補丁尚未合入。

2.2 pipe 的補丁當天到位，改在驅動側按命令自守（11-02）

日期：2026-11-02 15:23（提案時間）　來源：提案 #11971、缺陷 #11958

上一期報過的 pipe FIONREAD 缺陷等到了補丁。22 行新增、4 行刪除，只改 pipe_fops_ioctl 所在檔案。

改法是把環形緩衝的資料長度或剩餘空間先算進棧上的 int，MMU 構建下用 lwp_put_to_user() 拷回使用者地址，非 MMU 構建維持直接寫——單地址空間下沒有隔離可言，多這一層反而破壞相容。順帶補了 pipe 與 pipe->fifo 的判空，並把 lwp_user_mm.h 的 include 用 ARCH_MM_MMU 包住。

提案裡有一段說明為什麼不在 sys_ioctl() 統一攔：ioctl 的語義因驅動而異，有的是標量 arg，有的是結構體指標，全域性校驗容易誤傷，按命令在驅動側自守更合適。這個取捨值得記：上一期把 pipe、塊裝置、終端三處歸為同一成因，但統一入口並不是唯一解，代價是每個驅動都要記得自己做。

2.3 維護者親自重做兩筆舊提案：getaddrinfo 與 GPT 分割槽表（11-03）

日期：2026-11-03 00:08 / 07:18（提案時間）　來源：提案 #11977、提案 #11978

兩筆都由 BernardXiong 提交，提案正文第一句都寫著「這是對 #xxxx 的重做（原 PR 已衝突且過時）」。

#11977 重做 #11454，加固 sys_getaddrinfo() 的使用者指標處理（57 行新增、17 行刪除）。原實現只校驗頂層 res 緩衝，隨後透過 res->ai_addr 這個使用者可控的巢狀指標寫入解析結果，在 Smart/MMU 構建下等於一次任意核心寫；hints 的欄位在頂層校驗後仍從使用者記憶體讀，存在 TOCTOU 視窗。新實現用 lwp_get_from_user() 把 res 與 hints 一次性拷進核心臨時結構體，後續所有巢狀指標都來自這份快照；巢狀 sockaddr 與外層結構體統一用 lwp_put_to_user() 寫回；順帶修了 servname 複製的返回值判斷——原始碼拿 size_t 與 0 比較，恆為假。

#11978 重做 #11275，修 GPT 分割槽表的首尾顛倒（11 行新增、5 行刪除，只改 efi.c）。is_pte_valid() 只要求 starting_lba 與 ending_lba 都在磁碟範圍內，沒檢查 ending_lba >= starting_lba；構造一個 CRC 合法的 GPT 映象就能讓 size = ending_lba - starting_lba + 1ULL 發生無符號下溢，得到一個巨大的分割槽尺寸並註冊成邏輯分割槽。改法是在校驗函式里加 end < start 判斷，並把 start 與 size 的計算挪到合法性檢查之後，用已校驗的 start 算 size。對應缺陷 #11271，原提案 #11275 已於 11-03 07:20 關閉。

兩筆放在一起看，訊號比修法本身更重要：外部報告者掛出的補丁一旦陳舊衝突，維護者開始自己重做而不是等作者 rebase。這與 2.1、2.2 的快速補丁是同一件事的兩面——佇列在動。

2.4 佇列裡還壓著五筆：cromfs 目錄名、poll 計數、9pfs 長度、DHCP 池耗盡、signalfd（10-21 ~ 11-03）

日期：2026-10-21 ~ 2026-11-03（提案時間與最近更新）　來源：提案 #11911、提案 #11954、提案 #11918、提案 #11947、提案 #11935

#11911 是 cromfs 的目錄名讀取（421 行新增、116 行刪除，7 個檔案，11-03 07:50 仍在更新）。dfs_cromfs_getdents() 直接拿映象裡的 uint16 name_size 當 memcpy 長度往 d_name 裡拷，既不與 DIRENT_NAME_MAX（256）比較，也不校驗名字是否落在剛載入的目錄 blob 內；緊接著那行又把 NUL 寫在 name_size 位置，所以 name_size 到 256 時原始碼本身就多越界一位元組。呼叫方同樣不裁剪——msh 的 ls() 把 struct dirent 放在 shell 執行緒棧上，向 getdents 只要一個條目，超長目錄名覆蓋的就是 shell 執行緒棧。

#11954 是 poll 與 epoll 的計數乘法迴繞（166 行新增，11-03 07:24 更新，規模比上一期記錄時擴大了近六倍）。sys_poll() 用使用者給的數量算核心緩衝區大小，32 位下乘積迴繞但隨後仍用原始數量遍歷：nfds 取 0x20000001、pollfd 8 位元組時乘積截成 8，校驗與分配按 8 位元組透過，poll() 卻遍歷 5.3 億項。

#11918 是 9pfs 客戶端信任伺服器給的長度（66 行新增、6 行刪除）。p9_transaction() 的返回位元組數被丟棄，解析時直接用報文裡的 count、stat_size 與 name_len，構造一個「count 巨大但實際很短」的響應就能一路讀越接收緩衝，實測越過 8.3 MB，ASAN 報 use-after-poison，同時洩露目錄資訊。

#11947 是 DHCP 地址池耗盡後的無界搜尋（19 行新增、5 行刪除）。dhcp_client_alloc() 在候選地址被佔用時用 goto 繼續找，不限制次數；池子全滿後，新 MAC 的 DISCOVER 會讓它在 lwIP 接收路徑裡永久迴圈，後續報文全部堵住。修法是記錄本輪第一個候選，回到起點即停，池滿返回 NULL。

#11935 是 signalfd_close 的監聽器摘除（91 行新增、35 行刪除）。原實現用全域性索引計數登記通知，關閉時不摘鏈、不釋放，留下懸空節點；改法改成按註冊槽位的數量上限做邊界查詢，關閉時遍歷已註冊 lwp 把對應節點從通知鏈上摘下來並釋放，同時清空檔案上下文指標。

五筆的共同點仍是老問題：長度、計數、索引來自使用者態或對端，進入核心邏輯前沒有校驗層。區別是現在每筆都有對應提案，且多數附了 QEMU 上的復現步驟。

三、官方與社群活動

3.1 上海開源軟體應用創新大賽落幕，睿賽德是 12 道產業命題方之一（10-29 ~ 10-30，11-02 官方釋出）

日期：2026-11-02（官方釋出）/ 2026-10-29 ~ 10-30（賽事）　來源：上海市經信委：大賽落幕、人民網：推動更多開源成果從賽場走向市場

2026 上海開源軟體應用創新大賽總決賽暨創新增長大會 10 月 29 日至 30 日在上海張江人工智慧創新小鎮舉行，由開源中國主辦。8 月 5 日啟動報名以來收到 766 個報名專案，40 餘家合作企業與開源社群參與；12 道真實產業命題吸引 269 個專案應題，30 支團隊晉級總決賽，角逐總價值 100 萬元的獎池。

12 道命題的釋出方里，睿賽德（RT-Thread）與中國商飛、中船海舟、道客、雲軸科技、魔琺科技同列上海本土企業一側，另一端是百度地圖、openKylin 社群、open-supOS 社群等全國性技術企業與社群。對 RT-Thread 來說，這個位置的含義是「工業與嵌入式場景被當作真實產業問題的來源」，而不是贊助商席位。

10 月 30 日的頒獎典禮上，開源中國宣佈正式落戶上海，大賽品牌升級為上海開源與人工智慧領域的年度賽事，自今年起每年舉辦；30 支決賽團隊的專案覆蓋工業模擬、算力排程與推理加速、智慧體安全治理、具身智慧資料質檢、生命科學計算，其中上海高校、企業與開源社群團隊約佔三分之一。

3.2 RT-Thread 與恩智浦的使用者問卷開啟，NXP 適配面已列到 MCX A366 與 A156（11-02）

日期：2026-11-02 17:30（釋出）　來源：電子工程專輯：RT-Thread 與恩智浦問卷活動

RT-Thread 官方專欄釋出與恩智浦的聯合使用者調研，活動週期 11 月 2 日至 11 月 23 日，11 月 24 日開獎。文章開頭把合作面寫得很具體：已適配 MCX N947、MCX A366、MCX A156 等多款晶片。問卷要求填寫終端裝置、應用場景與開發難點，並歡迎就晶片效能、外設與生態適配提改進建議。

這條本身是社群運營動作，但披露的適配清單有價值：MCX A 系列是恩智浦近兩年主推的通用 MCU 線，A366 與 A156 出現在適配名單裡，說明 RT-Thread 在 NXP 產品線上的覆蓋已經從 N947 這類帶 NPU 的型號向通用型號鋪開。上一期報的 NXP i.MX RT1180 工業乙太網連結指令碼提案（#11959）仍在佇列，兩條線可以對照看——一條是 MCU 側的廣度，一條是跨界處理器側的深度。

3.3 官方新聞介面仍停在 6 月 17 日，釋出出口繼續留在媒體專欄（11-03）

日期：2026-11-03（核查）　來源：RT-Thread 官方新聞列表

官方新聞介面 getList?type=rt_org 返回的最新條目仍是 2026-06-17 的「睿賽德科技受邀出席 2026 阿布扎比投資論壇」，官網首頁新聞區同樣停在 6 月，本期無新增。這已是該介面連續第六個月無更新。

釋出側的實際出口在媒體專欄：本期視窗內電子工程專輯的 RT-Thread 官方專欄更新一篇（11-02 的恩智浦問卷），另一篇 11-01 的雙十一促銷稿未收錄。論壇側 club.rt-thread.org 仍返回 468，前置 WAF 挑戰頁，列表與正文無法直接讀取，社群動態只能靠 GitHub 與媒體專欄交叉核驗。

四、生態與廠商適配

4.1 先楫半導體一次推 12 個 BSP 倉庫到 v1.13.0，並新開 HPM5100EVK（11-02）

日期：2026-11-02 11:43 ~ 11:56（推送時間）　來源：倉庫：rtt-bsp-hpm5100evk、倉庫：rtt-bsp-hpm6800evk、倉庫：rtt-bsp-hpm6e00evk

先楫半導體（HPMicro）的 GitHub 組織下 64 個倉庫中，有 12 個 RT-Thread BSP 倉庫在 11 月 2 日 11:43 至 11:56 的十三分鐘內集中推送：HPM6750EVK、HPM6750EVK2、HPM6750EVKMINI、HPM6E00EVK、HPM6P00EVK、HPM6800EVK、HPM6300EVK、HPM6200EVK、HPM5E00EVK、HPM5300EVK、HPM5301EVKLITE，以及新開的 HPM5100EVK。

逐倉核對到的提交資訊一致：HPM5100EVK、HPM6800EVK、HPM6E00EVK 三處均為「RT-Thread BSP v1.13.0 for <板名>」，時間戳落在同一秒級區間，判斷為一次指令碼化的批式釋出而非各自開發。HPM6800EVK 與 HPM6E00EVK 的上一筆分別是 2026-02-03 的 v1.11.0，到這一筆間隔約九個月，中間沒有 v1.12.0 的提交記錄。

HPM5100EVK 是新倉庫（11-02 10:59 建立），首筆提交即 v1.13.0，README 寫明是 RT-Thread Studio BSP，隨附示例包括 adc、blink_led、flashdb、mcan、pwm、spi_nor_flash_fs、timer、uart_dma、usb_device_generic_hid 與 usb_host_msc_udisk。示例清單能看出這塊板子的定位：CAN 與 USB 雙角色、檔案系統與 FlashDB 都在預設覆蓋範圍內，偏工業與資料記錄場景。

晶片原廠把 BSP 拆成獨立倉庫、按 Studio 工程維護，是 RT-Thread 生態近兩年的常態（兆易、意法、瑞薩都這麼做）。值得記的是釋出節奏：十二個倉庫同日同版本，說明先楫內部有一套從 SDK 到各板 BSP 的同步指令碼，這比逐個倉庫手工合併更能保證板間一致性。

4.2 AWTK 主線照常迭代，本期提交與 RT-Thread 無專項關聯（11-02）

日期：2026-11-02 17:42（推送時間）　來源：倉庫：zlgopen/awtk

致遠電子的 AWTK（3325 星）在視窗內有一次推送，最近三筆提交的標題均為「improve edit」，屬通用 GUI 框架的日常迭代，未見 RT-Thread 專項改動。該倉庫帶 topic:rt-thread 標籤、長期支援 RT-Thread BSP，故列入生態觀察，本期不作條目展開。

五、行業應用

5.1 工業閘道器開源：FreeModbus 主站、LVGL 面板、4G 上雲與 HTTP OTA 合成一個映象（11-02）

日期：2026-11-02 13:59（倉庫建立）　來源：倉庫：rtthread-industrial-gateway

一個新建的個人專案，把工業資料閘道器的四條鏈路做在同一塊 STM32F407VGT6 上：下行用 FreeModbus 作 RTU 主站，週期輪詢現場從站的保持暫存器；本地用 LVGL 8.3 做 HMI，按鈕控制與回讀共用一份保持暫存器映象表；上行經 ML307 4G 模組走 MQTT QoS1 接 ThingsBoard，支援 RPC 反向控制；遠端升級用 HTTP 分塊下載加 CRC32 校驗，寫入 download 分割槽後由 rtboot 搬移到 app 分割槽再跳轉。

硬體配置寫得比多數同類倉庫細：FSMC 8080 並口 16 位 TFT、xpt2046 電阻屏走 SPI、W25Q128（16 MB）掛 SPI1 且片選走 PG15 軟體控制、ML307 走 uart6 用 AT 指令、Modbus 從站掛 uart3 的 9600 8N1。工程按九個階段遞進，末階段把四條鏈路合進同一個映象。

這個組合的意義在於「全鏈路都在板端」：很多閘道器專案把雲連線交給外掛模組或第二顆 MCU，這個專案把 4G、協議轉換、HMI 與 OTA 壓在一顆 M4F 上，代價是 192 KB SRAM 要同時容納 LVGL 緩衝、Modbus 幀與 MQTT 會話。對做工業閘道器選型的團隊，這份倉庫的目錄結構與分割槽劃分比成品更有參考價值。

5.2 Sifli SF32LB52 智慧手錶韌體，把 RT-Thread 放到可穿戴底座上（11-02）

日期：2026-11-02 18:03（推送時間）　來源：倉庫：helios-sf32

一個基於 OpenSifli SDK 的智慧手錶韌體，目標板是思澈（Sifli）SF32LB52 開發板的 LCD 屏，UI 用 LVGL，底座是 RT-Thread。倉庫 9 月 4 日建立，視窗內有一次推送，當前 5 星 1 叉。

可穿戴是 RT-Thread 相對少見的落點。這類產品的約束與工業板相反：螢幕重新整理要流暢、待機功耗要低、UI 資源要能熱更新，而 RT-Thread 在這塊的優勢是元件可裁剪與 LVGL 的成熟繫結。OpenSifli SDK 把 RT-Thread 作為預設 RTOS，說明思澈這條產品線在 SDK 層就選定了底座，第三方韌體專案可以直接繼承。

六、本期趨勢與總結

6.1 趨勢：一天六筆合入全是老賬，安全佇列開始由維護者接手

本期 24 小時裡主倉庫合入 6 筆，全部落在 11 月 2 日 11:24 至 18:20。數量不算多，但結構很集中：四筆的提案都開於 2026 年 7 月 1 日（#11542、#11545、#11546 當天提交，#11600 是 7 月 9 日），一筆對應 2022 年 6 月的缺陷 #6128，一筆對應 2021 年 6 月的缺陷 #4782。也就是說，這一天清的是積壓，不是新活。

第一條線是「配置組合下的隱性缺陷」。#11542 的 SDHCI 棧溢位要 RT_NAME_MAX 設成 64 才觸發，#11600 的 long long 截斷要開 tiny vsnprintf 才出現，#11965 的連結失敗要目標平臺沒有 C 庫才暴露。三者共同點是預設配置下測不出來，而恰恰是這些非預設組合在真實專案裡最常見——換一顆晶片、換一套工具鏈、省一點 Flash，就會踩上。

第二條線是 RT-Smart 與裝置邊界的清賬進入第二階段。上一期的判斷是「報告多、補丁少」，本期的變化是補丁開始跟上且響應變快：圖形裝置負偏移從報告到提案 31 分鐘（#11969 到 #11970），pipe 的補丁當天到位（#11971 對應上一期的 #11958），維護者本人重做了 getaddrinfo 與 GPT 兩筆陳舊提案（#11977、#11978）。佇列裡仍有五筆在審，但每筆都有可復現步驟，評審成本已經下降。

第三條線是版本治理從「計劃」走到「證據」。#11955 把 X/Y/Z 的週期與職責寫成文件，#11972 把 Z 版本能不能發拆成 QEMU 虛擬裝置與 utest 的逐框架清單，連 adc 與 dac 的模擬裝置測試都掛了提案。這兩件事都不改核心，但決定了後續每個 Z 版本釋出時的判斷依據——上一期說「把靠人工整理的環節改成可檢查的流程」，本期看到的是清單落地。

生態側的動作更直接：先楫半導體十三分鐘內把 12 個 BSP 倉庫推到 v1.13.0 並新開 HPM5100EVK，說明原廠側的 BSP 維護已經指令碼化；社群側則出現一個把 Modbus、LVGL、4G 與 OTA 全壓在一顆 M4F 上的工業閘道器專案。一邊是廠商保證板間一致，一邊是開發者把元件拼到極限，這兩頭正好是 RT-Thread 當前最實在的生態面貌。

6.2 侷限性與去重說明

論壇 club.rt-thread.org 本期仍返回 468 並前置 WAF 挑戰頁，帖子列表與正文無法直接讀取，社群討論側的資訊缺口由 GitHub 與媒體專欄補齊，未逐帖比對。官方新聞介面與官網新聞列表均停在 6 月 17 日，釋出側資訊只能以媒體專欄為準。

Google News 英文側兩組查詢零命中，中文側三組有結果：上海開源大賽（收錄）、恩智浦問卷（收錄）、智東西關於安謀科技極術社群機器狗的稿件（正文未涉及 RT-Thread 具體技術內容，未收錄）。另有 11-01 的雙十一促銷稿，超出視窗且屬推廣內容，未收錄。HN Algolia 視窗內無 RT-Thread 相關命中。

GitHub 側本期受匿名介面限額影響（60 次每小時），主倉庫的提交、提案、缺陷明細均已取到，先楫 12 個倉庫的版本號以 HTML 與 Atom 提交流交叉核對，其中三處確認提交資訊為 v1.13.0，其餘九處依據同一時間戳區間判定為同批發布，未逐倉取提交正文。上一期列入待審佇列的 #11897（K230D）、#11892（RISC-V Smart MMU）、#11944（RTL8125）、#11943（RK3588 顯示音訊）、#11959（NXP RT1180 連結指令碼）本期仍在佇列、未有合入，不重複成條；#11954 與 #11958 上期已報，本期只記更新與補丁進展。

附錄：信源核查表與信源清單

信源核查表

信源 核查結果
官方新聞介面（rt_org） 24 小時無新增，最新條目停在 2026-06-17
官網新聞列表 首頁新聞區仍為 6 月，無新稿
社群文章介面 站點前置 WAF 挑戰頁（HTTP 468），列表與正文無法讀取
主倉庫 commits 視窗內 6 筆，集中在 11-02 11:24 ~ 18:20
主倉庫 PR 合入 6 筆（#11542、#11545、#11546、#11600、#11965、#11946）；新建與在審十餘筆，含 #11970、#11971、#11974、#11976、#11977、#11978
主倉庫 Issue 新建 1 筆（#11969 圖形負偏移）；#11972 清單同日掛出並更新
主倉庫 releases 與 tags 無新增，最新仍為 v5.3.0（2026-09-10）
RT-Thread org（35 倉庫） 僅主倉庫視窗內推送，其餘倉庫靜默
先楫半導體 org（64 倉庫） 12 個 RT-Thread BSP 倉庫同日推送 v1.13.0，新開 HPM5100EVK
GitHub 倉庫檢索（rt-thread） 視窗內新建 2 個（工業閘道器、HPM5100EVK BSP），topic 推送 4 個
Google News 中文 3 條命中，收錄 2 條（上海開源大賽、恩智浦問卷）
Google News 英文 零命中
HN Algolia 無 RT-Thread 相關命中
電子工程專輯官方專欄 視窗內 1 篇（11-02 恩智浦問卷），已收錄
上海市經信委網站 11-02 釋出大賽總結，已收錄

完整信源清單

提案 #11947（DHCP 地址池耗盡的無限搜尋） https://github.com/RT-Thread/rt-thread/pull/11947