调研窗口：2026-10-23 08:00 ~ 2026-10-26 08:00（北京时间，72 小时，含周末）

信源：RT-Thread 官方新闻接口、社区论坛文章接口、GitHub（主仓库 commits / PR / Issue / Releases / tags、RT-Thread/sdk 与 toolchains-ci、RT-Thread-packages 组织各仓、pkgs-test、topic:rt-thread 生态检索）、Google News 聚合（中英文多组查询，走代理）、HN Algolia、行业媒体（电子工程专辑 RT-Thread 专栏）与厂商渠道核验（详见附录信源清单）

本期索引

  • 一、内核与版本动态
    • 主线 72 小时只有两笔提交：lwIP 回环 netdev 合入，clang-format 规则细化带 thread.c 示例（10-25）
    • qemu-virt64 打开 RT-Thread Smart：riscv64 关 SMP、ext4 与 elm 挂块设备、ptyfs 与 procfs 上挂（10-25）
    • lwp_syscall.c 一万一千行拆分：165 个系统调用入口按子系统分文件，行为不变（10-25）
  • 二、安全与稳定性跟进
    • 时间子系统一夜间四单连报：settimeofday 窄化、gmtime_r 负时间戳、timer_gettime 截断，附一份 A 至 F 工作项调研（10-23／10-24）
    • 32 位 RT-Smart 的 sys_poll 回绕：8 字节堆块被当成 0x20000001 项遍历，内核堆越界读写（10-24）
    • 上一期合入的 ESP-IDF v6.1 适配在 master 上把 C3／C6 构建打红，include 顺序修复已提（10-25）
    • 既有缺陷提案的状态盘点：NVMe 泄漏、9PFS 长度、tmpfs UAF、dlmodule 全局量、FDT 深度均待合并（10-25）
  • 三、官方与社区活动
    • 六届 RISC-V 中国峰会的系统软件视角报道刊出：RISC-V 瓶颈正从核转向系统软件（10-24）
    • GDR：把 RT-Thread 内核对象查看搬进 GDB，QEMU 闭环覆盖 3.1.x／4.0.x／4.1.x（10-25）
    • 两篇社区长文：Env 工具 v2.0.3 自定义安装，与 Studio 24 个隐式声明警告的完整排查（10-25）
    • 10-26 晚直播：RT-Thread 与边缘 AI 的手部康复外骨骼（10-25）
    • 嵌入式大赛三篇作品：端侧 Agent 多传感融合、ART-Pi2 USB 枚举诊断、OpenMV 嫌疑人跟踪（10-24／10-25）
  • 四、生态与厂商适配
    • TriCore（AURIX）进 Env SDK：tricore-gcc 13.4.1 与 qemu-tricore 两个包合入，覆盖 TC2xx／TC3xx／TC4xx（10-26）
    • ai/Agent 包新增语音转写端点，默认后端从 SiliconFlow 切到 DeepSeek 官方 API（10-23）
    • 全志 F101 与 H616 的 BSP 提案 172 个文件，ESP32-S3-DevKitM-1 也补齐了板级支持（10-24／10-26）
    • 驱动与 CI：OSPI 八线 Flash、I2C 控制事务串行化、STM32 包测试并发锁（10-23／10-25）
  • 五、总结与趋势观察
    • 本期趋势
    • 局限性与去重说明

一、内核与版本动态

1.1 主线 72 小时只有两笔提交：lwIP 回环 netdev 合入，clang-format 规则细化带 thread.c 示例（10-25）

日期：2026-10-23 17:09 与 2026-10-25 19:26（合入时间）　来源：PR #11859、PR #11893、主仓库提交记录

周末三天的窗口里，master 只落了这两笔提交，节奏与上一期「三日零提交后集中收尾」的判断连得上：合入动作都发生在非工作时段（周五 17:09、周日 19:26），评审本身没有停，只是开发侧没有新代码。

第一笔是 clang-format 规则的收口，2 个文件 +83/-77，只动 .clang-format 与 src/thread.c。分支名带着讨论线索 style/clang-format-discussion-11653，两个提交日期都是 10-09，主体是「对齐、花括号换行与空格规则」的细化，第二个提交把 src/thread.c 按新规则整体格式化作为示例。也就是说这是一笔拖了两周的评审收尾，不是新工作。提案里还记了一条工具事实：index++ 这类写法在 clang-format 18.1.8 与 23.1.3 上都会保持原样，没有对应配置项可以强制改写，校验用 --dry-run --Werror。

第二笔是 lwIP 回环设备进 netdev 框架，3 个文件 +54/-0。此前 lwIP 的回环口没有注册成 netdev，导致两类问题：走 127.0.0.1 的工具链跑不起来；没有物理链路的网络命名空间里没有默认可用的接口。改动新增 RT_LWIP_USING_LOOPBACK 配置项，把 lo／lo0 注册为 netdev 并置为 link up，在未指定接口时选回环作默认接口，同时把 RAW 接收邮箱调大以容纳回环回显。验证配置给的是 qemu-virt64-riscv，提案里写明「本地未编译，由 CI 验证构建」——这与上个月多笔提案的放行口径一致：合入以构建通过为条件，上板另行跟进。

版本侧依旧没有动作：最新发布物与标签还是 09-10 的 v5.3.0，10-17 那笔 v5.4.0 的版本宏至今没有配发布说明、二进制或预发布标签。

