調査期間：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 コラム）とベンダーチャネル検証（詳細は付録情報源リスト参照）

本期インデックス

    1. カーネルとバージョン動向
      • メインライン72時間でコミットはわずか2件：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）
    1. セキュリティと安定性のフォロー
      • 時間サブシステムで一夜に4件連続報告：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）
    1. 公式・コミュニティイベント
      • 第6回 RISC-V 中国サミットのシステムソフトウェア視点レポート掲載：RISC-V のボトルネックはコアからシステムソフトウェアへ移行中（10-24）
      • GDR：RT-Thread カーネルオブジェクト表示を GDB に移植、QEMU クローズドループで 3.1.x／4.0.x／4.1.x をカバー（10-25）
      • コミュニティ長文2本：Env ツール v2.0.3 カスタムインストール、および Studio の24件の暗黙宣言警告の完全調査（10-25）
      • 10-26 夜ライブ配信：RT-Thread とエッジ AI の手指リハビリ外骨格（10-25）
      • 組込みコンテスト作品3本：端側 Agent マルチセンサ融合、ART-Pi2 USB 列挙診断、OpenMV 容疑者追跡（10-24／10-25）
    1. エコシステムとベンダー適応
      • TriCore（AURIX）が Env SDK に参入：tricore-gcc 13.4.1 と qemu-tricore の2パッケージをマージ、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 8線フラッシュ、I2C 制御トランザクションの直列化、STM32 パッケージテストの並行ロック（10-23／10-25）
    1. まとめとトレンド観察
      • 本期のトレンド
      • 制約と重複排除の説明

1. カーネルとバージョン動向

1.1 メインライン72時間でコミットはわずか2件：lwIP ループバック netdev マージ、clang-format ルール細分化と thread.c サンプル（10-25）

日付：2026-10-23 17:09 および 2026-10-25 19:26（マージ時刻）　出所：PR #11859、PR #11893、メインリポジトリコミット記録

週末3日間の期間に、master にマージされたのはこの2件のコミットのみであり、そのリズムは前回の「3日間ゼロコミット後の集中クローズ」という判断とつながる：マージ操作はいずれも非業務時間帯（金曜 17:09、日曜 19:26）に発生しており、レビュー自体は止まっていないが、開発側には新規コードがなかった。

1本目は clang-format ルールの収束で、2 ファイル +83/-77、変更は .clang-format と src/thread.c のみ。ブランチ名には議論の手がかり style/clang-format-discussion-11653 が付いており、2 つのコミットの日付はいずれも 10-09、主体は「アライメント、波括弧改行、スペース規則」の細分化で、2 番目のコミットでは src/thread.c を新規則に従って全体フォーマットしたものを例として示している。つまりこれは 2 週間引きずったレビューの締めくくりであり、新規作業ではない。提案にはツール上の事実も 1 つ記録されている。index++ のような書き方は clang-format 18.1.8 と 23.1.3 のいずれでもそのまま維持され、強制書き換えに対応する設定項目は存在せず、検証には --dry-run --Werror を使う。

2本目は lwIP ループバックデバイスの netdev フレームワークへの導入で、3 ファイル +54/-0。これまで lwIP のループバックポートは netdev として登録されておらず、2 種類の問題を引き起こしていた。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 の 2 つの BSP で RT_USING_SMART を有効化する。これまでこれらの virt プラットフォームは名目上 Smart をサポートしていたが、virtio ブロックデバイスには標準的なルートファイルシステム初期化フローがなく、pty にもマウントポイントがなく、多くの機能は QEMU 下ではまったくテストできなかった。

変更は 4 つに分解できる。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、時間の 6 種類のシステムコールが一箇所に積み上げられており、レビューと検索が非常に困難だった。提案ではこれを components/lwp/syscall/ ディレクトリに分割し、サブシステム別にファイルを分け、共有のシステムコールディスパッチテーブルと内部ヘッダーファイルを新設し、LWP のビルドスクリプトに新ディレクトリを登録する。

