Reporting period: Monday, October 26, 2026 through Friday, October 30, 2026 — 5 working days, 5 daily issues; also includes checks on the release day (October 31) of the main repository’s commit stream, proposal and defect queues, releases page, and tags page, covering wrap-up changes from 10-30 08:00 to 10-31 17:00 Sources: 5 issues of this publication’s daily RT-Thread updates (10-26, 10-27, 10-28, 10-29, 10-30), totaling an effective window from 10-23 08:00 to 10-30 08:00 (the Monday issue covers a 72-hour weekend-spanning window); release-day checks are based on live API measurements of the GitHub main repository and the repositories of each organization Editorial note: Covers five dimensions — kernel and versions, security and stability, ecosystem and vendor adaptation, official and community activities, and industry applications; facts and dates in the body are taken item by item from the original text of the corresponding daily issue; release-day supplementary entries are individually annotated with the verification method

I. Weekly Highlights

  • RT-Thread Smart lands in a single day after ten days in the queue, then is reverted from the default config seven and a half hours later (10-29): Proposal #11896, created on October 18, was merged at 09:29, enabling RT-Thread Smart for qemu-virt64-riscv and qemu-virt64-aarch64 — 14 files, +1263/-1075, 14 commits, with a new applications/mnt.c that mounts virtio-blk0 as the root directory and mounts ptyfs and procfs; at 14:48 and 14:50, the terminal compatibility proposal #11890 and the lwp syscall split proposal #11894 landed in succession; at 16:59, proposal #11942 restored the default configs of both BSPs entirely to the standard kernel (7 files, +51/-220), with Smart moved to running separately under utest’s config overlay. “Enable—verify—revert” all in one day is effectively the maintainers defining Smart’s place: keep the default config predictable, and run Smart through a separate overlay.

  • RT-Smart’s ioctl user-pointer boundary draws four reports in a row, extending from the terminal all the way to block devices, pipes, and mailbox (10-28 ~ 10-31): On 10-28, #11937 pointed out that the terminal subsystem port dropped FreeBSD’s copyin precondition, so an unprivileged process could read and write arbitrary kernel memory via open plus ioctl; on 10-29, #11952 repeated the same pattern on the block device side, with a 24-byte partition table written to a kernel address specified by the caller; on 10-30, #11958 landed on POSIX pipes, where FIONREAD and FIONWRITE write ring-buffer lengths directly into an unvalidated user pointer; on 10-31, #11960 escalated to the mailbox, where sys_mb_send() forwards a user-supplied pointer as a kernel object directly, enabling arbitrary kernel read/write. The common cause across all four is that RT-Smart’s ioctl adaptation layer assumes “the argument is already a kernel address,” while the user-space entry point performs no such conversion. The terminal-side fix proposal #11941 was submitted on the evening of 10-28 (6 files, +577/-52); the other three sites have no corresponding fix yet.

  • 21 commits and 16 proposals on mainline, with a rhythm of “stall first, then clear the backlog in bulk” (10-25 ~ 10-30): This week master took 21 commits and 16 merged proposals, distributed as one on 10-25, zero on 10-26, four on 10-27, seven on 10-28, seven on 10-29, and two on 10-30. A considerable share of the 10-27 to 10-29 merges were backlog proposals held for nine days or more — the four on 10-27 had author dates of 10-18, and the Smart group on 10-29 was also created on 10-18. This is the same pattern as last week’s “three days of silence, three hours of wrap-up”: development-side output lands all at once after review approval rather than advancing at a steady daily pace.

  • Automotive-grade TriCore (AURIX) enters the Env SDK via a “toolchain-first” approach (10-26): Two RT-Thread/sdk proposals were merged in succession: tricore-gcc v13.4.1 (GCC 13.4.1, binutils 2.40, newlib, GDB 14.0, covering the TC2xx/TC3xx/TC4xx three generations of chips) and qemu-tricore v1.0.0 (QEMU 10.2.94, supporting the TC277, TC397B, and TC4D7 machine models), released as toolchains-ci v1.12 and v1.13 respectively. It is important to distinguish that this is only a compile-and-simulate path: the main repo’s libcpu has no tricore among its existing 19 architectures, and there is no AURIX board-level directory under bsp; the batch of attempts around 2020 that relied on the TASKING commercial toolchain have all been closed. Compared with the old path, this step first solves “can compile, can run, can debug.”

  • Four test proposals held for over three months merged at once, a concentrated catch-up on test infrastructure (10-28): #11601, created on July 9, was merged on 10-28 at 14:44, bringing in a fix to utest summary statistics (a later unit passing no longer erases the failure count of earlier testcases), cutting the netdev test cases’ public-network dependency on 8.8.8.8 and Baidu, excluding signal 0 from installation under musl, and two clang-format cleanups. All three classes of problems carry the reverse risk of “the test ran wrong but the report says it’s fine”; only after the fix is CI’s verdict trustworthy. Complementing this, #11942 on 10-29 rewrote utest_auto_run’s config selection logic, changing “overwrite with a full git checkout” to appending a single disable switch line to .config.

  • The time subsystem spawns four reports overnight, two fixes move to mergeable status (10-23 ~ 10-26): The same researcher filed a series of reports on ctime.c: settimeofday()’s long type narrowing (under ILP32, legitimate timestamps such as 2040-01-01 are truncated to negative and rejected), gmtime_r() outputting illegal fields for negative timestamps (-1 yields 1970-01-01 00:00:-1), and timer_gettime()’s 32-bit truncation, plus a time baseline investigation ticket with six work items A through F. Fix proposals #11928 (+185/-135) and #11929 (+104/-9) both checked “mature version, mergeable” on 10-26 but were not merged this week. On 10-29, further investigation found that timer_settime() uses a 32-bit variable to hold a result on the order of 1e13, so a 10-second timer is actually armed for about 21 hours (#11938, +142/-5).

  • Version number raised to 5.4.0 development state; two institutionalization documents on version management and release process proposed the same day (10-29 ~ 10-30): On 10-29, #11942 raised RT_VER_NUM from 0x50301 to 0x50400, formally moving mainline into 5.4.0 development state; but releases and tags both remain at v5.3.0 from 09-10, with no pre-release tags or binaries. Two supporting documents appeared on 10-30: defect ticket #11956 proposes establishing version management CI and a release process (monthly reports on the Z line plus manual approval; the Y line every 3 to 6 months combined with hardware validation; split into work item groups B01–B05 and C01–C08), and proposal #11955 adds the mainline version and release process documentation. This is a rare “process-side” signal this week and warrants a check next issue on whether it lands in code.

  • Vendor side is still proposal-first: RA6W1 phase two lands, while the large-volume Allwinner and ESP32-S3 proposals keep soaking in the queue (10-26 ~ 10-30): Renesas RA6W1’s proposal #11934 was merged on 10-28 at 18:52, adding 24 Wi-Fi-side interrupt vectors and renaming two crypto entries in the ROM symbol table with the __rom_ prefix. Allwinner F101 YuzukiNeko and H616’s #11877 (172 files, +35428/-6) and ESP32-S3-DevKitM-1’s #11844 (cumulative +295371/-22825 after a 10-28 refresh) remain in the queue; the latter has been a full month since its 9-28 creation, with review attention falling on the wholesale import of the vendor SDK and license terms, not just whether the functionality runs.