1.2 qemu-virt64 打开 RT-Thread Smart：riscv64 关 SMP、ext4 与 elm 挂块设备、ptyfs 与 procfs 上挂（10-25）

日期：2026-10-25 19:50（最后更新）　来源：PR #11896

这份提案 14 个文件 +1263/-1075，把 qemu-virt64-riscv 与 qemu-virt64-aarch64 两个 BSP 的 RT_USING_SMART 打开。此前这两个 virt 平台名义上支持 Smart，但 virtio 块设备没有标准的根文件系统初始化流程，pty 也没有挂载点，很多特性在 QEMU 下根本没法测。

改动可以拆成四块：riscv64 侧关掉 SMP，与 Smart 的单核配置对齐；新增一段初始化流程，在 virtio-blk0 上挂 ext4 或 elm；把 ptyfs 挂到 /dev/pts、procfs 挂到 /proc；重新生成 .config 与 rtconfig.h。构建验证写明 riscv64 用 RISC-V musl 通用工具链、aarch64 用 aarch64 musl 工具链，本地未跑、由 CI 验证。

值得注意的是依赖关系：这份提案显式依赖刚合入的 #11893（RT_LWIP_USING_LOOPBACK 配置符号），.config 是在 #11893 之上生成的，作者说明会在依赖合入后 rebase 并重新生成配置。这类跨提案的配置耦合在 qemu 平台改造里常见，也解释了为什么回环口要先于 Smart 使能落地——没有回环，Smart 下大量依赖本机地址的测试跑不起来。

1.3 lwp_syscall.c 一万一千行拆分：165 个系统调用入口按子系统分文件，行为不变（10-25）

日期：2026-10-25 19:50（最后更新）　来源：PR #11894

components/lwp/lwp_syscall.c 单个文件超过一万一千行，把内存、文件系统、socket、进程、IPC 与时间六类系统调用堆在一起，评审与检索都很困难。提案把它拆到 components/lwp/syscall/ 目录，按子系统分文件，新增共享的系统调用分派表与内部头文件，并在 LWP 的构建脚本里注册新目录。

规模上这是本窗口最大的一笔：22 个文件 +12223/-11638，几乎全是移动与改名。提案自称「机械重构，无功能变更」，并强调 165 个系统调用入口与行为完全保持不变。验证同样是「本地未编译，CI 验证」，配置是 CONFIG_RT_USING_SMART=y。

从工程角度看，这类拆分本身不产生新能力，但它决定了后续 lwp 缺陷（例如本期 2.2 的 sys_poll 回绕）能不能在一个可读的文件里定位。上一期记录的那份 9PFS 长度收敛提案也属于同一条线索：Smart 侧的代码正在从「能用」转向「可维护」。

二、安全与稳定性跟进

2.1 时间子系统一夜间四单连报：settimeofday 窄化、gmtime_r 负时间戳、timer_gettime 截断，附一份 A 至 F 工作项调研（10-23／10-24）

日期：2026-10-23 21:04 与 2026-10-24 20:25（创建时间）　来源：Issue #11922、Issue #11923、Issue #11924、Issue #11927

10-23 晚间，同一研究者在 components/libc/compilers/common/ctime.c 上连着开了三单，加上次日的一份调研单，把时间子系统的语义问题一次性摊开。三单的基线都是 master 的 a59e72fb5c，全部为源码级隔离复现，未上板。

第一单是 settimeofday() 的类型窄化：校验时先 (long)tv->tv_sec 强转，在 time64／long32 的 32 位 ARM ABI 下（time_t 为 64 位有符号、long 为 32 位），合法的正时间戳会被转成负数，于是在调 RTC 驱动之前就返回 -1 并置 EINVAL。作者用 GNU Arm Embedded 10.3-2021.10 做了类型尺寸与窄化行为的隔离验证。

第二单是 gmtime_r() 对负时间戳的处理：函数返回非 NULL，但字段非法。给出的四个对照值很直观——-1 得到 1970-01-01 00:00:-1、-86400 得到 1970-01-00 00:00:00（yday 为 -1）、-31536000 的年份字段变成 1970-01--364、-2208988800 应为 1900-01-01 却得到 1970-01--25566。根因是取模取余都用 C 的向零截断语义，负输入下余数为负，而年份循环只能向未来走。

第三单是 timer_gettime() 的截断：总剩余纳秒先存进 rt_uint32_t 再拆秒与纳秒，10 秒即 100 亿纳秒，赋给 32 位变量直接丢失高位。受影响配置是 RT_USING_POSIX_TIMER 与 RT_USING_CLOCK_TIME 同时打开。

第四单（10-24 20:25）不是缺陷而是调研：把 tick、clock_time、RTC、libc 与 VDSO 各自维护时间基线的问题整理成一份带工作项的设计建议，列出十项不足（设时不统一、clockid 语义混乱、软 RTC 假同步、回绕与溢出、hrtimer 回退、PM 分叉、启动授时状态、NTP 版本边界等），给出 A 至 F 六项可跟踪工作项与 P0 至 P2 的优先级，并明确普通 MCU 走完 A 至 D 即到阶段性终点。该单自己声明是静态分析，未编译未上板。