規模としてはこれが本調査期間で最大の 1 本である。22 ファイル +12223/-11638 で、ほぼすべてが移動と改名。提案は「機械的なリファクタリング、機能変更なし」と自称し、165 のシステムコール入口と挙動が完全に変わらないことを強調している。検証も同様に「ローカルでは未コンパイル、CI で検証」で、設定は CONFIG_RT_USING_SMART=y。

工学的観点から見ると、この種の分割自体は新たな能力を生まないが、今後の lwp 欠陥（例えば本号 2.2 の sys_poll ラップアラウンド）を読めるファイル内で特定できるかどうかを左右する。前号で記録した 9PFS の長さ収束の提案も同じ流れに属する。Smart 側のコードは「動く」から「保守できる」へと移行しつつある。

2. セキュリティと安定性のフォロー

2.1 時間サブシステムで一晩に4件連続報告：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 上で続けて3件を起票し、翌日の調査チケット1件を加えて、時間サブシステムの意味論的な問題を一気に並べた。3件のベースラインはいずれも master の a59e72fb5c で、すべてソースレベルの隔離再現であり、ボード上での実行は行っていない。

1件目は 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 を用いて型サイズと幅縮小の挙動を隔離検証した。

2件目は gmtime_r() の負のタイムスタンプ処理である。関数は非 NULL を返すが、フィールドが不正になる。提示された4つの比較値は非常に分かりやすい——-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 のゼロ方向切り捨ての意味論を用いており、負の入力では余りが負になり、年ループが未来方向にしか進めないことにある。

3件目は timer_gettime() の切り捨てである。残り総ナノ秒をまず rt_uint32_t に格納してから秒とナノ秒に分解するため、10 秒すなわち 100 億ナノ秒を 32 ビット変数に代入すると上位ビットが直接失われる。影響を受ける設定は RT_USING_POSIX_TIMER と RT_USING_CLOCK_TIME が同時に有効な場合である。

4件目（10-24 20:25）は欠陥ではなく調査である。tick、clock_time、RTC、libc、VDSO がそれぞれ時間ベースラインを維持している問題を、ワークアイテム付きの設計提案として整理し、10 項目の不足（設時が統一されていない、clockid の意味論が混乱している、ソフト RTC の偽同期、回り込みとオーバーフロー、hrtimer のフォールバック、PM の分岐、起動時の授時状態、NTP バージョンの境界など）を列挙し、A から F までの6つの追跡可能なワークアイテムと P0 から P2 の優先度を示し、通常の MCU は A から D まで完了すれば段階的な終点に到達すると明言している。このチケット自体は静的解析であると宣言しており、コンパイルもボード上での実行も行っていない。

対応する修正提案はすでに2件起票されている：#11928 は settimeofday() をフィールド自身の型で検証するようにし、一律に long へ変換しないようにする；#11929 は gmtime_r() の紀元前タイムスタンプに対する正規化を扱う。2件とも 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 の「デバイスまたはサーバ側で制御可能なメタデータを長さとして使う」一族とは異なる。今回はユーザ空間で制御可能なカウントが狭いビット幅でラップアラウンドするもので、古典的な整数境界問題に属するが、着地点がシステムコール入口とカーネルヒープの間にあるため、結果は直接カーネルヒープの境界外読み書きとなる。この PR には現在対応する修正提案はない。

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 の 2 回の 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 カーネルヘッダの前に並ぶことが要求される。しかし 2 つのパッケージの 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 更新）。

期間内に追加された2件は新しいものだ。1つはFDTアンフラット化の深さ制限（#11901、10-25 15:49更新）で、fdt_unflatten_single() は固定64項目のスタック np_stack を用いて走査パスを一時保持するが、プッシュ前に深さを検査しないため、深さが64層を超えるDTBではスタックの範囲外書き込みが発生する。作者はqemu-virt64-aarch64上で再現し、修正方法はアンフラット化の前に独立した手動スタック走査で最大深さを算出し、63層を超える場合は直接拒否するというものだ。もう1つはシリアルの 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に下がるだけだ）。

