Окно мониторинга: 2026-10-23 08:00 ~ 2026-10-26 08:00 (пекинское время, 72 часа, включая выходные)

Источники: официальный новостной интерфейс RT-Thread, интерфейс статей форума сообщества, GitHub (коммиты / PR / Issue / Releases / tags основного репозитория, RT-Thread/sdk и toolchains-ci, репозитории организации RT-Thread-packages, pkgs-test, поиск по экосистеме topic:rt-thread), агрегация Google News (несколько групп запросов на китайском и английском, через прокси), HN Algolia, отраслевые медиа (колонка RT-Thread в EE Times China) и проверка по каналам производителей (подробнее см. перечень источников в приложении)

Индекс выпуска

    1. Динамика ядра и версий
      • В основной ветке за 72 часа всего два коммита: merged lwIP loopback netdev, уточнение правил clang-format с примером thread.c (10-25)
      • qemu-virt64 включает RT-Thread Smart: riscv64 отключает SMP, ext4 и elm монтируют блочные устройства, ptyfs и procfs монтируются (10-25)
      • Разбиение lwp_syscall.c на 11 тысяч строк: 165 точек входа системных вызовов распределены по файлам подсистем, поведение не изменилось (10-25)
    1. Безопасность и стабильность
      • Подсистема времени: четыре отчёта за одну ночь: сужение settimeofday, отрицательная временная метка gmtime_r, усечение timer_gettime, плюс исследование работ A–F (10-23／10-24)
      • Переполнение sys_poll в 32-битном RT-Smart: 8-байтовый блок кучи обходится как элемент 0x20000001, выход за границы кучи ядра при чтении/записи (10-24)
      • Адаптация ESP-IDF v6.1, вошедшая в прошлом выпуске, ломает сборку C3／C6 на master, исправление порядка include уже предложено (10-25)
      • Обзор статуса существующих предложений по дефектам: утечка NVMe, длина 9PFS, UAF tmpfs, глобальные переменные dlmodule, глубина FDT — все ожидают слияния (10-25)
    1. Официальные и общественные мероприятия
      • Опубликован репортаж с шестого саммита RISC-V China с точки зрения системного ПО: узкое место RISC-V смещается от ядра к системному ПО (10-24)
      • GDR: просмотр объектов ядра RT-Thread перенесён в GDB, замкнутый цикл QEMU охватывает 3.1.x／4.0.x／4.1.x (10-25)
      • Две длинные статьи сообщества: пользовательская установка Env tool v2.0.3 и полный разбор 24 предупреждений о неявных объявлениях в Studio (10-25)
      • Вечерний стрим 10-26: экзоскелет для реабилитации рук на базе RT-Thread и edge AI (10-25)
      • Три работы конкурса встраиваемых систем: мультисенсорное слияние для устройства-агента, диагностика USB-энумерации ART-Pi2, отслеживание подозреваемых на OpenMV (10-24／10-25)
    1. Экосистема и адаптация производителей
      • TriCore (AURIX) в Env SDK: пакеты tricore-gcc 13.4.1 и qemu-tricore вошли, охват TC2xx／TC3xx／TC4xx (10-26)
      • Пакет ai/Agent получает endpoint транскрипции речи, бэкенд по умолчанию переключён с SiliconFlow на официальный API DeepSeek (10-23)
      • Предложения BSP для Allwinner F101 и H616 на 172 файла, ESP32-S3-DevKitM-1 также получил поддержку платы (10-24／10-26)
      • Драйверы и CI: 8-линейный OSPI Flash, сериализация управляющих транзакций I2C, блокировка параллелизма тестов пакетов STM32 (10-23／10-25)
    1. Итоги и наблюдения за трендами
      • Тренды выпуска
      • Ограничения и примечания по дедупликации

1. Динамика ядра и версий

1.1 В основной ветке за 72 часа всего два коммита: merged lwIP loopback 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.