配套的修复提案已经开出两笔：#11928 让 settimeofday() 按字段自身类型校验、不再统一转 long；#11929 处理 gmtime_r() 对纪元前时间戳的规范化。两笔都在 10-24 提交，仍未合并。

2.2 32 位 RT-Smart 的 sys_poll 回绕：8 字节堆块被当成 0x20000001 项遍历，内核堆越界读写（10-24）

日期：2026-10-24 03:39（创建时间）　来源：Issue #11925

这份缺陷单在 10-24 凌晨提交，问题落在 components/lwp/lwp_syscall.c 的 sys_poll() 与 libc 侧的 poll() 之间。用户态传入的 nfds 在计算分配大小时，nfds * sizeof(struct pollfd) 在 32 位目标上以 size_t 宽度运算，超过约 1.79 亿项就会回绕成一个小值——于是内核按 8 字节的堆块去做 0x20000001 项的遍历，读写都落在堆外。

影响面按作者给出的口径：仅 32 位 RT-Smart 受影响，64 位构建下乘积会提升到 64 位，超大分配直接以 -ENOMEM 失败，不会回绕。引入点是 2022-12-03 的 ecf2d821（sync branch rt-smart，#6641），首个受影响版本为 v5.0.0，v5.0.0 至 v5.3.0 与当前 master（5d1fb66d）均在列。复现用的是 bsp/qemu-vexpress-a9。

这条与上一期 9PFS、NVMe 那族「设备或服务端可控的元数据当长度用」不同：这次是用户态可控的计数在窄位宽下回绕，属经典整数边界问题，但因为落点在系统调用入口与内核堆之间，后果直接是内核堆越界读写。该单目前无对应修复提案。

2.3 上一期合入的 ESP-IDF v6.1 适配在 master 上把 C3／C6 构建打红，include 顺序修复已提（10-25）

日期：2026-10-25 17:49（最后更新）　来源：PR #11926、PR #11870（上期合入）

上一期记录的 ESP32-C3／C6 适配 ESP-IDF v6.1 于 10-22 合入，当时的上板一栏写的是「待验证」。两天后 master 上的 C3／C6 构建转红：按提案描述，master 的两次 CI 运行（40043597502、39929831359）复现了同一现象，并且所有 PR 的 RT-Thread BSP Static Build Check 与 MemBrowse Memory Report 都跟着变红。

根因不在适配代码本身，而在构建顺序。ESP-IDF 包在 components/rtthread/scons/ 下放了一个 FreeRTOS.h 的 scons shim，用 #include_next 转发到 <freertos/FreeRTOS.h>，要求 RT-Thread 的 FreeRTOS-Wrapper include 目录排在 shim 之后、ESP-IDF 自带 FreeRTOS V11 内核头之前。但两个包的 SConscript 加载顺序由目录遍历顺序决定，并不稳定；一旦 ESP-IDF 先加载，#include_next 就解析到 V11 的头，Wrapper 提供的 configNUMBER_OF_CORES、configMINIMAL_STACK_SIZE、configUSE_PREEMPTION 等默认值全部落空，编译 drv_uart.c 时直接 #error。

修复提案只动 3 个文件，把 FreeRTOS include 目录顺序固定下来。这条值得记一笔的原因不是缺陷本身，而是反馈链条：上期以「构建通过」为放行条件的合入，在本期被 CI 抓到了顺序依赖，修复提案当天就开出来了。

2.4 既有缺陷提案的状态盘点：NVMe 泄漏、9PFS 长度、tmpfs UAF、dlmodule 全局量、FDT 深度均待合并（10-25）

日期：2026-10-25（核查时间）　来源：PR #11920、PR #11918、PR #11910、PR #11915、PR #11901

上期收录的几笔修复在窗口内都有更新，但都没有合入，状态停在「提案已开、等待评审」：NVMe 每遇一个非活动命名空间漏分配（#11920，10-25 00:35 更新）、9PFS 把服务端长度字段收敛到实际接收字节（#11918，10-24 17:19 更新）、tmpfs 截断到零长度时的释放后使用（#11910，10-23 23:31 更新）、可加载模块未初始化全局量（#11915，10-24 17:27 更新）。

窗口内补进来的两笔是新的：一是 FDT 解平铺的深度限制（#11901，10-25 15:49 更新），fdt_unflatten_single() 用固定 64 项的栈 np_stack 暂存遍历路径，压栈前不查深度，深度超过 64 层的 DTB 会栈越界写，作者在 qemu-virt64-aarch64 上复现，修法是在解平铺前用一条独立的手工栈遍历算出最大深度、超过 63 层直接拒绝；二是串口 rx_indicate 被误清（#11931，10-26 01:34 更新），echo xxx /dev/uart0 之后控制台不再响应，作者排除了「open_flag 被覆盖」这条旧解释——现在 rt_device_open() 在 OFLAG_MASK 匹配时根本不调驱动的 open——把真因定在 serial_fops_close() 无条件清 rx_indicate，而设备仍被控制台持有（ref_count 只从 3 降到 2）。

同一批里还有两笔驱动层的正确性修补：#11891 改 TIOCGWINSZ 不再借 finsh_getchar() 读终端应答（原来会消耗输入、且只在 tshell 线程可用），并在 termios 未变化时跳过 UART 重配以免复位 FIFO；#11885 修 utimensat() 对 UTIME_OMIT 的判断取反，此前请求「不改 mtime」反而会覆盖 mtime 并忽略调用方给的时间戳。