同じバッチにはドライバ層の正確性修正が2件ある。#11891は TIOCGWINSZ が finsh_getchar() を借りて端末応答を読まないように変更し（従来は入力を消費し、しかもtshellスレッドでのみ利用可能だった）、termiosが変化していない場合はUARTの再設定をスキップしてFIFOのリセットを回避する。#11885は utimensat() の UTIME_OMIT に対する判定の反転を修正した。これまでは「mtimeを変更しない」という要求がかえってmtimeを上書きし、呼び出し側が渡したタイムスタンプを無視していた。

3. 公式・コミュニティ活動

3.1 第6回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技術特別セッションを加えたもので、議題は人工知能、データセンターとハイパフォーマンスコンピューティング、ソフトウェアエコシステム、組込みとIoT、チップ設計と検証、車載エレクトロニクスとロボティクスをカバーしている。

RT-Threadに直接関連するのは2つの記述だ。サミット期間中、RT-Threadは複数のRISC-V IPおよびチップメーカーとカーネル適応、ツールチェーンの疎通、共同ソリューションの実装について意見を交換した。業界ではRISC-Vが組込みとIoTでスケール化の条件をすでに備えており、ボトルネックは「コア」からシステムソフトウェアへ移行しつつあり、オペレーティングシステムの参画が補うのはリアルタイム性、機能安全、エンジニアリング納品という環であるとの判断が示されている。報道は具体的な講演タイトルや製品発表を展開しておらず、本文は画像が中心のため、本号では上記の確認可能な記述のみを取り上げ、細部を代わりに起草することはしない。

なお、サミット本体は10-18から10-20に深センで開催され、産業側のチップ発表は既に前号までのRISC-Vデイリーレポートで収録済みである。本号ではシステムソフトウェア視点とRT-Threadに関連するこの1本のみを補い、テーマをまたいだ重複を避ける。

3.2 GDR：RT-Threadカーネルオブジェクトの閲覧をGDBに移植、QEMUの閉ループで3.1.x／4.0.x／4.1.xをカバー（10-25）

日付：2026-10-25（公開）　情報源：電子工程専輯：LoRaWAN移植の落とし穴から出発、GDRリポジトリ

これは「デバッグ用スキャフォールド」を正式なエンジニアリングとして取り組む稀なコミュニティ長文だ。出発点は2年前、SemtechのLoRaWANプロトコルスタックSWL2001をZephyrからリソース制約のある国産マイコンへ移植したこと。下層はトリミングされたRT-Thread Nanoで、40以上のHALインターフェースを1つずつマッピングし、あらゆる意味のずれは実行期にしか露見しない。真の難所は観測にあった。FinSHが動くとradio plannerのタイミングが乱され、観測行為が被観測システムを変えてしまう。GDBはネイティブではポインタしか与えず、1つのセマフォを見るには rt_object_container をたどってリンクリストを辿り、container_of 換算をしてからcastする必要があり、10個のオブジェクトで50〜60条のコマンドになる。

GDRのアプローチは、こうした機械的作業をGDBのPythonコマンドとして固定化し、3層の能力を提供する。集約コマンド（rtthread threads／timers／system／semaphores／objects）はグローバルスナップショットを出力し、スレッドテーブルにはスタック充填パターンに基づくピーク水位である StkUsed と MaxStkUsed の2つが付く。便利関数 $gdr_thread("worker2") と $gdr_object(...) はネイティブな gdb.Value を返し、その後のフィールド掘り下げは引き続きGDB式で行える。pretty-printerはカーネルオブジェクトを1行の要約に折り畳み、例えばミューテックスは保持者を直接表示する。

FinSH との本質的な違いは完全に非侵襲である点にある。すべての情報は GDB がシンボルとターゲットメモリを読むことでのみ取得し、ファームウェア内のいかなる関数も呼び出さない。そのため、shell がまったく存在しない Nano のシナリオにも、HardFault の後でもはやコードを実行できない死後分析にも適用できる。エンジニアリング上、いくつかの決定は記録に値する。もはや RTOS を自動検出せず（明示的な gdr init rtthread 4.0.5 に変更したが、SMP、ヒープマネージャ、IPC コンポーネントといった設定差異はシンボルの存在性で検出する）、すべてのレイアウト知識を 1 つのファイルに集中させて 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 コミュニティの長文 2 本：Env ツール v2.0.3 のカスタムインストールと、Studio の 24 個の暗黙宣言警告の完全な調査（10-25）

