调研窗口：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 发布大赛总结，已收录

完整信源清单