三、官方与社区活动

3.1 六届 RISC-V 中国峰会的系统软件视角报道刊出：RISC-V 瓶颈正从核转向系统软件（10-24）

日期：2026-10-24（发布）　来源：电子工程专辑：端侧 AI 成 RISC-V 新战场、RT-Thread 专栏页

RT-Thread 在电子工程专辑的专栏于 10-24 刊出一篇峰会侧记，标题把落点放在「端侧 AI 成 RISC-V 新战场」。报道给出的峰会规模是 1 场主论坛、7 场平行分论坛加 Member Day 技术专场，议题覆盖人工智能、数据中心与高性能计算、软件生态、嵌入式与物联网、芯片设计与验证、汽车电子与机器人。

与 RT-Thread 直接相关的是两段表述：峰会期间，RT-Thread 与多家 RISC-V IP 及芯片厂商就内核适配、工具链打通与联合方案落地交换意见；业内判断 RISC-V 在嵌入式与物联网已具备规模化条件，瓶颈正从「核」转向系统软件，而操作系统的参与补的是实时性、功能安全与工程化交付这一环。报道未展开具体演讲题目与产品发布，正文以图片为主，本期只取上述可核对的表述，不代拟细节。

需要说明的是，峰会本体在 10-18 至 10-20 于深圳举行，产业侧的芯片发布已由前几期 RISC-V 日报收录，本期只补系统软件视角与 RT-Thread 相关的这一篇，避免跨主题重复。

3.2 GDR：把 RT-Thread 内核对象查看搬进 GDB，QEMU 闭环覆盖 3.1.x／4.0.x／4.1.x（10-25）

日期：2026-10-25（发布）　来源：电子工程专辑：从 LoRaWAN 移植踩坑出发、GDR 仓库

这是一篇少见地把「调试脚手架」当正式工程来做的社区长文。起点是两年前把 Semtech 的 LoRaWAN 协议栈 SWL2001 从 Zephyr 移植到一颗资源受限的国产单片机上，底层是裁剪过的 RT-Thread Nano；四十多个 HAL 接口逐个映射，任何语义偏差都只在运行期暴露。真正的难点在观测：FinSH 一跑，radio planner 的时序就被扰动，观测行为改变了被观测系统；GDB 原生只给指针，看一个信号量要沿 rt_object_container 走链表、做 container_of 换算再 cast，十个对象就是五六十条命令。

GDR 的做法是把这类机械劳动固化成 GDB 的 Python 命令，提供三层能力：聚合命令（rtthread threads／timers／system／semaphores／objects）输出全局快照，线程表里带 StkUsed 与 MaxStkUsed 两个基于栈填充模式的峰值水位；便捷函数 $gdr_thread("worker2") 与 $gdr_object(...) 返回原生 gdb.Value，后续字段钻取仍用 GDB 表达式；pretty-printer 把内核对象折叠成一行摘要，例如互斥量直接显示持有者。

与 FinSH 的本质区别是完全无侵入：所有信息只通过 GDB 读符号与目标内存，不调用固件里的任何函数，因此既适用于根本没有 shell 的 Nano 场景，也适用于 HardFault 之后已经无法执行代码的死后分析。工程上几个决定值得记：不再自动探测 RTOS（改为显式 gdr init rtthread 4.0.5，但用符号存在性探测 SMP、堆管理器、IPC 组件这些配置差异）；所有布局知识集中在一个文件里并标注 COUPLED；用 QEMU 启动真实固件做 pytest 断言，CI 矩阵覆盖 Cortex-A9（3.1.0 至 3.1.5、4.x）与 RV64（4.0.4 至 4.1.1）。作者也写明了边界：本人已不做单片机开发，工具只在 QEMU 矩阵里验证过，尚未经真实板卡检验；后续计划是 agent skill、VSCode 插件与 FreeRTOS 适配。

3.3 两篇社区长文：Env 工具 v2.0.3 自定义安装，与 Studio 24 个隐式声明警告的完整排查（10-25）

日期：2026-10-25 18:45 至 18:46（发布）　来源：Env 工具 v2.0.3 使用记录、Studio 24 个隐式声明警告排查

社区文章接口在 10-25 傍晚连续放了两篇工具链长文，都属「踩坑加修法」的类型。

第一篇讲 Env 2.0.3 的自定义位置安装。Env 从 v2.0 起做了架构性重构：命令入口统一为 rt-env，menuconfig／pkgs／scons 变成它的子命令，另加 sdk、plugin、webui、system；依赖全部跑在 Python 虚拟环境里；新增插件体系与浏览器端 WebUI；每个终端要先 dot-source 激活脚本才能用。官方安装脚本把位置写死为 ~/.env，想把工具链放进项目目录只能手工复刻目录结构，文章给了完整步骤与本机验证的版本组合（rt-env v2.0.3、SCons 4.11.1、kconfiglib 14.1.0、pyyaml 6.0.3）。文中还标了一条兼容红线：Env v2.0 完整支持 RT-Thread 5.1.0 以上的 master 分支，5.1.0 及更早继续用 v1.5.x。