日付：2026-10-25 18:45 から 18:46（公開）　情報源：Env ツール v2.0.3 使用記録、Studio 24 個の暗黙宣言警告の調査

コミュニティ記事のインターフェースは 10-25 の夕方にツールチェーンの長文を 2 本連続で公開した。いずれも「ハマりどころと修正方法」という類型に属する。

1 本目は 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）を示している。記事中では互換性のレッドラインも 1 つ示されている。Env v2.0 は RT-Thread 5.1.0 以上の master ブランチを完全にサポートし、5.1.0 以前は引き続き v1.5.x を使う。

2 本目は RT-Thread Studio のビルド警告の完全な溯源で、ちょうど本期のメインライン提案 #11930 に対応する。scons --dist-ide でエクスポートしたプロジェクトを Studio でコンパイルすると、5 つのカーネルソースファイルで 24 個の -Wimplicit-function-declaration（clock.c 1、ipc.c 7、thread.c 12、timer.c 1、scheduler_comm.c 3）が報告され、すべて rt_sched_* 系列の内部スケジューリング API を指している。著者の調査経路は次のとおり。まず 2 種類のビルドのコンパイルコマンドラインを比較し、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、コミュニティ開発者の崔竣碩氏が手指リハビリ外骨格プロジェクトを共有する。作品は脳卒中、手外傷術後、末梢神経損傷の人々の手機能トレーニングに向け、知覚、認識、補助、インタラクション、評価を 1 つのプラットフォームにしている。2 つの見どころが比較的具体的に書かれている。筋電信号から運動意図への認識経路と、1 枚の開発ボード上でデュアルコアがどのように分担協力するかである。

テーマから見ると、この項目は本期 3.5 の端側 Agent 作品、4.2 の ai/Agent パッケージ更新と同じ方向に属する。RT-Thread 側のコミュニティコンテンツは「点灯とネット接続」から「センシングに端側推論を加えた」丸ごとのソリューションへと移行しつつあり、デュアルコア異種構成とリアルタイム性の分担は繰り返し現れる構造である。

3.5 組込みコンテストの 3 作品：端側 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 組み込みコンテストの作品が調査期間内に 3 件集中して公開され、ハードウェアとソフトウェアの方向性はそれぞれ異なっている。

端側 Agent の記事は Infineon Edgi-Talk ボード（PSoC E84：Cortex-M55 に Ethos-U55 NPU、さらに Cortex-M33 コプロセッサ、オンチップ最大 6 MB SRAM）をベースにしており、システムは分散センシング収集、MQTT 集約、端側マルチソースフュージョン、インテリジェント認識意思決定に LVGL ダッシュボードを加えた構成である。注目すべき実装詳細は次のとおり：agent パッケージは MQTT のサブスクライブ、アンサブスクライブ、履歴照会を「ツール」としてカプセル化し、agent カーネルが登録されたツールに従ってスケジューリングする。UI は 1 スレッドと 1 組のタイマーで、800×480 の論理キャンバスを 480×800 の縦画面に描画してから GPU で回転させ、すべてのページは LVGL スレッド内でのみ変更される。Agent カーネルのフレームワークドキュメントは作者自身のリポジトリを指している。

ART-Pi2 の記事は USB 列挙の可観測性を扱っている：CherryUSB のホストアダプテーション層を使い、制御転送の開始と完了時にリクエストパラメータ、戻りステータス、ディスクリプタバイトを記録し、イベントは有界キューに入り、RT-Thread 分析スレッドが共有の C99 ルールコアを呼び出して判定を生成する。ルール結論はソースイベントとバイト参照を保持し、ボード側は不変の証拠スナップショットを公開し、4.3 インチ LCD と LAN ウェブページがこのセッションを中心に表示し、1 つのルール結論から元のバイトまで遡って確認できる。ハードウェアは ART-Pi2（STM32H7R7）に正点原子 4.3 インチ RGB スクリーン、Wi-Fi はオンボードの CYW43438 が提供する。