II. Kernel and Version Dynamics

Versions and Mainline

Date: 2026-10-26 ~ 2026-10-31　Source: Main repository releases page

  • Official releases: Still no new releases or tags this week; the latest release artifact remains v5.3.0 from 09-10. Since 10-17, v5.4.0 has had only the version macro, and #11942 on 10-29 bumped RT_VER_NUM to 0x50400; since then there have still been no release notes, binaries, or pre-release tags. This document uses the framing “the version number has entered 5.4.0 development state but has not yet been released.”
  • Mainline commits: This week master had 21 commits and 16 proposals merged; at the organization level there were also two in RT-Thread/sdk (TriCore toolchain and QEMU emulator), one in RT-Thread-packages (ai/Agent configuration), and one in pkgs-test (STM32 package test concurrency lock).
  • Cadence characteristics: Zero commits on Monday, four on Tuesday, more than five on Wednesday, seven on Thursday, and two on Friday—a typical batch landing of backlogged proposals; merges clustered in the evening window (19:20 to 19:26, 14:44, 09:29 to 16:59), handled centrally by the same maintainer.
  • Release-day check (10-30 to 10-31): The main repository landed two more commits (#11915 dlmodule global variable fix, #11936 pinning clang-format to 22.1.8 and formatting everything), and the end state of releases and tags matches Friday’s daily report, with no new version.

This Week’s Merge List (21 commits / 16 proposals)

Date: 2026-10-25 ~ 2026-10-30　Source: Main repository master commit stream

Date Commits Content
10-25 1 commit lwIP loopback netdev (#11893, 3 files +54/-0, adds a loopback network interface switch)
10-26 0 commits No commits for 24 hours; 13 proposals churned in the queue
10-27 4 commits dfs UTIME_OMIT (#11885), SAL RAW socket protocol whitelist (#11888), poll changed to obtain fops from dfs_file (#11887), 8250 earlycon reads reg-io-width (#11889)
10-28 7 commits Four utest commits (#11601), MAINTAINERS removes FAL entry (#11939), RA6W1 vector table (#11934), DHCP raw option bounds (#11940)
10-29 7 commits qemu-virt64 enables Smart (#11896), ping statistics (#11900), TIOCLINUX and default window (#11890, two commits), lwp split (#11894, two commits), restore standard kernel default configuration (#11942)
10-30 2 commits dlmodule uninitialized global variables (#11915), pin clang-format to 22.1.8 and format everything (#11936, 75 files)
  • lwIP loopback (10-25): Previously the lwIP loopback interface was not registered as a netdev, so toolchains going through 127.0.0.1 could not run, and network namespaces without a physical link also lacked a default available interface. The change adds a loopback network interface switch, registers lo/lo0 as a netdev and sets it link up, and selects loopback as the default interface when no interface is specified. This commit is a prerequisite for the later qemu-virt64 Smart enablement.
  • The four boundary fixes on 10-27: The UTIME_OMIT branch condition was inverted, so timestamps that callers explicitly asked not to touch were overwritten instead; RAW sockets previously allowed only IPPROTO_RAW, so native socket scenarios such as ICMP could not work, and this was changed to whitelist validation; under DFSv2, poll obtained fops from the vnode and got a different structure, so it was changed to resolve through dfs_file while retaining the DFSv1 compatibility path; earlycon ignored the device-tree register width, and a unified solution now addresses early-log misalignment and garbled output on wide-register platforms. Together the four commits add 46 lines and delete 6, and three of them have an author date of 10-18.
  • The Smart group on 10-29: See “Review Queue Observations” in this chapter and the first item in Chapter I’s top stories.
  • The two commits on 10-30: The dlmodule uninitialized-global-variable fix had been in the queue since 10-24 (#11915) and was merged Friday morning; clang-format was pinned to version 22.1.8 and all kernel source was formatted (#11936), the final step that applies the rule refinement merged on 10-23 to the full codebase, touching 75 files.

Security and Defects

Date: 2026-10-23 ~ 2026-10-31　Source: Issue #11960

  • 16 new issues were opened this week, more than ten of them security-related. They fall into three families: time and libc semantics (#11922 settimeofday narrowing, #11923 gmtime_r negative timestamps, #11924 timer_gettime truncation, #11925 sys_poll count wraparound, #11927 time baseline investigation), RT-Smart boundaries (#11932 musl thread list use-after-free, #11933 signalfd global count out-of-bounds, #11937 terminal ioctl, #11952 block device ioctl, #11958 pipe ioctl, #11960 mailbox object pointer), and driver parameter validation (#11948 Bluetrum AB32, #11949 Bouffalo, #11951 HPM ADC channel out-of-bounds in all three, plus #11950 DM365 SPI divide-by-zero). There is also #11956, a feature issue for the version management process.
  • The RT-Smart boundary line is the most serious: The terminal, block device, pipe, and mailbox cases are completely identical in form—the adaptation layer treats user pointers as kernel addresses. The mailbox issue is the most severe: sys_mb_send() forwards without any validation, so an attacker can construct a fake object and the read/write range is no longer constrained by the value domain. All four issues trace back to the RT-Smart synchronization commit ecf2d821 of 2022-12-03; the first affected version is v5.0.0, and v5.3.0 and current master are all affected. They can be reproduced on QEMU.
  • Closed within the week: The DHCP raw option out-of-bounds read in #11913 was fixed by #11940, merged on 10-28 (+23/-5, 12 host-side ASAN regressions); the dlmodule uninitialized global variable in #11915 was merged on 10-30 at 10:54; the signalfd out-of-bounds in #11933 received fix proposal #11935 the day after it was opened (+41 lines, changing to a bounded slot lookup located by context, with listener unbinding added on the close path); the first half of #11925 was submitted as #11954 (+28 lines) on 10-30, with sys_poll() directly rejecting “byte count wraparound” counts on 32-bit.
  • Still in the queue or unclaimed: #11878 (lwip-dhcpd lease pool exhaustion infinite loop), #11905 (cromfs directory name out-of-bounds), #11917 (NFS out-of-bounds write), #11919 (NVMe heap leak, fix proposal #11920 not merged), #11902 and #11910 (tmpfs use-after-truncate, fix in #11910), #11918 (9PFS length convergence), #11901 (FDT depth limit), #11931 (serial rx_indicate erroneously cleared), #11932 (musl thread list), plus the four newly opened issues #11937, #11952, #11958, and #11960 (of which #11937 has proposal #11941, and #11938 fixes the timer truncation it introduced).

Review Queue Observations

Date: 2026-10-26 ~ 2026-10-31　Source: Main repository pull request list

  • The Smart batch is being advanced in two stages: Of the six created on 10-18, #11890, #11894, #11896, and #11900 have already landed on 10-29; #11892 (RISC-V-side MMU and user-mode page fault handling, 4 files +105/-8) and #11897 (add K230D support to K230) are still in the queue. The former covers XuanTie architecture selection and the SVPBMT option, early page-table pointers converted by kernel physical offset, and terminating only the current LWP rather than bringing down the kernel when an unhandled user page fault occurs; the latter involves real boards and awaits hardware-side confirmation. The pattern is “merge first what can be verified on QEMU, merge later what depends on real hardware.”
  • Large new hardware support under review: #11944 Realtek RTL8125 Ethernet driver (adds 1934 lines, covering native PCI, descriptor-ring DMA, 10/100/1000/2500M autonegotiation, lwIP software checksum, with optional PTP and PPS); #11943 RK3588 and RK3528 display and audio (36 files, +5483/-391, including HDMI controller and HDPTX PHY, VOP2 routing, SAI and codec audio clocks); #11959 NXP RT1180 industrial Ethernet linker script (20 files, +7499/-18, CM33 running from on-chip RAM, CM7 XIP from Flash). All three fall under “a whole class of hardware entering in batches,” and review cycles typically run in weeks.
  • Tooling and documentation: #11930 moves __RT_KERNEL_SOURCE__ into the Kernel group’s global CPPDEFINES, fixing 24 implicit-declaration warnings for rt_sched_* in Studio-exported projects; #11953 fixes rt_sprintf() passing (size_t)-1 to libc when libc vsnprintf is enabled, which caused not a single byte to be written (+11 lines, switched to vsprintf()); #11961 initializes static TLS for native threads (6 files, +189/-3, AArch64 restores TPIDR_EL0 on every context switch, RISC-V enables it only in S-mode with MMU).
  • Long-pending items: #11844 (ESP32-S3 BSP) has grown to +295371/-22825 after refresh and has been open for a month since 9-28, with review focused on the full SDK bundle and licensing; #10096 (on-demand compilation) has been advised to rebase first; #11860 (aarch64 interrupt acknowledge) and #11864 (IAR implicit declarations) are still supplementing test records. Also, #11947 (DHCP raw address pool exhaustion unbounded loop) is a small change (+17/-4) but comes with comparative tests over 3586 pool-size and occupancy-bitmap combinations plus ASAN results—the strongest verification in this week’s queue.

III. Ecosystem and Vendor Adaptation

Vendor BSPs and Drivers

Date: 2026-10-26 ~ 2026-10-30　Source: PR #11896

  • Infineon TriCore (AURIX): Two packages, tricore-gcc 13.4.1 and qemu-tricore 1.0.0, were added on the Env SDK side, covering TC2xx/TC3xx/TC4xx. The toolchain upstream is NoMore201/tricore-gcc-toolchain (a downstream of EEESlab 11.3.0); the Windows package adds the libwinpthread-1.dll that upstream omitted. The emulator only implements ASCLIN0 serial, STM, IR interrupt routing, SCU and clocks, the SFR bridge, and RAM/Flash mapping — no CAN, Ethernet, ADC, GPIO, or DMA. That is enough to run the kernel and a serial shell, but not enough to validate peripheral drivers.
  • Renesas: The rafw_gen vector table for RA6W1-EK gains 24 Wi-Fi-side interrupt entries (KDMA, TDES CBC, PSK SHA1, SYSPLL and FPLL lock, the full RTC interface group, MRM and D-cache MRM, CryptoCell-312, HSU, MAC timer/receive/transmit/protocol/general/beacon, radio controller), all declared as weak handlers and wired into the vector table. Two crypto entries in the ROM symbol table were also renamed with a __rom_ prefix to avoid name collisions with the RAM side.
  • Allwinner: The BSP proposals for F101 YuzukiNeko and H616 (#11877, 172 files, +35428/-6) are still queued. The F101 side adds the Sun252i device model driver set and the Sunxi DE0/TCON0 display backend (RGB, LVDS, MIPI-DSI); the H616 side is a separate driver set and adds AXP313A regulator support. The D1s QEMU boot script (#11903, 4 files, +145) is likewise under review, with reviewers suggesting it be moved into a unified target subdirectory.
  • Espressif: The ESP-IDF v6.1 adaptation wrapped up on the package side — the main-repo proposal #11926 was closed on 10-26 at 11:37, and the package-repo proposal #19 (fix(scons): prioritize RT-Thread FreeRTOS headers) was merged the same day at 09:15, resolving header priority at the SCons script layer. Board support for ESP32-S3-DevKitM-1 (#11844) is still awaiting review. Note the core distinction: ESP32-S3 is Xtensa, while C3/C6 are RISC-V.
  • STMicroelectronics: The OSPI and OctaFlash proposal (#11912, 32 files) adds OSPI bus, device, and message definitions at the component layer, integrates them with SFUD, and covers read, write, erase, and status query. It also adds a generic STM32 OctoSPI driver and stm32l4r9-st-eval board configuration, enabling SFUD access in both 1-1-1 and 8-8-8 modes. #11819 adds the full STM32 Ethernet ops callback set and SR8201F PHY support in one pass, and lowers the default ADC log level from spam to DBG_WARNING.
  • NXP: The RT1180 industrial Ethernet linker script proposal (#11959) adds Keil scatter-loading (.scf) and IAR configuration (.icf) files for CM33 and CM7 respectively, along with corresponding targets in Kconfig, rtconfig.py, and templates.

Software Packages and Middleware

Date: 2026-10-23 ~ 2026-10-26　Source: RT-Thread-packages/esp-idf PR #19

  • ai/Agent package: A single Kconfig change of +32/-4 switches the default model from DeepSeek-V4-Pro to deepseek-flash and the default service endpoint from a third-party aggregation platform to the official DeepSeek API. It adds a speech-to-text (STT) toggle and file server address, and expands the multimodal description from “image/file” to “image/file/audio”. In the same week’s community competition entries, the agent package registers MQTT subscribe, unsubscribe, and history query as tools for kernel scheduling — both point to the same usage pattern: treating the RTOS as the runtime for agents.
  • esp-idf package: The header ordering issue after the full v6.1 upgrade is fixed at the SCons layer; #include_next no longer resolves to ESP-IDF’s bundled FreeRTOS V11 headers, and defaults such as configNUMBER_OF_CORES and configMINIMAL_STACK_SIZE provided by the Wrapper no longer fall through.
  • pkgs-test: The concurrency lock for STM32 package tests was moved up into __build(), placing dependency updates and compilation in the same critical section, so that concurrent git pull on the same HAL directory is no longer aborted by Git and misreported as a compile failure.

Toolchain and Development Environment

Date: 2026-10-26 ~ 2026-10-30　Source: vscode-rt-smart PR #38

  • vscode-rt-smart 0.4.14 (merged 10-26 22:35): 49 files, +883/-4826 — nearly five thousand lines removed in one pass. Four feature areas were removed wholesale: the Kconfig view, SDK manager, toolchain settings, and symbol analysis. The ELF and DWARF parsers (~887 lines combined) and 291 lines of settings documentation went with them. The RT-Thread Setting view is narrowed to Env installation, update, and status display only, and an editor-embedded browser plus code --open-url URI handling were added. Positionally, it retreats from “IDE stand-in” to “Env entry point plus embedded browser”.
  • Eclipse project generator (#11930): LOCAL_CPPDEFINES was not included in the generated rtconfig_preinc.h, causing 24 implicit-declaration warnings in Studio builds; the fix moves the macros into the global CPPDEFINES, touching only the project generation script and not kernel source.
  • klibc (#11953): After enabling the libc-delegated vsnprintf, rt_sprintf() passed (size_t)-1 as the size to libc, overflowing buf + size on 64-bit and causing the call to fail without writing a single byte; switching to vsprintf() restores it.
  • Env documentation: The community published two long-form articles this week dissecting Env v2.0.3 — the command entry point is unified as rt-env, with new sdk/plugin/webui/system subcommands; dependencies run in a Python virtual environment; and a plugin system and browser-based WebUI were added. The compatibility red line: v2.0 fully supports 5.1.0 and above plus master, while 5.1.0 and earlier still require v1.5.x.

Verification Notes

  • There were no new releases on the main repository’s releases or tags pages this week; the official website’s news list page is client-side dynamically rendered, so scraping returns only an empty shell — news data is taken from the official API.
  • topic:rt-thread ecosystem searches this week turned up scattered hits on several personal repositories and general-purpose GUIs (zlgopen/awtk), none specifically related to RT-Thread. Two community projects — K230 flame detection and CH32H417 handwritten symbol recognition — have been included on the ecosystem side; see Chapter V.
  • The Windows builds of the two TriCore packages were only checked via PE import tables and were not run on real Windows hardware; the author recommends a trial compile before merging. All conclusions in this report follow the source wording and are not extrapolated.

IV. Official and Community Activities

Official Channels

Date: 2026-10-26 ~ 2026-10-30　Source: RT-Thread official news API

  • News API silent for a fifth consecutive month: The latest entry in the organization-category archive is still 2026-06-17, with no additions from June through October; per-issue checks return counts fluctuating around 5, which reflects pagination differences in the API. There are no new posts on the official news list page, and company-side external updates also return zero hits in Google News queries in both Chinese and English; queries for 睿擎 and 睿擎派 over the past seven days are empty.
  • Maintainer change: #11939, merged at 18:48 on 10-28, removes the components_fal entry from MAINTAINERS; the original author states they no longer have the time or energy to continue participating. FAL (Flash abstraction layer) has long been maintained by a single person, and after the entry’s removal the component has no registered maintainer; whether anyone steps in is worth tracking — when basic components like this go unclaimed, problems often only surface when vendors submit BSPs.
  • Primary information channels: Product and event information continues to be first released via the WeChat official account, the community forum, and GitHub; the absence of official proprietary channels continues this week, and the community’s external narrative is carried by competition entries and industry media.

Media and Reviews

Date: 2026-10-24 ~ 2026-10-27　Source: EET-China: in-depth comparison of three major RTOSes

  • Comparison of three major RTOSes (10-27): Compares FreeRTOS, RT-Thread, and Zephyr across six dimensions: real-time performance, memory footprint, ecosystem, community, AI support, and migration cost. RT-Thread is positioned as an Apache 2.0 lightweight all-in-one package, with a kernel of 3KB Flash plus 1.2KB RAM and built-in POSIX, GUI, file system, and AI packages; its low-power components save 15% to 20% more power than the other two in Stop mode; the selection table assigns extreme low-cost projects under 64KB RAM, along with consumer electronics and wearables, to RT-Thread. The article also acknowledges that Zephyr is stronger in multi-protocol, multi-board, and long-term maintenance scenarios, concluding with a three-way split rather than a one-sided verdict.
  • RISC-V Summit side notes (10-24): The EET-China RT-Thread column publishes a system-software perspective report on the 6th RISC-V China Summit, which comprised 1 main forum, 7 parallel sub-forums, and a Member Day technical session. Two passages relate directly to RT-Thread: during the summit, views were exchanged with multiple RISC-V IP and chip vendors on kernel adaptation, toolchain integration, and joint solution deployment; the industry judges that RISC-V already meets the conditions for scale in embedded and IoT, with the bottleneck shifting from “cores” to system software, and OS participation filling in real-time performance, functional safety, and engineering delivery.
  • Arm China WTCC 2026 seminar (10-23 event / 10-27 report): Arm China held a small embodied-intelligence solutions seminar during the Shanghai West Bund International Tech Carnival, with Rockchip, Radxa Computer, and RT-Thread attending as Open Source AIOS Alliance partners. RT-Thread senior AI engineer Zheng Wei presented three types of agent solutions — robot dogs, HyperCar, and Codex orchestration — discussing how agents move from conversation to execution and explicitly naming embodied-intelligence projects as the focus going forward; Rockchip noted that LLM inference is shifting from compute-intensive to memory-intensive, with bandwidth becoming the edge bottleneck. Arm China also released two deployment results, JishuFriends and JishuBuddy, at the same event.

Community Projects and Competitions

Date: 2026-10-24 ~ 2026-10-30　Source: Community article API

  • 2026 Embedded Competition entries enter submission peak: At least seven entries were published in concentrated fashion within this week’s window — 10-24 to 10-25: edge-side Agent multi-sensor fusion monitoring, ART-Pi2 USB enumeration diagnostic tool, OpenMV protocol pedestrian tracking; 10-28: NOVOSENSE NS800RT7P65 industrial CAN mobile robot, XuanTie D121 multi-slave monitoring, NXP MCXA346 neural-network-enhanced FOC; 10-30: Infineon Edgi Talk “Little Watcher”. What they share is that all include open-source repositories or complete reproduction records, publishing engineering details together with code rather than just submitting a report.
  • GDR debugging tool (10-25): A rare community long-form post that treats debugging scaffolding as a formal engineering project. The tool solidifies RT-Thread kernel object inspection into GDB Python commands, offering three layers of capability: aggregate commands (threads/timers/system/semaphores/objects, with the thread table carrying peak watermarks based on stack fill patterns), convenience functions, and pretty-printers; its essential difference from FinSH is that it is completely non-intrusive, reading symbols and target memory only through GDB, making it suitable for Nano scenarios without a shell and for post-mortem analysis after a HardFault. CI uses QEMU to boot real firmware for pytest assertions, with a matrix covering Cortex-A9 (3.1.0 to 3.1.5, 4.x) and RV64 (4.0.4 to 4.1.1); the author notes it has not yet been verified on real boards.
  • Three long-form posts on the kernel and toolchain: The 10-26 “rtthread startup path analysis” splits Reset_Handler to main into three stages — assembly, C initialization, and scheduler startup — and points out the common misconception that SystemInit does not configure the main frequency to 72MHz; the 10-29 long-form post on kernel object distribution uses 4.0.3’s object.c and rtdef.h to explain how “manage by type, look up by name, traverse, and count” maps onto three things: rt_object_information, intrusive linked lists, and container_of; the two posts on Env v2.0.3 and the 24 implicit declaration warnings in Studio are toolchain pitfall records.
  • Livestream: 10-26 20:00 to 21:00, community developer Cui Junshuo shares a hand rehabilitation exoskeleton project for stroke survivors, post-hand-injury surgery patients, and people with peripheral nerve injury; highlights are the recognition pipeline from EMG signals to movement intention and how the two cores on a single development board divide the work.

Industrial Control and Industrial Connectivity

Date: 2026-10-28 ~ 2026-10-29　Source: Community article: Small autonomous mobile robot

  • Industrial CAN distributed mobile robot: The main controller is a NOVOSENSE NS800RT7P65 (Cortex-M7, 600MHz) running RT-Thread 4.x, with a single chip handling the FOC 2-axis gimbal, CAN master control, and 40 MSH online diagnostic commands; the chassis uses a five-node CAN architecture (main controller, gimbal FOC, sensor acquisition, chassis drive, vision AI), with each slave running its own local closed loop. On the perception side, a rotating ultrasonic scan generates a 2D point cloud, combined with an IMU and odometry for pose estimation; monitoring runs over LAN MQTT, the entire chain does not depend on the public internet, and the code is released under GPL-3.0.
  • DAMO XuanTie D121 master with Loongson LS2K0300 slave: The master runs RT-Thread plus an LVGL touchscreen and polls two slaves over RS485 with Modbus RTU — a Spark STM32F407 collecting temperature, humidity, and six-axis data, and a Loongson LS2K0300 reporting system metrics such as CPU, memory, and uptime. Collected data is written to a TF card with local playback support; communication interruptions, recoveries, and vibration limit violations go into a persistent queue, and after uploading to the cloud via ESP8266 the data can be viewed remotely through a WeChat mini program — stored locally during outages and backfilled after recovery. Putting both ARM and LoongArch slaves on the same Modbus bus offers a direct reference for integrating heterogeneous devices.
  • AI-based BLDC motor defect monitoring: On the Renesas Titan Board (RA8P1, 1GHz Cortex-M85 plus 250MHz Cortex-M33, with an Ethos-U55 NPU and 256 GOPS on a single chip), three-phase current, bus voltage, and inverter temperature are collected; the M85 core preprocesses the data and sends it to a lightweight CNN on the NPU for real-time defect recognition. On the software side, RT-Thread runs three threads for UI, communication, and inference, and the model is converted from TFLite to C code via RUHMI for integration. The approach emphasizes no additional sensors and a low-cost predictive maintenance path.

Motor Control and Edge AI

Date: 2026-10-27 ~ 2026-10-30　Source: Community article: Lightweight neural network enhanced brushless motor controller

  • Neural network enhanced FOC on NXP MCXA346: The hardware is an FRDM-MCXA346 with a 2804 motor, an AS5600 magnetic encoder, and a SimpleFOC Mini driver. On the control side, a feedforward-plus-PI speed loop and position loop are implemented first, then a dynamic compensation network with 3 inputs, 8 hidden units, and 1 output is superimposed on the output; the weights are exported as C code and computed directly on the MCU, the firmware introduces no inference framework, and the compensation can be toggled independently for same-parameter comparisons. 90 real-board tests (10 switching patterns within ±15 RPM, three rounds each) show the steady-state tail-segment 100 ms window RMSE dropping from 2.187 to 2.094 RPM (about 4.26%), and the full-segment RMSE from 3.327 to 3.291 (about 1.07%); after adding 25 ms smoothing to the P-term target, the mean full-segment speed error across 60 tests drops by about 5.83%.
  • K230 kitchen flame detection: Built on K230 and RT-Thread Smart with open-source code, including multi-sensor fusion, adaptive linkage strategies, reproduction records, and model evaluation; the repository also includes reference materials so third parties can rerun it per the records. The project describes itself as a research prototype rather than a product. This is one of the few public projects this week that puts Smart into a real perception closed loop.
  • CH32H417 handwritten symbol recognition: A WCH dual-core RISC-V platform with a stack of RT-Thread plus LVGL plus TFLM; the pipeline includes OV5640 capture, fixed-point image preprocessing, INT8 quantized inference, and UI display, with a separate toolchain on the training side. The project is newly created and has no traction yet; its value lies in laying out a complete lightweight vision pipeline on RISC-V clearly.
  • Infineon Edgi Talk “Little Watcher”: A single Chinese sentence specifies the appearance or disappearance of a visible target; when a change is detected it alerts and saves the before/after frames. The board’s M55 side handles voice recording and upload, camera capture and upload, and alert playback, while visual judgment runs on a ready-made model on the PC side; a single session is capped at 300 seconds and 60 image uploads, the web page keeps the latest 100 events, and restarts default to paused. The highlight is treating the “AI-assisted development” process itself as a deliverable — requirement breakdown, code integration, troubleshooting, test verification, and documentation all record how AI participated.

Date: 2026-10-28 ~ 2026-10-30　Source: Hackster project: Smart Water Bottle Reminder

  • Overseas project on the RT-Spark board: An offline edge AI project using the RT-Spark board as hardware appeared on Hackster; it uses a six-axis IMU to distinguish four states — lying flat, being carried, drinking, and shaking — and if no drinking is detected for 30 seconds, it shows a red LCD prompt and sounds a buzzer. A depth-5 decision tree trained in Python is exported as pure C and runs a single inference in about 154 microseconds on an STM32F407, achieving 95% set accuracy, while a threshold-rule baseline on the same data reaches 97.5% — the author honestly documents this gap. Note the distinction: the project uses RT-Thread’s RT-Spark development board, but the firmware runs FreeRTOS, making it ecosystem reuse at the board level rather than a case of kernel adoption.
  • Business trends: No new commercial deployments, funding, or order-related reports this week. Vendor activity centered on laying groundwork in toolchains and packages — TriCore gained compilation and simulation support, RA6W1 gained a vector table, and ai/Agent switched its default backend; the pace looks more like groundwork for future solutions than one-off commits.

VI. Trend Observations

  • Smart’s positioning was clarified this week as a “test coverage layer” rather than a “default configuration”: On 10-29, Smart was first enabled and then reverted from the default configuration within a single day. This may look like flip-flopping, but in practice the maintainers were drawing a boundary: the default configuration must remain predictable so that regular regression runs without Smart stay stable; Smart runs separately through utest’s configuration overlay layer, with both paths sharing a single BSP. This achieves user-space test coverage on QEMU without disrupting the existing BSP build matrix. The follow-up observation points are #11892 and #11897: merge first what can be verified on QEMU, and merge later what depends on confirmation from physical boards. This scheduling pattern was corroborated twice this week.
  • The RT-Smart user-space/kernel-space boundary became the heaviest security theme this week, and has already become a family of issues: The terminal, block device, pipe, and mailbox cases are completely identical in form—the adaptation layer’s default parameters are already kernel addresses, and the user-space entry points lack copyin/copyout. The affected versions of all four tickets trace back to the same RT-Smart synchronization commit in 2022, indicating that this is not a newly introduced defect but a structural gap brought in wholesale during porting. The remediation path is also clear (#11941’s kernel-stack staging plus copy_from_user/copy_to_user plus lwp_in_user_space() boundary checks). The next thing to watch is whether this approach can be abstracted into a common layer, rather than being fixed separately in each subsystem.
  • The mainline cadence was dominated by “batch clearing of the proposal backlog” rather than same-day new development: Among the merges on 10-27 (four) and 10-29 (seven), most proposals had author timestamps more than a week earlier than their merge times; the 10-29 batch was created on 10-18 and queued for eleven days. This pattern affects judgments of project health: looking only at commit counts overestimates the week’s development intensity, while looking only at zero-commit days underestimates review activity. The truly stable metric is “proposal queue turnaround time”—this week it narrowed from ten days to one (#11942 followed on the same day after #11896 merged), which is a positive change.
  • Test credibility was treated as infrastructure to fix, not as tests to fix: The three things fixed this week were not “adding more cases” but making the verdicts themselves trustworthy—subsequent unit passes no longer erase earlier testcase failures (#11601), CI no longer depends on the public network or invalid IP strings (#11601), and under musl it is no longer assumed that signal 0 can be installed (#11601). In addition, #11942 changed CI’s configuration override method from “checking out the whole thing” to “appending a line to turn off the switch.” This belongs to the same line as last week’s pkgs-test concurrency-lock fix: first make the premise of “tests pass” solid, then talk about coverage.
  • Version releases shifted from “waiting” to “institutionalized,” but the release action has still not been unlocked: The v5.4.0 version number was bumped on 10-17, raised again to 0x50400 on 10-29, while releases and tags remain stuck at v5.3.0 from 09-10, already seven weeks. Two materials that appeared on 10-30 (#11956’s version management CI and release process, #11955’s version and release process documentation) show that the community itself is addressing this gap—the Z line has monthly reports plus manual approval, the Y line combines hardware verification every 3 to 6 months, and “QEMU conclusions are not expanded into physical-machine conclusions” is written into the non-goals. The next issue should verify whether the release gate has actually opened based on the release page and ChangeLog, rather than based on the version macro.
  • The shape of vendor adaptation is changing: on one side, toolchains and emulation come first; on the other, a large category of hardware enters in batches: TriCore entered the Env SDK rather than the main repository, first using open-source GCC plus QEMU to solve “can compile, can run, can debug,” with BSP and drivers left for later; meanwhile, three large proposals—RTL8125, RK3588, and RT1180—are under review at the same time, indicating that the focus of adaptation is shifting from “lighting up a single development board” to “entire classes of platforms and peripheral stacks.” The review costs of the two paths differ greatly: the former is a low-risk increment at the package-index level, while the latter often runs to thousands of lines and requires board-side confirmation—which is also why the BSP queue always has proposals on the order of 172 files and 290,000 lines pending.

Appendix: Sources and Verification

Source Inventory

Issue Date Effective Window Entries Included (by subheading)
Issue 1 2026-10-26 (Mon) 10-23 08:00 to 10-26 08:00 (72 hours) 16
Issue 2 2026-10-27 (Tue) 10-26 08:00 to 10-27 08:00 (24 hours) 13
Issue 3 2026-10-28 (Wed) 10-27 08:00 to 10-28 08:00 (24 hours) 18
Issue 4 2026-10-29 (Thu) 10-28 08:00 to 10-29 08:00 (24 hours) 16
Issue 5 2026-10-30 (Fri) 10-29 08:00 to 10-30 08:00 (24 hours) 13
  • All five daily issues are present with no missing dates; the Monday issue uses a 72-hour window spanning the weekend, with its start point carried over from the previous issue’s cutoff. The clang-format rule refinement merged at 10-23 17:09 (#11859) was already recorded in the previous weekly report’s release-day verification and is not repeated here.
  • The weekly report body merges same-topic entries from the five daily issues, so its entry count differs from the table above; this is normal consolidation. Security-class defect tickets are merged by family and not expanded ticket by ticket.

Verification Notes

  • Release-day verification: On 2026-10-31, the master commit stream, releases and tags, merged and pending proposals, and newly filed defect tickets of the main repository were each tested individually, with the verification cutoff before 10-31 17:00. Verification found two merges that fell after the Friday daily issue’s cutoff (10-30 08:00): #11915 merged at 10-30 10:54 and #11936 merged at 10-30 18:20; both have been folded into the Chapter 2 merge list and marked. Three new defect tickets were also found (#11956 version management process, #11958 pipe ioctl, #11960 mailbox object pointer) along with six new proposals (#11953, #11954, #11955, #11957, #11959, #11961), all separately marked per the verification method.
  • Version basis: For v5.4.0, only the measured RT_VER_NUM value (0x50400) exists; the official Release, tags, and ChangeLog have not been updated. The full text therefore states “has entered 5.4.0 development state, not yet released.”
  • Excluded items: Routine commits to zlgopen/awtk (general-purpose GUI, no specific tie to RT-Thread); several personal newly created repositories with single-digit stars; the Hackster RT-Spark project, treated as a board-ecosystem reference (its firmware is FreeRTOS and is not counted as kernel adoption); and commercial conclusions from overseas articles (no commercial deployments or financing reports within the window).
  • Channel limitations: Multiple Google News queries in Chinese and English and HN Algolia this week yielded no valid new RT-Thread articles; most HN candidates were literal false matches on “threads” and “Threads.” The official website’s news list page is front-end rendered, so news data is taken from the official API. The GitHub anonymous API rate limit approached its cap partway through collection in some issues; organization-level verification was completed with a single sort=pushed request, and main-repository commits are based on the first 100 entries from the commits API.

Complete Source List

Data sources: Daily RT-Thread Intelligence Briefing (five issues, 2026-10-26 to 2026-10-30) and this cycle’s release-day verification; reporting period is 2026-10-26 to 2026-10-30. Suggested next weekly report period: 2026-11-02 ~ 2026-11-06.