第二篇是 RT-Thread Studio 构建告警的完整溯源，正好对应本期主线提案 #11930。scons --dist-ide 导出的工程在 Studio 里编译，五个内核源文件报 24 个 -Wimplicit-function-declaration（clock.c 1、ipc.c 7、thread.c 12、timer.c 1、scheduler_comm.c 3），全部指向 rt_sched_* 系列内部调度 API。作者的排查路径是：先对比两种构建的编译命令行，发现 scons 带 -D__RT_KERNEL_SOURCE__ 而 Studio 的 make 没有；再回到 include/rtsched.h 找到宏守卫；最后定位到宏是通过 LOCAL_CPPDEFINES 注入，而 Studio 构建前的 Eclipse 工程生成器只收集全局 CPPDEFINES，LOCAL_CPPDEFINES 根本不进生成的 rtconfig_preinc.h。文中特别提醒：这些警告在 GCC 14 起默认升级为错误，对用新工具链的人是构建失败而不是噪音。对应提案 #11930 只改 1 行，把宏移到 Kernel 组的全局 CPPDEFINES，与 msvc 分支的写法对齐。

3.4 10-26 晚直播：RT-Thread 与边缘 AI 的手部康复外骨骼（10-25）

日期：2026-10-25（发布）　来源：电子工程专辑：下周一晚 8 点

10-25 发布的直播预告：10-26 20:00 至 21:00，社区开发者崔竣硕分享手部康复外骨骼项目。作品面向脑卒中、手外伤术后及周围神经损伤人群的手功能训练，把感知、识别、辅助、交互、评估做成一套平台。两个看点写得比较具体：从肌电信号到运动意图的识别链路，以及一块开发板上双核如何分工协作。

从主题看，这条与本期 3.5 的端侧 Agent 作品、4.2 的 ai/Agent 包更新属同一方向：RT-Thread 侧的社区内容正在从「点灯与联网」转向「传感加上端侧推理」的整机方案，双核异构与实时性分工是反复出现的结构。

3.5 嵌入式大赛三篇作品：端侧 Agent 多传感融合、ART-Pi2 USB 枚举诊断、OpenMV 嫌疑人跟踪（10-24／10-25）

日期：2026-10-24 12:03 至 2026-10-25 10:39（发布）　来源：端侧 Agent 多传感融合、ART-Pi2 USB 枚举诊断仪、OpenMV 嫌疑人跟踪

2026 嵌入式大赛的作品在窗口内集中放出三篇，硬件与软件取向各不相同。

端侧 Agent 那篇基于英飞凌 Edgi-Talk 板（PSoC E84：Cortex-M55 加 Ethos-U55 NPU，另有 Cortex-M33 协处理，片上最高 6 MB SRAM），系统是分布式传感采集、MQTT 汇聚、端侧多源融合、智能识别决策加 LVGL 看板。值得注意的实现细节是：agent 包把 MQTT 的订阅、退订、查历史封装成「工具」，由 agent 内核按注册的工具调度；UI 是一条线程加一组定时器，800×480 逻辑画布画在 480×800 竖屏上再靠 GPU 旋转，所有页面只在 LVGL 线程里改。Agent 内核的框架文档指向作者自己的仓库。

ART-Pi2 那篇做的是 USB 枚举的可观测性：用 CherryUSB 的主机适配层在控制传输开始与完成时记录请求参数、返回状态与描述符字节，事件进有界队列，再由 RT-Thread 分析线程调用共享的 C99 规则核心生成判定；规则结论保留来源事件与字节引用，板端发布不可变的证据快照，4.3 寸 LCD 与局域网网页围绕这份会话展示，可以从一条规则结论一路回查到原始字节。硬件是 ART-Pi2（STM32H7R7）加正点原子 4.3 寸 RGB 屏，Wi-Fi 由板载 CYW43438 提供。

第三篇是 RA8P1 Titan Mini 加 PC 上位机的行人跟踪：板端用 OpenMV 固件跑 YOLOv8n（192 输入、Ethos-U55 NPU），经 USB CDC 自定义协议把检测结果与视频流送到 Python 上位机，操作员在画面上点一下即锁定目标，红框带运动预测跟随并烧进录像。实测帧率给得很细：QVGA 无检测约 25 fps、带检测 16 至 19 fps，VGA 带检测约 8 fps。

四、生态与厂商适配

4.1 TriCore（AURIX）进 Env SDK：tricore-gcc 13.4.1 与 qemu-tricore 两个包合入，覆盖 TC2xx／TC3xx／TC4xx（10-26）

日期：2026-10-26 00:10 与 07:57（合入时间）　来源：RT-Thread/sdk PR #9、RT-Thread/sdk PR #10、toolchains-ci v1.12、toolchains-ci v1.13

本期最实质的一笔不在主仓库，而在 Env 的 SDK 仓库：两个 PR 先后合入，把 Infineon TriCore（AURIX）这条车规架构的编译与仿真通路补进了 RT-Thread 的工具链体系。