3 件目は RA8P1 Titan Mini と PC 上位機による歩行者追跡である：ボード側は OpenMV ファームウェアで YOLOv8n（192 入力、Ethos-U55 NPU）を実行し、USB CDC カスタムプロトコル経由で検出結果と映像ストリームを Python 上位機に送信する。オペレータが画面をクリックすると即座に対象をロックし、赤枠が運動予測を伴って追従し録画に焼き込まれる。実測フレームレートは細かく示されている：QVGA 検出なし約 25 fps、検出あり 16 から 19 fps、VGA 検出あり約 8 fps。

4. エコシステムとベンダー適応

4.1 TriCore（AURIX）が Env SDK に参入：tricore-gcc 13.4.1 と qemu-tricore の 2 パッケージがマージされ、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 リポジトリにある：2 つの PR が相次いでマージされ、Infineon TriCore（AURIX）という車載グレードアーキテクチャのコンパイルとシミュレーション経路を RT-Thread のツールチェーン体系に補完した。

1 件目は 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 の 3 世代チップに該当する。リリース物は toolchains-ci の v1.12 に配置：Linux パッケージ 251 MB、Windows パッケージ 466 MB。Windows パッケージには上流が漏らしていた libwinpthread-1.dll を補完した（同時に bin/ と libexec/gcc/tricore-elf/13.4.1/ に配置）。これがないと MSYS2 未インストールのマシンでコンパイラが起動しない。

2件目は 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 の2台のマシンしかなく、TC3／TC4 をエミュレーションできないため、Zephyr 側で使われている一支を別途導入した。ソースは linumiz/qemu-tricore の release/ifx/tricore-1.0 ブランチ（tag v1.0.0、QEMU 10.2.94）で、対応する3台のマシンは 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 は一切ない——カーネルとシリアルシェルを動かすには十分だが、ペリフェラルドライバの検証には不十分である。Windows クロスコンパイルをサポートするため、TriCore 側ではポータビリティ問題を2箇所修正している（ENOTBLK／O_* の条件コンパイルと hwaddr のログフォーマット）。

2点は明確に書いておく必要がある。第一に、これはツールチェーンとエミュレーションが先行するだけである：メインラインの 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 であり、メインラインにはマージされていない。第二に、2件の提案の Windows パッケージはいずれも PE インポートテーブルのチェックのみで、Windows 実機での実行は行われておらず、作者自身が PR でマージ前にコンパイルを一度追加実行することを推奨している。

この2点を合わせて見ると、意義は路線の変化にある：かつての 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、1ファイルのみの変更だが、2箇所のデフォルト値の変化は記録に値する。モデル名のデフォルト値は deepseek-ai/DeepSeek-V4-Pro から deepseek-flash に変更；インターフェースアドレスのデフォルト値はサードパーティアグリゲーションプラットフォームの api.siliconflow.cn から DeepSeek 公式エンドポイント api.deepseek.com に変更（両者ともパスは chat/completions）——つまりデフォルトパスがアグリゲーションプラットフォームからベンダー純正エンドポイントに変わった。

新規追加されたのは音声転写設定ブロック：1つのスイッチオプション（PKG_AGENT_STT_ENABLE／DISABLE、デフォルトは有効）に加え、STT File Server 文字列があり、セマンティクスは HTTP ファイルアップロードエンドポイントで、例示はローカルアドレスに /stt パスを付けたもの。マルチモーダルスイッチの説明文も「画像／ファイル」から「画像／ファイル／オーディオ」に拡張され、STT 設定に対応している。

この項目は本期 3.5 のエンドサイド Agent コンテスト作品と対読できる：作品では agent パッケージが MQTT 操作をツールとして登録してカーネルスケジューリングに供し、その参照する Agent フレームワークリポジトリと今回の提案の作者は同じ GitHub アカウントに属する；一篇は使い方を説き、一笔は設定を変え、同じ使い方を指し示している——RTOS を agent のランタイムとして扱い、モデルが「ツール」を通じてデバイス機能を操作する。デフォルトバックエンドが公式 API に切り替わった後、すぐに使えるハードルはいくらか下がるが、代償としてネットワーク依存が単一ベンダーに紐付けられる点は、リソース制約のあるシナリオでは自行でトレードオフする必要がある。