Второй — вывод loopback-устройства lwIP в фреймворк netdev, 3 файла +54/-0. Ранее loopback-интерфейс lwIP не регистрировался как netdev, что порождало две проблемы: не запускался инструментарий, работающий через 127.0.0.1; в сетевом пространстве имён без физического канала не было интерфейса по умолчанию. Изменение добавляет параметр конфигурации RT_LWIP_USING_LOOPBACK, регистрирует lo／lo0 как netdev и переводит их в состояние link up, при неуказанном интерфейсе выбирает loopback в качестве интерфейса по умолчанию, а также увеличивает почтовый ящик приёма RAW для вмещения loopback-эха. Конфигурация для проверки — qemu-virt64-riscv, в предложении указано «локально не компилировалось, сборка проверяется CI» — это совпадает с критерием допуска нескольких предложений прошлого месяца: слияние при условии успешной сборки, проверка на железе — отдельно.

По версиям по-прежнему без движения: последний релиз и тег — всё тот же v5.3.0 от 09-10, у версионного макроса v5.4.0 от 10-17 до сих пор нет ни описания релиза, ни бинарников, ни предрелизного тега.

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, включает RT_USING_SMART для двух BSP: qemu-virt64-riscv и qemu-virt64-aarch64. Ранее эти две virt-платформы номинально поддерживали Smart, но у virtio-блочного устройства не было стандартного процесса инициализации корневой файловой системы, у pty не было точки монтирования, и множество возможностей под QEMU вообще нельзя было протестировать.

Изменение можно разбить на четыре части: на стороне riscv64 отключается SMP в соответствии с однопроцессорной конфигурацией Smart; добавляется этап инициализации, монтирующий ext4 или elm на virtio-blk0; 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 и объясняет, почему loopback-интерфейс должен войти в строй раньше включения Smart — без loopback множество тестов под 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.

С инженерной точки зрения такое разбиение само по себе не создаёт новых возможностей, но определяет, можно ли будет locating последующие дефекты lwp (например, переполнение sys_poll из раздела 2.2 этого выпуска) в читаемом файле. Упомянутое в прошлом выпуске предложение по сжатию длины 9PFS относится к той же линии: код на стороне Smart переходит от «работает» к «поддерживаемо».

2. Безопасность и сопровождение стабильности

2.1 Подсистема времени: четыре сообщения за одну ночь: сужение settimeofday, отрицательные временные метки в gmtime_r, усечение timer_gettime, а также исследование рабочих пунктов от A до F (23.10/24.10)

Дата: 2026-10-23 21:04 и 2026-10-24 20:25 (время создания)　Источник: Issue #11922, Issue #11923, Issue #11924, Issue #11927

Вечером 23.10 один и тот же исследователь подряд открыл три заявки по components/libc/compilers/common/ctime.c, а на следующий день добавил ещё одну исследовательскую заявку, разом вскрыв семантические проблемы подсистемы времени. Базой для всех трёх заявок является master a59e72fb5c, все воспроизведены изолированно на уровне исходного кода, без запуска на плате.