第一笔是 tricore-gcc 工具链包，4 个文件 +112，Linux 与 Windows 各一套 Kconfig 与 package.json，包名 tricore-gcc、版本 v13.4.1、开关 PKG_USING_TRICORE_GCC。工具链上游是 NoMore201/tricore-gcc-toolchain（EEESlab 11.3.0 的下游，带 CI 自动构建），组成是 GCC 13.4.1、binutils 2.40、newlib、GDB 14.0，目标三元组 tricore-elf，覆盖 TriCore 1.3／1.3.1／1.6／1.6.1／1.6.2／1.8，对应 TC2xx、TC3xx、TC4xx 三代芯片。发布物放在 toolchains-ci 的 v1.12：Linux 包 251 MB，Windows 包 466 MB。Windows 包补了上游漏带的 libwinpthread-1.dll（同时放在 bin/ 与 libexec/gcc/tricore-elf/13.4.1/），否则在未装 MSYS2 的机器上编译器起不来。

第二笔是 qemu-tricore 模拟器包，同样是 4 个文件 +112，开关 PKG_USING_QEMU_TRICORE，版本 v1.0.0，发布物在 toolchains-ci 的 v1.13（Linux 5.4 MB、Windows 9.4 MB）。背景写得清楚：tricore-gcc 包自带的 QEMU 9.2.3 只有 KIT_AURIX_TC277_TRB（TC2xx）与 tricore_testboard 两台机器，仿真不了 TC3／TC4，所以单独引入 Zephyr 侧在用的一支。源码是 linumiz/qemu-tricore 的 release/ifx/tricore-1.0 分支（tag v1.0.0，QEMU 10.2.94），支持的三台机器是 KIT_AURIX_TC277_TRB、KIT_AURIX_TC397B_TRB、KIT_A3G_TC4D7_LITE，CPU 模型 tc2x／tc3x／tc4x。外设只做了 ASCLIN0 串口、STM 系统定时器、IR 中断路由、SCU 与时钟、SFR 桥、片上 RAM 与 Flash 映射，CAN、以太网、ADC、GPIO、DMA 都没有——够跑内核与串口 shell，不够做外设驱动验证。为支持 Windows 交叉编译，TriCore 侧还改了两处可移植性问题（ENOTBLK／O_* 条件编译与 hwaddr 日志格式）。

两点必须写清楚。其一，这只是工具链与仿真先行：主线的 libcpu 目录现有 19 个架构（aarch64、arc、arm、avr32、blackfin、c-sky、ia32、m16c、mips、nios、ppc、risc-v、rx、sim、sparc-v8、ti-dsp、unicore32、v850、xilinx），没有 tricore，bsp 下也没有 AURIX 板级目录；仓库里能查到的 TriCore 记录是 2020 年前后的几次尝试（#4311 架构适配、#4488 与 #4527 的 TASKING 工具链与 FinSH 支持），状态都是 Closed，没有并入主线。其二，两笔提案的 Windows 包都只做了 PE 导入表检查，未在 Windows 实机运行，作者自己在 PR 里建议合入前补跑一次编译。

把这两点合起来看，意义在于路线变化：早年的 TriCore 适配依赖 TASKING 商业工具链，门槛高且难以进社区；这次换成开源 GCC 13.4.1 加 QEMU 仿真，先解决「能编、能跑、能调」，至于 BSP 与驱动，是后面的事。对车规场景（域控、安全岛、AURIX TC3xx／TC4xx 是这块的主力）而言，这是必要但不充分的一步。

4.2 ai/Agent 包新增语音转写端点，默认后端从 SiliconFlow 切到 DeepSeek 官方 API（10-23）

日期：2026-10-23 10:12（合入时间）　来源：RT-Thread-packages PR #2046

软件包索引里的 ai/Agent 包在窗口内更新了 Kconfig，+32/-4，只动一个文件，但两处默认值变化值得记。模型名默认值从 deepseek-ai/DeepSeek-V4-Pro 改为 deepseek-flash；接口地址默认值从第三方聚合平台的 api.siliconflow.cn 改为 DeepSeek 官方端点 api.deepseek.com（两者路径同为 chat/completions）——也就是说默认路径从聚合平台换成了原厂端点。

新增的是语音转写配置块：一个开关选项（PKG_AGENT_STT_ENABLE／DISABLE，默认开），加上一个 STT File Server 字符串，语义是 HTTP 文件上传端点，示例给的是本机地址加 /stt 路径。多模态开关的说明文字也从「图像／文件」扩成「图像／文件／音频」，与 STT 配置对应。

这条与本期 3.5 的端侧 Agent 大赛作品可以对读：作品里 agent 包把 MQTT 操作注册成工具供内核调度，其引用的 Agent 框架仓库与本次提案的作者同属一个 GitHub 账号；一篇讲用法，一笔改配置，指向同一种用法——把 RTOS 当作 agent 的运行时，让模型通过「工具」去操作设备能力。默认后端切到官方 API 之后，开箱即用的门槛会低一些，但代价是把联网依赖绑定到单一供应商，这一点在资源受限场景需要自行权衡。

4.3 全志 F101 与 H616 的 BSP 提案 172 个文件，ESP32-S3-DevKitM-1 也补齐了板级支持（10-24／10-26）

日期：2026-10-24 03:32 与 2026-10-26 02:05（最后更新）　来源：PR #11877、PR #11844、PR #11903