4.3 Allwinner 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 側は提案が中心で、最大規模は Allwinner の系列（#11877）で、172 ファイル +35428/-6、一度に F101 YuzukiNeko と H616 の 2 つを持ち込んだ。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 レギュレータのサポートを新規追加した。

もう 1 件は 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。ボード共有の変更は 3 箇所（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 8 線 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 経路がなく、8 線 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）の 2 モードでアクセスできるようにした。

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. 総括とトレンド観察

5.1 今期のトレンド

  • 車載アーキテクチャは「ツールチェーン先行」：TriCore／AURIX は今回メインリポジトリではなく Env SDK に入った——オープンソースの GCC 13.4.1 と qemu-tricore の 2 パッケージでまずコンパイルとシミュレーションを補完し、メインラインの libcpu には依然として tricore ポートがなく、bsp 下にも AURIX ボード級ディレクトリがない。2020 年前後に TASKING 商用ツールチェーンに依存した一連の試み（いずれも Closed で終わった）と比較すると、今回の経路は実現可能性が高いが、「ボードに載る」までにはまだ BSP とドライバが必要だ。
  • メインラインは極めて静か、提案面は極めて活発：72 時間で master はわずか 2 コミットだが、期間内に 25 件の PR が更新され、6 件がマージされた（メインリポジトリ 2、sdk 2、packages 1、pkgs-test 1）。マージ動作は金曜夕方と日曜夜に集中し、レビューは止まっておらず、開発側は確かに収束しつつある。
  • 欠陥研究は単点からサブシステムへ：時間サブシステムは一夜で 4 件（3 欠陥＋A から F の作業項目を含む調査 1 件）、2 件の修正提案が翌日提出され、「報告—分析—修正」の短い閉ループを形成した；lwp の sys_poll ラップアラウンドは、32 ビット RT-Smart のユーザー空間で制御可能なカウンタにおける整数境界問題を個別に挙げ、前回の「デバイスまたはサービス側のメタデータを長さとして扱う」欠陥群と相補的であり、カーネルが依然として歴史的負債を支払っていることを示す（ecf2d821 は 2022 年まで遡れる）。
  • ビルドをリリース条件とするマージが CI に逆襲され始めた：前回 ESP-IDF v6.1 適応のマージから 2 日後、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インターフェースのレート制限が収集の途中で尽きたため、以降はWeb側での照合と既存の検索結果を基準とし、組織レベルの全量プッシュ確認は行っていない；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チュートリアル；最後の1件は公開時刻が窓の起点に近く、チュートリアル類に属するため、本期は単独で取り上げていない。検索時には、同じコラム内のa422289が2025年の第5回サミットの旧記事であり、タイトルが類似して混同しやすいことに注意が必要で、本期はコラムページの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の2つのパッケージのWindowsビルドはPEインポートテーブルのチェックのみ；時間サブシステムの3件はソースレベルの分離再現；OSPI提案のハードウェア検証はstm32l4r9-st-evalに基づく。報告中の関連する結論はすべて情報源の原文の表現に従い、外挿はしない。

付録：情報源照合表

情報源 照合結果
RT-Thread公式ニュースインターフェース（組織分類） 新規なし、依然として5件を返却、最新は06-17で停止
公式サイトニュース一覧ページ フロントエンド動的レンダリングのため、取得すると読み込み中の空シェルのみ
コミュニティ記事インターフェース（article） 窓内に新規5件：Env v2.0.3の記録、Studio 24警告の調査、組み込みコンテスト作品3件
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 4件の候補はいずれもthreadsの文字通りの誤マッチのため除外済み
業界メディア（EET-Chinaコラム） 窓内に4件、3件収録、10-23チュートリアル記事は単独で取り上げず
メインラインアーキテクチャディレクトリ照合 libcpuには現在19のアーキテクチャが存在し、tricoreはなし；旧提案#4311の状態はClosed

完全な情報源リスト

<github.com/RT-Thread/rt-thread/pull/11885>

[47] PR #11820（I2C 制御トランザクションの直列化） — https://github.com/RT-Thread/rt-thread/pull/11820