Первая заявка — сужение типа в settimeofday(): при проверке сначала выполняется приведение (long)tv->tv_sec, и в 32-битном ARM ABI с time64/long32 (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.

Четвёртая заявка (24.10 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(). Обе поданы 24.10 и пока не объединены.

2.2 Обёртывание sys_poll в 32-битном RT-Smart: 8-байтовый блок кучи обходится как 0x20000001 элемент, выход за границы кучи ядра при чтении и записи (24.10)

Дата: 2026-10-24 03:39 (время создания)　Источник: Issue #11925

Эта заявка о дефекте подана в ночь на 24.10, проблема находится между sys_poll() в components/lwp/lwp_syscall.c и poll() на стороне libc. При вычислении размера выделения для переданного из пользовательского пространства nfds выражение nfds * sizeof(struct pollfd) на 32-битной цели вычисляется в ширине size_t и при превышении примерно 179 миллионов элементов обёртывается в небольшое значение — в результате ядро обходит 8-байтовый блок кучи как 0x20000001 элемент, и чтение с записью выходят за пределы кучи.

По оценке автора, затронут только 32-битный RT-Smart; в 64-битной сборке произведение повышается до 64 бит, и слишком большое выделение сразу завершается с -ENOMEM, без обёртывания. Точка внесения — ecf2d821 от 2022-12-03 (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, вошедшая в предыдущем выпуске, покрасила сборки C3/C6 на master в красный, предложено исправление порядка include (10-25)

Дата: 2026-10-25 17:49 (последнее обновление)　Источники: PR #11926, PR #11870 (вошёл в предыдущем выпуске)

Записанная в предыдущем выпуске адаптация ESP32-C3/C6 под ESP-IDF v6.1 вошла в 10-22, и тогда в графе проверки на плате стояло «ожидает проверки». Два дня спустя сборки C3/C6 на master стали красными: согласно описанию предложения, два запуска CI на master (40043597502, 39929831359) воспроизвели одно и то же явление, и RT-Thread BSP Static Build Check и MemBrowse Memory Report во всех PR также стали красными.

Корневая причина не в самом коде адаптации, а в порядке сборки. Пакет ESP-IDF размещает в components/rtthread/scons/ scons-shim для FreeRTOS.h, который через #include_next перенаправляет на <freertos/FreeRTOS.h>, требуя, чтобы каталог include FreeRTOS-Wrapper от RT-Thread шёл после shim и до заголовков ядра FreeRTOS V11, поставляемых ESP-IDF. Но порядок загрузки SConscript двух пакетов определяется порядком обхода каталогов и нестабилен; как только ESP-IDF загружается первым, #include_next разрешается в заголовок V11, и все значения по умолчанию, предоставляемые Wrapper (configNUMBER_OF_CORES, configMINIMAL_STACK_SIZE, configUSE_PREEMPTION и др.), оказываются пустыми, а при компиляции drv_uart.c сразу срабатывает #error.

Предложение об исправлении затрагивает только 3 файла и фиксирует порядок каталогов include FreeRTOS. Это стоит отметить не из-за самого дефекта, а из-за цепочки обратной связи: вошедшее в предыдущем выпуске изменение с условием допуска «сборка проходит» в этом выпуске было поймано CI на зависимости от порядка, и предложение об исправлении было открыто в тот же день.

2.4 Обзор состояния существующих предложений по дефектам: утечка NVMe, длина 9PFS, UAF в tmpfs, глобальная переменная 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, обновлено 25.10 в 15:49), fdt_unflatten_single() использует стек np_stack с фиксированными 64 элементами для временного хранения пути обхода, перед помещением в стек глубина не проверяется, DTB с глубиной более 64 уровней приводит к записи за границу стека; автор воспроизвёл на qemu-virt64-aarch64, исправление — перед разворачиванием отдельным ручным обходом со стеком вычислить максимальную глубину и при превышении 63 уровней сразу отклонить; второе — ошибочная очистка rx_indicate последовательного порта (#11931, обновлено 26.10 в 01:34), после echo xxx /dev/uart0 консоль перестаёт отвечать, автор исключил старое объяснение «перезапись open_flag» — теперь rt_device_open() при совпадении OFLAG_MASK вообще не вызывает open драйвера — и определил истинную причину в безусловной очистке rx_indicate в serial_fops_close(), при том что устройство всё ещё удерживается консолью (ref_count снижается только с 3 до 2).

В той же партии ещё два исправления корректности на уровне драйверов: #11891 меняет TIOCGWINSZ, чтобы больше не заимствовать finsh_getchar() для чтения ответа терминала (ранее это потребляло ввод и было доступно только в потоке tshell), и пропускает перенастройку UART, когда termios не изменился, чтобы избежать сброса FIFO; #11885 исправляет инвертированную проверку UTIME_OMIT в utimensat(), ранее запрос «не менять mtime» наоборот перезаписывал mtime и игнорировал переданную вызывающим сторону метку времени.

3. Официальные и общественные мероприятия

3.1 Опубликован обзор системного программного обеспечения шестого китайского саммита RISC-V: узкое место RISC-V смещается от ядра к системному программному обеспечению (24.10)

Дата: 2026-10-24 (публикация)　Источник: EE Times China: встраиваемый AI становится новым полем битвы RISC-V, страница колонки RT-Thread

Колонка RT-Thread в EE Times China 24.10 опубликовала заметку о саммите, заголовок которой делает акцент на «встраиваемый AI становится новым полем битвы RISC-V». Приведённый в репортаже масштаб саммита: 1 главный форум, 7 параллельных секционных заседаний плюс техническая сессия Member Day; тематика охватывает искусственный интеллект, центры обработки данных и высокопроизводительные вычисления, программную экосистему, встраиваемые системы и интернет вещей, проектирование и верификацию чипов, автомобильную электронику и робототехнику.

Непосредственно с RT-Thread связаны два фрагмента: в ходе саммита RT-Thread обменялся мнениями с рядом поставщиков RISC-V IP и чипов по адаптации ядра, сквозной интеграции инструментальных цепочек и совместному внедрению решений; отрасль считает, что RISC-V во встраиваемых системах и интернете вещей уже обладает условиями для масштабирования, а узкое место смещается от «ядра» к системному программному обеспечению, и участие операционной системы восполняет именно звено реального времени, функциональной безопасности и инженерной поставки. В репортаже не раскрываются конкретные темы докладов и анонсы продуктов, основной текст преимущественно состоит из изображений; в этом выпуске берутся только вышеуказанные проверяемые формулировки, без домысливания деталей.

Следует пояснить, что сам саммит проходил с 18 по 20 октября в Шэньчжэне, анонсы чипов со стороны индустрии уже были включены в предыдущие выпуски ежедневного отчёта RISC-V; в этом выпуске добавляется только этот материал с точки зрения системного программного обеспечения и в связи с RT-Thread, чтобы избежать дублирования между темами.

3.2 GDR: перенос просмотра объектов ядра RT-Thread в GDB, замкнутый цикл QEMU охватывает 3.1.x／4.0.x／4.1.x (25.10)

Дата: 2026-10-25 (публикация)　Источник: EE Times China: от проблем переноса LoRaWAN, репозиторий GDR

Это редкая длинная статья сообщества, в которой «отладочные строительные леса» делаются как полноценный инженерный проект. Отправной точкой стал перенос два года назад стека протоколов LoRaWAN SWL2001 от Semtech с Zephyr на ресурсно-ограниченный отечественный микроконтроллер, в основе которого был урезанный RT-Thread Nano; более сорока HAL-интерфейсов отображались по одному, и любое семантическое отклонение проявлялось только во время выполнения. Настоящая сложность была в наблюдении: как только запускался FinSH, временная последовательность radio planner нарушалась, и наблюдение изменяло наблюдаемую систему; GDB изначально даёт только указатели, и чтобы посмотреть семафор, нужно пройти по связному списку через rt_object_container, выполнить преобразование container_of и затем приведение типа; для десяти объектов это пятьдесят-шестьдесят команд.

Подход GDR — зафиксировать такой механический труд в виде Python-команд GDB, предоставляя три уровня возможностей: агрегирующие команды (rtthread threads／timers／system／semaphores／objects) выводят глобальный снимок, таблица потоков содержит два пиковых уровня заполнения стека StkUsed и MaxStkUsed на основе шаблона заполнения стека; удобные функции $gdr_thread("worker2") и $gdr_object(...) возвращают нативные gdb.Value, а дальнейшее извлечение полей по-прежнему выполняется выражениями GDB; pretty-printer сворачивает объекты ядра в однострочную сводку, например мьютекс сразу показывает владельца.

Ключевое отличие от FinSH — полная неинвазивность: вся информация извлекается только через GDB, читающий символы и целевую память, без вызова каких-либо функций прошивки, поэтому инструмент применим как в сценариях Nano, где shell вообще отсутствует, так и для посмертного анализа после HardFault, когда выполнение кода уже невозможно. В инженерном плане стоит запомнить несколько решений: отказ от автоматического определения RTOS (вместо этого явная команда gdr init rtthread 4.0.5, но различия конфигураций SMP, менеджера кучи и компонентов IPC определяются по наличию символов); все знания о раскладке сосредоточены в одном файле с пометкой COUPLED; для pytest-утверждений используется QEMU с запуском реальной прошивки, матрица 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 и полное расследование 24 предупреждений о неявных объявлениях в Studio (10-25)

Дата: 2026-10-25 18:45–18:46 (публикация)　Источники: Запись об использовании Env v2.0.3, Расследование 24 предупреждений о неявных объявлениях в Studio

Интерфейс статей сообщества вечером 10-25 подряд выдал две длинные статьи о инструментальных цепочках, обе в жанре «грабли и способы их обойти».

Первая — о пользовательской установке Env 2.0.3 в произвольное место. Начиная с v2.0 Env претерпел архитектурную переработку: единая точка входа команд — 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 полностью поддерживает master-ветку RT-Thread 5.1.0 и выше, для 5.1.0 и более ранних следует продолжать использовать v1.5.x.

Вторая — полное прослеживание предупреждений сборки RT-Thread Studio, точно соответствующее предложению #11930 основной темы выпуска. При компиляции в Studio проекта, экспортированного через scons --dist-ide, пять исходных файлов ядра выдают 24 предупреждения -Wimplicit-function-declaration (clock.c 1, ipc.c 7, thread.c 12, timer.c 1, scheduler_comm.c 3), все указывают на внутренние API планировщика семейства rt_sched_*. Путь расследования автора: сначала сравнить командные строки компиляции двух сборок и обнаружить, что scons передаёт -D__RT_KERNEL_SOURCE__, а make в Studio — нет; затем вернуться к include/rtsched.h и найти защиту макросом; наконец локализовать, что макрос внедряется через LOCAL_CPPDEFINES, тогда как генератор Eclipse-проекта перед сборкой в Studio собирает только глобальные CPPDEFINES, а LOCAL_CPPDEFINES вообще не попадает в генерируемый rtconfig_preinc.h. В статье особо предупреждают: начиная с GCC 14 эти предупреждения по умолчанию повышены до ошибок, так что для использующих новый инструментарий это провал сборки, а не шум. Соответствующее предложение #11930 меняет всего 1 строку — переносит макрос в глобальные CPPDEFINES группы Kernel, выравнивая с написанием в ветке msvc.

3.4 Прямой эфир вечером 10-26: RT-Thread и экзоскелет для реабилитации руки с граничным AI (10-25)

Дата: 2026-10-25 (публикация)　Источники: EE Times China: в следующий понедельник в 8 вечера

Анонс прямого эфира, опубликованный 10-25: 10-26 с 20:00 до 21:00 разработчик сообщества Цуй Цзюньшо делится проектом экзоскелета для реабилитации руки. Изделие ориентировано на тренировку функции руки для людей после инсульта, после операций на кисти и с повреждениями периферических нервов и объединяет восприятие, распознавание, assistance, взаимодействие и оценку в единую платформу. Два акцента описаны довольно конкретно: цепочка распознавания от сигналов ЭМГ до двигательного намерения и разделение труда двух ядер на одной отладочной плате.

Судя по теме, эта публикация относится к тому же направлению, что и работа с граничным Agent из 3.5 текущего выпуска и обновление пакета ai/Agent из 4.2: контент сообщества на стороне RT-Thread переходит от «мигания светодиодом и подключения к сети» к целостным решениям «сенсоры плюс граничный вывод», а гетерогенность двух ядер и разделение труда по реальному времени — повторяющаяся структура.

3.5 Три работы встраиваемого конкурса: мультисенсорное слияние для граничного Agent, диагностика перечисления USB на ART-Pi2, отслеживание подозреваемого на OpenMV (10-24／10-25)

Дата: 2026-10-24 12:03 — 2026-10-25 10:39 (публикация)　Источники: Мультисенсорное слияние для агента на периферийном устройстве, Диагностическое средство перечисления USB для ART-Pi2, Отслеживание подозреваемых на OpenMV

В окне мониторинга одновременно вышли три работы конкурса встраиваемых систем 2026 года, различающиеся как по аппаратной, так и по программной направленности.

Работа про агента на периферийном устройстве основана на плате Infineon Edgi-Talk (PSoC E84: Cortex-M55 плюс NPU Ethos-U55, дополнительно сопроцессор Cortex-M33, до 6 МБ SRAM на кристалле); система представляет собой распределённый сбор данных с датчиков, агрегацию через MQTT, многосенсорное слияние на периферийном устройстве, интеллектуальное распознавание и принятие решений, а также панель на LVGL. Примечательная деталь реализации: пакет agent инкапсулирует подписку, отписку и запрос истории MQTT в виде «инструментов», которые ядро агента планирует по зарегистрированным инструментам; UI — это один поток плюс набор таймеров, логический холст 800×480 рисуется на вертикальном экране 480×800 и затем поворачивается через GPU, все страницы изменяются только в потоке LVGL. Документация по фреймворку ядра агента указывает на собственный репозиторий автора.

Работа про ART-Pi2 посвящена наблюдаемости перечисления USB: с помощью хостового адаптационного слоя CherryUSB в начале и при завершении управляющих передач записываются параметры запроса, возвращаемый статус и байты дескрипторов, события попадают в ограниченную очередь, а затем аналитический поток RT-Thread вызывает общее ядро правил на C99 для формирования заключений; выводы правил сохраняют ссылки на исходные события и байты, плата публикует неизменяемые снимки доказательств, ЖК-дисплей 4,3 дюйма и веб-страница в локальной сети отображают эту сессию, позволяя проследить от вывода правила вплоть до исходных байтов. Аппаратура — ART-Pi2 (STM32H7R7) плюс 4,3-дюймовый RGB-экран Zhengdian Atom, Wi-Fi обеспечивается встроенным CYW43438.

Третья работа — отслеживание пешеходов на RA8P1 Titan Mini плюс хост-ПК: на плате прошивка OpenMV запускает YOLOv8n (вход 192, NPU Ethos-U55), через собственный протокол 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 объединены, охват 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

Самое существенное в этом выпуске находится не в основном репозитории, а в репозитории SDK для Env: два PR были последовательно объединены, добавив пути компиляции и симуляции для автомобильной архитектуры Infineon TriCore (AURIX) в систему инструментов RT-Thread.

Первый — пакет инструментов tricore-gcc, 4 файла +112, отдельные наборы Kconfig и package.json для Linux и Windows, имя пакета 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 МБ, пакет для Windows 466 МБ. В пакет для Windows добавлена пропущенная в upstream библиотека 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). В описании ясно сказано: QEMU 9.2.3, поставляемый с пакетом tricore-gcc, содержит только две машины — KIT_AURIX_TC277_TRB (TC2xx) и tricore_testboard, — и не может эмулировать TC3／TC4, поэтому отдельно вводится ветка, используемая на стороне Zephyr. Исходный код — ветка release/ifx/tricore-1.0 репозитория linumiz/qemu-tricore (тег 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, Ethernet, ADC, GPIO, DMA отсутствуют — этого достаточно для запуска ядра и последовательной оболочки, но недостаточно для проверки драйверов периферии. Для поддержки кросс-компиляции под 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 на официальный API DeepSeek (23.10)

Дата: 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 регистрирует операции MQTT как инструменты для планирования ядром, а репозиторий фреймворка Agent, на который она ссылается, и автор данного предложения относятся к одному и тому же аккаунту GitHub; одна статья описывает использование, один коммит меняет конфигурацию, и оба указывают на один и тот же способ применения — рассматривать RTOS как среду выполнения агента, позволяя модели через «инструменты» управлять возможностями устройства. После переключения бэкенда по умолчанию на официальный API порог готовности к использованию «из коробки» станет несколько ниже, но ценой является привязка сетевой зависимости к единственному поставщику, что в сценариях с ограниченными ресурсами требует самостоятельного взвешивания.

4.3 Предложения BSP для Allwinner F101 и H616 — 172 файла, ESP32-S3-DevKitM-1 также получил поддержку уровня платы (24.10／26.10)

Дата: 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. На стороне F101 добавлен набор драйверов моделей устройств Sun252i: тактирование, сброс, pinctrl, DMA, SDIO, SPI, USB, аудио, температура, RTC, PWM, ADC, NVMEM, сторожевой таймер, DVFS, G2D и JPEG; на стороне дисплея добавлен бэкенд Sunxi DE0/TCON0 с поддержкой RGB, LVDS и MIPI-DSI, а также предоставлена платная конфигурация и команды проверки для QSPI-экрана ST77916; кроме того, добавлен слой склейки Sunxi MUSB под CherryUSB и ряд исправлений общего драйверного фреймворка (домены питания, DVFS, графика, сброс UART и смещение регистров, конфигурация QSPI, рабочая очередь температуры, захват входов, интеграция USB в модель устройств). На стороне H616 — другой набор драйверов: CCU/сброс, pinctrl, температура, CPU DVFS, codec, аудио AHUB HDMI, аппаратное шифрование CE, framebuffer DE33 HDMI, 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 (к RISC-V относятся C3/C6). В предложении указаны несколько практических деталей: bootloader и таблица разделов в builtin_imgs должны быть от 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 столбец error для timer и main показывает EINTRPT, но shell и тактирование работают нормально. GPIO, I2C, SPI, ADC, PWM, Wi-Fi, BLE и встроенная 8 MB PSRAM на плате не проверялись, в README отмечены как ожидающие поддержки.

Ещё одна небольшая позиция — скрипт запуска QEMU для D1s (#11903), 4 файла +145: для BSP allwinner d1s добавлены 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 файла. Ранее драйверный слой SPI в RT-Thread не имел нативного пути OSPI, и восьмилинейный Flash приходилось обходить. Изменения добавляют на уровне components определения шины, устройства, конфигурации и сообщений OSPI, а также вспомогательные функции передачи и опции сборки, при этом сохраняя существующие пути SPI и QSPI; передача и обнаружение OSPI подключены к SFUD с поддержкой чтения, записи, стирания и операций состояния/управления, а в таблицу устройств SFUD добавлен MX25LM51245G для проверки; чтобы весь путь мог работать на аппаратном обеспечении, также добавлены общий драйвер STM32 OctoSPI и поддержка платного OSPI Flash для stm32l4r9-st-eval, что позволяет 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, но по-прежнему совместно использует каталоги драйверов HAL/CMSIS в bsp/stm32/libraries; прежний 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 сначала дополняют компиляцию и эмуляцию, в основной ветке libcpu по-прежнему нет порта tricore, а в bsp нет каталога платы AURIX. По сравнению с теми попытками около 2020 года, которые опирались на коммерческую инструментальную цепочку TASKING (все завершились Closed), этот путь более вероятно приведёт к результату, но до «запуска на плате» ещё не хватает BSP и драйверов.
  • Основная ветка крайне тихая, предложения крайне активны: за 72 часа в master всего 2 коммита, тогда как в окне мониторинга 25 PR имели обновления, 6 были влиты (основной репозиторий 2, sdk 2, packages 1, pkgs-test 1). Действия по вливанию сосредоточены вечером пятницы и вечером воскресенья, ревью не прекращалось, а разработка действительно сворачивается.
  • Исследование дефектов переходит от отдельных точек к подсистемам: подсистема времени за одну ночь получила четыре заявки (три дефекта плюс исследование с рабочими пунктами от A до F), два предложения по исправлению поданы на следующий день, образуя короткий цикл «сообщение — анализ — исправление»; переполнение sys_poll в lwp отдельно выделяет проблему целочисленной границы 32-битного RT-Smart на счётчике, управляемом из пользовательского пространства, что дополняет семейство дефектов предыдущего выпуска «метаданные устройства или серверной стороны как длина» и показывает, что ядро всё ещё платит по историческим счетам (ecf2d821 прослеживается до 2022 года).
  • Вливания с условием сборки начинают получать отпор от CI: через два дня после вливания адаптации ESP-IDF v6.1 в предыдущем выпуске сборки C3/C6 в master стали красными, что затронуло проверки статической сборки всех PR; предложение по исправлению открыто в тот же день. Сама эта цепочка здорова, но также показывает, что подход «локально не компилировали, проверяем в CI» нуждается в сопутствующих гарантиях стабильности порядка.
  • Точка приложения端侧 AI смещается от запуска моделей к подключению инструментов: пакет ai/Agent добавляет конечную точку загрузки STT, бэкенд по умолчанию переключается на официальный API DeepSeek, работы конкурса сообщества используют пакет agent для регистрации операций MQTT как инструментов, планируемых ядром, а вместе с прямым эфиром вечером 10-26 «два ядра плюс электромиографическое намерение» направление едино — RTOS рассматривается как среда выполнения агента, а реальное время и гетерогенное разделение труда — его преимущество перед универсальным 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 API исчерпан в середине сбора, дальнейшая проверка выполнена через веб-интерфейс и по имеющимся результатам поиска; полная проверка на уровне организаций не проводилась; первые 100 репозиториев по sort=pushed показывают наличие отправок в 5 репозиториях в пределах окна (sdk, toolchains-ci, rt-thread, pkgs-test, packages).
  • Официальный новостной API по-прежнему остановлен на 2026-06-17 (в этот раз возвращено 5 записей), страница списка новостей на сайте рендерится на стороне клиента, при парсинге получена только пустая оболочка; API статей сообщества в текущем выпуске пополнился 5 материалами, заголовки и время обновления всех проверены.
  • Со стороны отраслевых медиа, в колонке RT-Thread на EE Times China в пределах окна всего 4 материала: статья о саммите от 10-24, трансляция о GDR и экзоскелетах от 10-25, а также учебное пособие по CherryUSB HID от 10-23; последний материал опубликован близко к началу окна и относится к категории обучающих, в текущем выпуске отдельно не выделен. При поиске следует учитывать, что в той же колонке a422289 — старая статья о пятом саммите 2025 года, заголовок похож и легко спутать; в текущем выпуске ориентиром является a533499 от 10-24 на странице колонки.
  • В окне поиска по экосистеме topic:rt-thread отправки есть в 2 репозиториях: sejtam-dev/AKP05E-Open-Firmware (ArtInChip D13x, RISC-V, сторонняя открытая прошивка на базе RT-Thread, 0 звёзд) и zlgopen/awtk (универсальный встраиваемый GUI, коммиты не связаны специально с RT-Thread); оба использованы как экосистемный справочный материал, отдельные записи не выделялись.
  • Проверка на плате не проводилась: сборка под Windows для двух пакетов TriCore ограничена проверкой таблицы импорта PE; три заявки по подсистеме времени — воспроизведение изоляции на уровне исходного кода; аппаратная проверка предложения по OSPI выполнена на stm32l4r9-st-eval. Соответствующие выводы в отчёте изложены в соответствии с формулировками источников, без экстраполяции.

Приложение: таблица проверки источников

Источник Результат проверки
Официальный новостной API RT-Thread (категория организации) Нет новых, по-прежнему возвращается 5 записей, последняя остановлена на 06-17
Страница списка новостей на сайте Динамический рендеринг на стороне клиента, при парсинге получена только пустая оболочка загрузки
API статей сообщества (article) В окне 5 новых материалов: запись Env v2.0.3, разбор предупреждений Studio 24, три работы конкурса встраиваемых систем
Коммиты основного репозитория GitHub В окне 2 коммита: #11859 правило clang-format, #11893 lwIP loopback
PR основного репозитория GitHub 25 обновлений, слито 2
Issue основного репозитория GitHub Открыто 5 новых: #11922–#11925 и #11927, сосредоточены на подсистеме времени и lwp
releases / tags основного репозитория GitHub Новых релизов нет, последний по-прежнему v5.3.0 от 09-10
GitHub RT-Thread/sdk Слито 2: tricore-gcc и qemu-tricore, toolchains-ci выпустил v1.12, v1.13
GitHub RT-Thread/packages Слито 1: конфигурация STT для ai/Agent и бэкенд по умолчанию 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

Полный перечень источников

[47] PR #11820 (сериализация транзакций управления I2C) — https://github.com/RT-Thread/rt-thread/pull/11820