本窗口的 BSP 侧以提案为主，规模最大的是全志那条线（#11877），172 个文件 +35428/-6，一次带进 F101 YuzukiNeko 与 H616 两块。F101 侧补的是 Sun252i 的设备模型驱动集：时钟、复位、pinctrl、DMA、SDIO、SPI、USB、音频、温度、RTC、PWM、ADC、NVMEM、看门狗、DVFS、G2D 与 JPEG；显示侧新增 Sunxi DE0／TCON0 后端，支持 RGB、LVDS 与 MIPI-DSI，并给了 ST77916 QSPI 屏的板级配置与验证命令；此外补了 Sunxi MUSB 在 CherryUSB 下的胶合层，以及一批共享驱动框架的修复（电源域、DVFS、图形、UART 复位与寄存器位移、QSPI 配置、温度工作队列、输入捕获、设备模型 USB 集成）。H616 侧是另一套驱动集：CCU／复位、pinctrl、温度、CPU DVFS、codec、AHUB HDMI 音频、CE 硬件加密、DE33 HDMI framebuffer、TCON TOP，加上 RTC、DMA、SDIO、I2C、SPI、PWM、看门狗、IR、SID NVMEM、GPIO LED、JPEG 解码、G2D、GPADC、LRADC，并新增 AXP313A 调压器支持。

另一笔是 ESP32-S3-DevKitM-1（#11844），52 个文件 +7152/-29。这条要分清内核：ESP32-S3 是 Xtensa，不在 RISC-V 之列（C3／C6 才是）。提案里写了几个实操细节：builtin_imgs 里的 bootloader 与分区表必须用 S3 的、不能拿 C3 的替换，Flash 是 DIO、8 MB、80 MHz，应用在 0x10000；板级共享改动三处（SoC 收进 choice 默认仍为 C3、S3 的节拍中断只加 tick、sdkconfig.h 转去包含 sdkconfig_s3.h）。上板验证做了：能进 msh，help／version／ps／free 有回应，版本报 5.3.1，free 显示 total 76704、used 12192、available 64512，ps 里 timer 与 main 的 error 列为 EINTRPT 但 shell 与节拍正常。GPIO、I2C、SPI、ADC、PWM、Wi-Fi、BLE 与片内 8 MB PSRAM 均未上板验证，README 标注为待支持。

还有一笔小的是 D1s 的 QEMU 启动脚本（#11903），4 个文件 +145，给 allwinner d1s BSP 加了 qemu-d1s.sh 与文档，让这块 BSP 能直接在 d1s 机器上跑；作者注明脚本与文档由 AI 辅助编写、已人工审阅并实测。

4.4 驱动与 CI：OSPI 八线 Flash、I2C 控制事务串行化、STM32 包测试并发锁（10-23／10-25）

日期：2026-10-23 至 2026-10-25（更新与合入时间）　来源：PR #11912、PR #11820、pkgs-test PR #37

驱动层最大的一笔是 OSPI 与 OctaFlash 支持（#11912），32 个文件。此前 RT-Thread 的 SPI 驱动层没有原生的 OSPI 通路，八线 Flash 只能绕。改动在 components 层补 OSPI 的总线、设备、配置与消息定义，以及传输辅助函数与构建选项，同时保留既有 SPI 与 QSPI 路径；把 OSPI 传输与探测接进 SFUD，支持读、写、擦除与状态／控制操作，并在 SFUD 设备表里加了 MX25LM51245G 用于验证；为了让整条路径能在硬件上跑通，还加了通用 STM32 OctoSPI 驱动与 stm32l4r9-st-eval 的板级 OSPI Flash 支持，使 SFUD 能以 1-1-1 与 8-8-8（OPI STR／DTR）两种模式访问。

I2C 那笔（#11820）修的是总线控制与传输的竞态：rt_i2c_control() 可能在 rt_i2c_transfer() 使用总线期间改控制器配置，尤其在 SET_MAX_HZ 上。改法是让控制命令取同一把总线互斥锁、走统一出口释放，并在 API 文档里写明控制需要线程上下文。验证用的是主机侧 pthread 互斥适配器，覆盖并发传输与控制、控制与控制、频率更新、锁与回调错误、以及控制里嵌套传输；未打补丁的源码在同一回归集里失败。

CI 侧的那笔在 pkgs-test（#37），1 个文件 +11/-7，解释得很完整：STM32 软件包测试并行跑多个版本，每个任务有独立 BSP 副本，但仍共用 bsp/stm32/libraries 下的 HAL／CMSIS 驱动目录；原来的 sem_stm32 只保护编译、不保护依赖更新，于是会出现一个任务在另一个任务克隆依赖未完成时对同一目录 git pull，Git 报未跟踪文件将被覆盖并中止，失败又被框架统一报成 compile failure。上一期合入的 #11870 测试即栽在这上面（失败日志可查）。修法是把锁上移到 __build()，让依赖更新与编译处在同一个临界区，同时删掉 __build_scons() 里的重复加锁避免自死锁，并用 try/finally 保证异常释放。

五、总结与趋势观察

5.1 本期趋势

  • 车规架构走「工具链先行」：TriCore／AURIX 这次进的是 Env SDK 而不是主仓库——开源 GCC 13.4.1 与 qemu-tricore 两个包先补齐编译与仿真，主线 libcpu 仍无 tricore 移植、bsp 下也无 AURIX 板级目录。对比 2020 年前后依赖 TASKING 商业工具链的那批尝试（均以 Closed 收场），这次的路径更可能落地，但距离「能上板」还差 BSP 与驱动。
  • 主线极静、提案面极活：72 小时 master 只有 2 笔提交，而窗口内 25 笔 PR 有更新、6 笔合入（主仓库 2、sdk 2、packages 1、pkgs-test 1）。合入动作集中在周五傍晚与周日晚间，评审没停，开发侧确实在收。
  • 缺陷研究从单点转向子系统：时间子系统一夜间四单（三缺陷加一份带 A 至 F 工作项的调研），两笔修复提案次日提交，形成「报—析—修」的短闭环；lwp 的 sys_poll 回绕则单列出 32 位 RT-Smart 在用户态可控计数上的整数边界问题，与上期那族「设备或服务端元数据当长度」的缺陷互补，说明内核仍在为历史包袱付账（ecf2d821 可追到 2022 年）。
  • 以构建为放行条件的合入开始被 CI 反噬：上一期 ESP-IDF v6.1 适配合入两天后，master 上 C3／C6 构建转红，波及所有 PR 的静态构建检查；修复提案当天开出。这条链条本身是健康的，但也说明「本地未编译、CI 验证」的口径需要配套的顺序稳定性保障。
  • 端侧 AI 的落点从跑模型转向接工具：ai/Agent 包加 STT 上传端点、默认后端换到 DeepSeek 官方 API，社区大赛作品用 agent 包把 MQTT 操作注册成工具供内核调度，加上 10-26 晚的「双核加肌电意图」直播，方向一致——RTOS 正被当成 agent 的运行时，实时性与异构分工是它相对通用 Linux 的卖点。

5.2 局限性与去重说明

  • 本期为 72 小时窗口（10-23 08:00 至 10-26 08:00），周一，覆盖周六周日，与上一期（10-22 08:00 至 10-23 08:00，24 小时）衔接，无重叠。
  • 与上期去重：#11920、#11918、#11910、#11915 上期已收录，本期只在状态确有更新时集中盘点，不重复描述缺陷机理；#11870 上期按「阻塞解除、上板待验」收录，本期只写其在 master 上引发的构建回归与新修复提案；#11896、#11894 上期已有记录，本期补的是最新状态与改动细节。
  • 匿名 GitHub 接口限额在采集中途耗尽，后续以网页端核对与既有检索结果为准，未做组织级全量推送核查；sort=pushed 前 100 仓显示窗口内 5 个仓有推送（sdk、toolchains-ci、rt-thread、pkgs-test、packages）。
  • 官方新闻接口仍停在 2026-06-17（本次返回 5 条），官网新闻列表页为前端渲染、抓取只得空壳；社区文章接口本期新增 5 篇，均已核对标题与更新时间。
  • 行业媒体侧，电子工程专辑 RT-Thread 专栏窗口内共 4 篇：10-24 峰会稿、10-25 的 GDR 与外骨骼直播、以及 10-23 的 CherryUSB HID 教程；最后一篇发布时间贴近窗口起点且属教程类，本期未单列。检索时需注意同专栏里 a422289 是 2025 年第五届峰会旧稿，标题相近易混淆，本期以专栏页 10-24 的 a533499 为准。
  • topic:rt-thread 生态检索窗口内 2 个仓有推送：sejtam-dev/AKP05E-Open-Firmware（ArtInChip D13x、RISC-V、基于 RT-Thread 的第三方开源固件，星标 0）与 zlgopen/awtk（通用嵌入式 GUI，提交与 RT-Thread 无专项关联）；均作生态参考，未单列条目。
  • 未做上板验证：TriCore 两个包的 Windows 构建仅做 PE 导入表检查；时间子系统三单为源码级隔离复现；OSPI 提案的硬件验证基于 stm32l4r9-st-eval。报告中相关结论均按来源原文表述，不外推。

附录：信源核查表

信源 核查结果
RT-Thread 官方新闻接口（组织分类） 无新增，仍返回 5 条，最新停于 06-17
官网新闻列表页 前端动态渲染，抓取只得加载空壳
社区文章接口（article） 窗口内新增 5 篇：Env v2.0.3 记录、Studio 24 警告排查、三篇嵌入式大赛作品
GitHub 主仓库 commits 窗口内 2 笔：#11859 clang-format 规则、#11893 lwIP 回环
GitHub 主仓库 PR 25 笔更新，合入 2 笔
GitHub 主仓库 Issue 新开 5 笔：#11922 至 #11925 与 #11927，集中在时间子系统与 lwp
GitHub 主仓库 releases / tags 无新发布，最新仍为 09-10 的 v5.3.0
GitHub RT-Thread/sdk 合入 2 笔：tricore-gcc 与 qemu-tricore，toolchains-ci 出 v1.12、v1.13
GitHub RT-Thread/packages 合入 1 笔：ai/Agent 的 STT 配置与 DeepSeek 默认后端
GitHub RT-Thread/pkgs-test 合入 1 笔：STM32 包测试并发锁修复
GitHub topic:rt-thread 2 仓推送，均为生态参考，未收录
Google News 聚合（中英文，走代理） 中文 7 天窗口 1 条有效（EET-China 10-24 峰会稿），英文 0 条
HN Algolia 四条候选均为 threads 字面误匹配，已剔除
行业媒体（EET-China 专栏） 窗口内 4 篇，收录 3 篇，10-23 教程稿未单列
主线架构目录核对 libcpu 现有 19 个架构，无 tricore；旧提案 #4311 状态为 Closed

完整信源清单