Окно мониторинга: 2026-10-22 08:00 ~ 2026-10-23 08:00 (пекинское время, 24 часа)

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

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

    1. Динамика ядра и версий
      • Тикетная спин-блокировка RISC-V переведена на AMO: на стороне разблокировки больше нет повторов LR/SC, конфигурация SMP для K1 одновременно расширена с 4 до 8 ядер (10-22)
      • FIFO очереди сообщений обходится потоком с высоким приоритетом: по старому тикету двухлетней давности предоставлен минимальный пример, стабильно воспроизводимый в основной ветке (10-22)
      • Основная ветка завершила трёхдневный период без коммитов: в окне landed 4 коммита, принято 3 предложения, в v5.4.0 по-прежнему только макрос версии (10-23)
    1. Сопровождение безопасности и стабильности
      • NVMe теряет 4480 байт на каждое неактивное пространство имён: при каждой загрузке на соответствующем диске теряется около 1,1 MB кучи ядра (10-23)
      • 9PFS напрямую доверяет полю длины от сервера: ASAN фиксирует чтение за границами 8,3 MB приёмного буфера, предложение по исправлению открыто (10-22)
      • Статус тикета о записи за границами в NFS не изменился, в этом выпуске нет ни заявок на исправление, ни предложений (10-22)
    1. Официальные и общественные мероприятия
      • Официальный новостной API по-прежнему остановлен на июне, в окне сообщества нет новых полноформатных статей (10-23)
    1. Экосистема и адаптация производителей
      • Адаптация ESP-IDF v6.1 для ESP32-C3/C6 вошла в основную ветку: инструментальная цепочка RISC-V также переведена на GCC 15.2 (10-22)
      • GD32VW553 добавлен в пакет at_device: чип RISC-V с Wi-Fi 6 и BLE 5.2 можно выбрать напрямую через menuconfig (10-22)
      • Пример GD32EmbeddedUI через день после создания репозитория попал в индекс пакета LVGL, пакет и репозиторий замкнулись в цикл (10-22)
      • scons --attach аварийно завершается на китайской Windows: 4 метки emoji заменены на ASCII (10-22)
    1. Итоги и наблюдения за трендами
      • Тренды выпуска
      • Ограничения и пояснения по дедупликации

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

1.1 Тикетная спин-блокировка RISC-V переведена на AMO: на стороне разблокировки больше нет повторов LR/SC, конфигурация SMP для K1 одновременно расширена с 4 до 8 ядер (10-22)

Дата: 2026-10-22 17:59 (время слияния)　Источник: PR #11904, cpuport.c, K1 BSP README

Это изменение затрагивает libcpu/risc-v/common/cpuport.c и заменяет реализацию обоих путей тикетной блокировки (ticket spinlock): захвата и освобождения. Ранее обе стороны использовали цикл LR/SC для операции «чтение—изменение—запись» над одним и тем же словом: на стороне захвата старшие 16 бит (следующий номер тикета) увеличивались на единицу и склеивались с младшими 16 битами (текущий номер владельца) в одно целое слово, которое записывалось обратно; на стороне освобождения также через LR/SC номер владельца увеличивался на единицу. Комментарии после изменения указывают на две проблемы отказа: во-первых, путь получения тикета и путь освобождения, повторяющий LR/SC, могут прерывать друг друга на одном и том же резервированном наборе и при высокой конкуренции ядер попадать в livelock — именно это и есть SMP-залипание из заголовка; во-вторых, освобождение через чтение-изменение-запись целого слова перезаписывает тикеты, выданные параллельно за это время.

Исправление состоит в том, чтобы заменить получение тикета одной атомарной инструкцией amoadd.w.aqrl (AMO не может потерпеть неудачу, поэтому проблема прерывания повторов исчезает); приращение тикета выбирается как 1 << 16, и оба 16-битных счётчика по-прежнему находятся в младших 32 битах — в комментарии специально отмечено, что это верно и на RV64, поэтому используется 32-битная amoadd.w, а не amoadd.d. На стороне освобождения атомарное чтение-изменение-запись полностью удалено: только владелец записывает номер владельца, достаточно одного 16-битного полусловного сохранения для «увеличения на единицу»; это сохраняет параллельно выданные новые тикеты и избавляет от LR/SC. С обеих сторон добавлен вызов rt_hw_barrier(), гарантирующий, что обращения к памяти в критической секции выполняются после наблюдения освобождения другой стороной и что публикация завершается до продвижения номера владельца.

Тот же предложенный набор изменений меняет CONFIG_RT_CPUS_NR в bsp/spacemit/k1 и RT_CPUS_NR в rtconfig.h с 4 на 8, а также дополняет пояснения в двух README для K1 и в матрице поддержки bsp/README.md; порядок действий — «сначала исправить блокировку, затем разрешить большее число ядер». Согласно действующему README для K1, этот SoC представляет собой 64-битный RISC-V, интегрирует 8 ядер X60 с векторным расширением; BSP использует дерево устройств, загружается через U-Boot/OpenSBI и работает в режиме S, а проверочной платформой является Banana Pi BPI-F3. Весь набор изменений затрагивает 6 файлов, +33/-37; объём изменений небольшой, но он затрагивает инфраструктуру многоядерности RISC-V.

1.2 Очередь сообщений FIFO обходится потоком с высоким приоритетом: старая заявка двухлетней давности получила минимальный пример, стабильно воспроизводимый в основной ветке (10-22)

Дата: 2026-10-22 13:54 (время комментария)　Источник: Issue #4940, ipc.c

Старая заявка от августа 2021 года была повторно продвинута в окне мониторинга. Изначально заявка указывала, что очередь сообщений и почтовый ящик при RT_IPC_FLAG_FIFO не гарантируют порядок «первым пришёл — первым вышел»; ответ сопровождающего в том году признавал, что «здесь блокировка не сделана, тогда как semaphore фактически её делает», после чего исправление так и не было реализовано. Новый комментарий по этой линии добавил минимальное воспроизведение и заявил, что в основной ветке оно стабильно воспроизводится.

Конфигурация воспроизведения: rt_mq_create() создаёт очередь с msg_size=4, max_msgs=1, RT_IPC_FLAG_FIFO; поток с низким приоритетом (20) сначала выполняет блокирующий приём, очередь пуста, поэтому он оказывается первым в очереди ожидания; поток с высоким приоритетом (10) не встаёт в очередь ожидания, а сначала блокируется на семафоре; главный поток отправляет сообщение, поток с низким приоритетом снимается с очереди ожидания и попадает в очередь готовых; главный поток сразу освобождает семафор, поток с высоким приоритетом становится готовым; после задержки главного потока, уступающей CPU, первым запускается поток с высоким приоритетом и неблокирующим приёмом забирает это сообщение. Сообщение не попадает к ожидающему, стоящему первым в очереди, и семантика FIFO нарушается вытеснением по приоритету.

Характер проблемы отличается от 1.1: это не окно гонки, а выбор семантики «пробуждение означает выход из очереди» — как только разбуженный покидает очередь ожидания, он становится обычным готовым потоком, после чего любое неблокирующее получение с более высоким приоритетом может законно забрать сообщение, которое должно было достаться ему. В комментарии упоминается, что подход uClinux — разбудить, но не удалять из очереди, и удалять из очереди ожидания только после фактического получения блокировки; это можно использовать как ориентир для исправления. Заявка по-прежнему открыта; в этом выпуске соответствующего предложенного набора изменений нет.

1.3 Основная ветка завершила три дня без коммитов: в окне мониторинга было 4 коммита, слиты 3 предложенных набора изменений, v5.4.0 всё ещё содержит только макрос версии (10-23)

Дата: 2026-10-23 (время проверки)　Источник: журнал коммитов основного репозитория, releases, tags

Зафиксированная в прошлом выпуске неподвижность основной ветки в окне мониторинга была нарушена: 10-22 за один день появилось 4 коммита, все внесены слиянием трёх предложенных наборов изменений — адаптация ESP32-C3/C6 к ESP-IDF v6.1 (07:42 UTC), билетная блокировка RISC-V и восьмиядерный K1 (два коммита в 09:59 UTC), замена emoji в tools/attachconfig.py (10:00 UTC). Слияния сосредоточены в трёхчасовом интервале с 15:42 до 18:00 (пекинское время) и все обработаны одним сопровождающим, что выглядит как единое завершение ревью.

На стороне версий движений по-прежнему нет: последний релиз и тег — по-прежнему v5.3.0 от 09-10; коммит от 10-17 «Bump version to v5.4.0» до сих пор содержит только макрос версии, без описания релиза, без бинарных артефактов и без предрелизного тега. На организационном уровне в окне мониторинга изменения были только в двух репозиториях — основном и packages; время последней активности остальных репозиториев совпадает с прошлым выпуском.

2. Безопасность и стабильность

2.1 NVMe теряет 4480 байт на каждом неактивном пространстве имён: исправный диск при каждой загрузке теряет около 1,1 МБ кучи ядра (10-23)

Дата: 2026-10-23 01:15 (время создания)　Источник: Issue #11919, nvme.c

Исследователь XueDugu в конце окна мониторинга сообщил об утечке памяти ядерной кучи в драйвере NVMe. nvme_scan_device() использует управляемое устройством поле nn (Number of Namespaces) из ответа Identify Controller в качестве верхней границы цикла, последовательно проверяя номера от 1 до nn, причём на каждой итерации сначала выполняется rt_calloc для блока rt_nvme_device размером 4480 байт, и только затем отправляется команда Identify для этого номера. Оба пути обработки ошибок не освобождают этот блок памяти: при nsze == 0 (пространство имён выделено, но не активировано — допустимый по спецификации нормальный ответ) выполняется continue; при ошибке команды Identify выполняется goto _free_res, пропуская освобождение.

Влияние по измерениям автора: в конфигурации по умолчанию официального BSP qemu-virt64-aarch64 без подключённого NVMe свободная ядерная куча составляет 66 941 784 байта; с одним диском с одним пространством имён nn = 1 — 66 931 592 байта, что нормально; с оригинальным устройством nvme QEMU она снижается до 65 774 912 байт — QEMU всегда сообщает nn = 256, но предоставляет только 1 пространство имён, этот ответ легитимен, поэтому 255 неактивных номеров каждый теряют по 4536 байт (включая заголовок memheap), за одну загрузку это 1 156 872 байта, около 1,1 MB, что составляет 1,8% от 64 MB ядерной кучи. Горячее подключение и повторное сканирование приводят к линейному накоплению; если устройство сообщает большее nn (например, 0xFFFFFF), цикл будет выделять память до исчерпания кучи, и в итоге система не сможет загрузиться, последовательный порт остановится после hello rt-thread и приглашение не появится.

Автор указывает CWE-401 и CVSS 3.1 4.9 (Medium, AV:P), поясняя, что «утечка 1,1 MB за загрузку не требует атакующего», и только «исчерпание кучи, приводящее к невозможности загрузки» требует вредоносного или некорректного контроллера. Дефект внесён коммитом 945114fd5 от 2024-11-24 (поддержка NVMe, #9591), присутствует в каждой версии начиная с v5.2.0 и в текущей основной ветке. Предлагаемое исправление — перенести это выделение после подтверждения валидности пространства имён и дополнить освобождение на обоих путях ошибок, а также не доверять напрямую nn как верхней границе (можно ограничить по mnan или использовать список Active Namespace ID через CNS 02h). Тикет в настоящее время не имеет меток и не назначен.

2.2 9PFS напрямую доверяет полю длины от сервера: ASAN выявляет чтение за границами приёмного буфера размером 8,3 MB, предложение исправления открыто (10-22)

Дата: 2026-10-22 19:36 (время создания)　Источники: PR #11918, Issue #11289, dfs_9pfs.c

В dfs_9pfs_read() и dfs_9pfs_getdents() присутствует чтение за границами, не связанное с длиной ответа сервера; предложение +58/-4 затрагивает только один файл dfs_9pfs.c. Корневая причина в том, что возвращаемое p9_transaction() число байт отбрасывается (передаётся RT_NULL), после чего код напрямую использует count из пакета, stat_size и name_len каждой записи, никогда не сравнивая их с реально полученным объёмом данных; если сервер вернёт пакет с огромным count и фактически коротким содержимым, парсер будет читать за пределами приёмного буфера. В нормальной ситуации пропускаемая запись . не вызывает условие выхода fd->pos >= end, поэтому парсер может продолжать продвигаться.

Автор собрал на bsp/simulator (x86-64, ASAN, -fsanitize=address) поддельный сервер 9P в памяти: рукопожатие и Tstat/Topen/Tclunk отвечают нормально, но на Tread возвращается пакет всего из 11 байт, count ложно сообщает около 2 GB, а за приёмным буфером размещены поддельные записи . и защитная зона отравления ASAN. До исправления срабатывает AddressSanitizer: use-after-poison, позиция чтения попадает на 8 334 515-й байт внутри 8 MB области кучи, процесс ABORT; после исправления вредоносный ответ отклоняется (возвращается P9_READ_UNEXPECTED_DATA или -EIO), нормальный разбор каталога не затронут, элементы hello.txt и subdir по-прежнему выводятся.

Метод исправления в четыре шага: обе функции передают фактическое количество полученных байтов в p9_transaction() и проверяют, что оно не меньше P9_MSG_READ_DATA; count приводится к rx_size - P9_MSG_READ_DATA, и значение из сообщения больше не принимается на веру; для getdents выполняется проверка каждой записи на то, вмещают ли оставшиеся байты поле длины, не выходит ли stat_size за пределы оставшихся данных и не выходит ли name_len за пределы текущей записи; в пути read также выполняется приведение к фактически прочитанному количеству байтов (автор особо отмечает, что got <= set недостаточно, поскольку сам set может превышать ёмкость приёма). Патч проходит git apply --check на последнем master.

2.3 Дефект переполнения записи в NFS: статус заявки не изменился, в этом выпуске нет ни заявления о принятии, ни предложения об исправлении (10-22)

Дата: 2026-10-22 (время проверки)　Источник: Issue #11917

Зафиксированное в прошлом выпуске переполнение записи в клиенте NFS (nfs_read() принимает READ3resok.count от сервера в качестве длины для memcpy, и один вызов cat может выйти за пределы 81-байтового буфера стека) в течение окна мониторинга получило только обновление статуса: заявка по-прежнему открыта и не назначена, соответствующего предложения об исправлении не появилось. Тот же исследователь в течение 24 часов подряд сообщил об утечке памяти в NVMe (2.1) и переполнении чтения в 9PFS (2.2); общая черта всех трёх заявок — «управляемые устройством или сервером метаданные напрямую используются как длина или верхняя граница операции с памятью», причём в заявке по 9PFS уже приложен пригодный метод исправления по принципу приведения значений. По словам самого автора, ранее mtd-cfi (#11272) и usbhost (#11287, #11288) относятся к тому же семейству проблем и были приняты, поэтому эту линию стоит систематически проверять по семейству, а не исправлять заявку за заявкой.

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

3.1 Официальный новостной интерфейс по-прежнему стоит на июне, в окне мониторинга нет совершенно новых длинных статей сообщества (10-23)

Дата: 2026-10-23 (время проверки)　Источник: Официальный новостной интерфейс RT-Thread, Интерфейс статей общественного форума

Официальный новостной интерфейс в категории «организация» на этот раз вернул 5 записей, последняя из которых по-прежнему — «Инвестиционный форум в Абу-Даби» от 2026-06-17; обновления прекратились более четырёх месяцев назад; страница списка новостей официального сайта отрисовывается динамически на стороне клиента, при захвате получается только пустая оболочка загрузки, поэтому данные о новостях берутся из интерфейса. У нескольких первых записей интерфейса статей сообщества последнее время обновления — 10-21 10:08, статья «Двухплатный кооперативный интеллектуальный терминал на базе NS800RT7P65 и ESP32-C3»; эта работа была обработана в прошлом выпуске как редакционное обновление, в этом выпуске новых изменений нет. В течение окна мониторинга не появилось новых анонсов саммитов, хакатонов или университетских программ, а также новых релизов через каналы производителей.

4. Экосистема и адаптация производителей

4.1 Адаптация ESP-IDF v6.1 для ESP32-C3/C6 вошла в основную ветку: инструментовая цепочка RISC-V также переходит на GCC 15.2 (10-22)

Дата: 2026-10-22 15:42 (время слияния)　Источник: PR #11870, RT-Thread-packages/esp-idf PR #18

Зафиксированное в прошлом выпуске предложение для основного репозитория со статусом «блокировка снята, проверка на плате ожидается» в течение окна мониторинга было официально слито. Изменение затрагивает 55 файлов, +4564/-333, и делится на три части: для C3 и C6 отдельно адаптирована совместимость с ESP-IDF v6.1 (объявления FreeRTOS V11 в portmacro.h, sections.ld, port.c, main.c, rtconfig.py и небольшие правки драйверов ADC/SPI); инструментовая цепочка RISC-V обновлена с gcc 11.2 (esp-2022r1) до gcc 15.2 (esp-15.2.0_20251204), синхронно изменены CI workflow, docker и tools/ci; кроме того, изменения FreeRTOS-Wrapper явно вынесены в отдельное предложение.

При слиянии автор привёл только проверку на уровне компиляции: для C3 все тринадцать конфигураций attachconfig проходят на gcc 15.2 с пакетом esp-idf #18, конфигурация C6 по умолчанию собирается и компонуется, а в графе проверки на оборудовании указано «ожидает проверки, пакет прошивки для C3 подготовлен». То есть это слияние с условием допуска по успешной сборке. Для RISC-V значение состоит в том, что C3 и C6 относятся к ядрам RISC-V (в отличие от Xtensa в S2 и S3), и вместе с уже слитым переключателем CONFIG_IDF_RTOS_RTTHREAD на стороне пакета этот путь теперь готов от пакета до основного репозитория, а оставшийся риск сосредоточен в проверке на плате.

4.2 GD32VW553 вошёл в пакет at_device: чип RISC-V с Wi-Fi 6 и BLE 5.2 можно выбрать напрямую через menuconfig (10-22)

Дата: 2026-10-22 09:21 (время слияния)　Источники: RT-Thread-packages PR #2047, страница продукта GD32VW553

В пакет at_device из RT-Thread-packages добавлена поддержка GD32VW553, +68/-0; изменения заключаются в добавлении одной строки source в iot/at_device/Kconfig и нового файла gd32vw553/Kconfig (67 строк). Параметры конфигурации охватывают способ инициализации (возможна асинхронная инициализация из потока), включение AT socket, а также параметры примера: имя сетевого устройства по умолчанию wifi0, SSID и пароль, имя устройства AT-клиента по умолчанию uart4, скорость UART по умолчанию 115200 (диапазон от 9600 до 2000000), длина буфера принимаемой строки, номер вывода сброса и активный уровень (-1 означает отсутствие аппаратного сброса).

GD32VW553 — это беспроводной MCU из серии GD32V от GigaDevice; согласно странице продукта производителя, он построен на ядре RISC-V с тактовой частотой до 160 МГц, интегрирует 2.4 GHz Wi-Fi 6 (802.11b/g/n/ax, HT20) и Bluetooth LE 5.2, имеет на кристалле 4 MB Flash и 320 KB SRAM, а также аппаратное ускорение DSP и блок чисел с плавающей точкой двойной точности. Реализация его в качестве AT device означает, что со стороны RT-Thread радиомодуль не управляется напрямую — модуль рассматривается как внешнее сетевое устройство и подключается через UART посредством AT-команд; это тот же подход, что и у существующих в пакете записей ESP8266, ESP32, EC20, SIM800C и других, то есть путь недорогого подключения к сети, а не глубокая портация.

4.3 Пример GD32EmbeddedUI через день после создания репозитория попал в индекс пакета LVGL: пакет и репозиторий образуют замкнутый контур (10-22)

Дата: 2026-10-22 11:17 (время слияния)　Источники: RT-Thread-packages PR #2048, GD32EmbeddedUI-demos

Отмеченное в прошлом выпуске создание репозитория GD32EmbeddedUI-demos (10-21, тогда был только один Initial commit) через день было подключено к системе пакетов: в пакет LVGL добавлена запись gd32embeddedui_demos, +57/-0, включая одну строку source в multimedia/LVGL/Kconfig, 27 строк дочернего Kconfig и 29 строк package.json. Таким образом, этот пример из «пустого репозитория, созданного в организации» превратился в выбираемый в menuconfig компонентный пакет; исходный код по-прежнему указывает на исходный репозиторий, то есть это лёгкое подключение к индексу, а не копирование кода.

В той же партии есть ещё два обновления на стороне пакетов: [multimedia/LVGL] Add GD32EmbeddedUI demos package (11:17) и [at_device] Add GD32VW553 package configuration (09:21), автор один и тот же, оба слиты в окне мониторинга. Рассматривая 4.2 и 4.3 вместе, линия GigaDevice в течение 24 часов одновременно пополнила два базовых компонента — «сеть» и «интерфейс»; по темпу это больше похоже на подготовку основы для законченного решения, а не на точечный коммит.

4.4 scons –attach падает на китайской Windows: 4 emoji-маркера заменены на ASCII (10-22)

Дата: 2026-10-22 18:00 (время слияния)　Источники: PR #11908, attachconfig.py

В 4 строках print в tools/attachconfig.py использовались emoji-маркеры состояния, что на китайской Windows делает всю команду неработоспособной. Причина в том, что кодировка stdout в Python следует региональной кодовой странице (для системы с упрощённым китайским это 936/GBK), которая не может закодировать U+2705 и U+274C; при первой же печати возникает UnicodeEncodeError и выполнение прерывается. Поскольку все три варианта использования — --attach=?, --attach=<name>, --attach=default — проходят через одну и ту же функцию, все три пути выходят из строя одновременно. Установка PYTHONIOENCODING=utf-8 позволяет обойти проблему, но обычный пользователь об этом не знает.

Исправление заменяет 4 места на чисто ASCII-маркеры [OK] и [ERR], сохраняя исходные ANSI-цветовые коды — tools/env_utility.py и tools/ci/bsp_buildings.py уже используют цветной вывод ANSI, это существующее соглашение. Emoji в tools/ci/ не тронуты, поскольку они записываются в Markdown summary GitHub Actions и рендерятся в UTF-8, не подвергаясь влиянию кодировки консоли. Изменение затрагивает только 4 строки print, не касается логики; автор провёл сравнение до и после исправления на китайской версии Windows 11 с кодовой страницей по умолчанию 936, использованный BSP — единственный на данный момент каталог ra6m3-hmi-board с attachconfig.yml. Подобные проблемы не касаются ядра, но напрямую влияют на первый опыт китайских разработчиков.

5. Итоги и наблюдения за тенденциями

5.1 Тенденции本期

  • Путь RISC-V SMP в один день получил два базовых компонента: билетная блокировка переведена с двусторонних повторов LR/SC на «взятие билета через AMO, освобождение блокировки через полусловную запись», что устраняет поверхность livelock в корне; K1 сразу открыт до 8 ядер; ESP32-C3/C6 получили базу ESP-IDF 6.1 и инструментальную цепочку GCC 15.2. Первое исправляет корректность SMP, второе — доступность новой базы; обе работы относятся к категории «незаметные, но определяющие стабильность работы».
  • Основная ветка перешла от застоя к концентрированному завершению: после трёх дней подряд без коммитов 10-22 за три часа влиты три предложения и четыре коммита. По ритму это скорее похоже на то, что мейнтейнеры накопили партию ревью и обработали её разом, а не на рост интенсивности разработки; в v5.4.0 пока только макрос версии, что говорит о том, что процесс релиза ещё не запущен.
  • «Метаданные, контролируемые устройством или сервером, суть длина» стало целой линией дефектов: один и тот же исследователь за два дня сообщил о трёх случаях — запись за границы в NFS, утечка кучи в NVMe, чтение за границы в 9PFS; для 9PFS уже есть сходящееся исправление. Автор сам проследил эту линию до старых заявок mtd-cfi и usbhost; поштучное исправление стоит гораздо дороже, чем проверка по семейству.
  • Проблема кодировки в китайской Windows начинает рассматриваться как исправимый дефект: scons --attach из-за emoji выбрасывает исключение в GBK, и вся команда становится недоступной — частая точка преткновения китайских разработчиков. Подобные исправления малозначительны технически, но дают прямой выигрыш, и их стоит рассматривать вместе с другими пунктами адаптации инструментальной цепочки под Windows.
  • GigaDevice дополняет беспроводные и интерфейсные базовые компоненты вместе: за 24 часа GD32VW553 вошёл в at_device, пример GD32EmbeddedUI вошёл в пакет LVGL; первый — модуль Wi-Fi 6 на RISC-V, второй — пример UI; это указывает на комплектное решение, а не на точечный коммит.

5.2 Ограничения и пояснения по дедупликации

  • Данный выпуск охватывает 24-часовое окно (10-22 08:00 ~ 10-23 08:00), пятница, не понедельник, многосуточное объединение не выполняется.
  • Дедупликация с предыдущим выпуском: #11870 в прошлом выпуске уже был включён как «блокировка снята, ожидает проверки на плате», в этом выпуске описывается только результат влития и границы проверки при слиянии; #11912, #11914, #11915, #11917, #11910, #11911 были включены в прошлом выпуске, в этом упоминаются только при действительном изменении статуса (#11917 статус не изменился, приведено лишь одно пояснение).
  • Каналы отраслевых применений (промышленность, автомобильные, робототехника, embodied intelligence) в данном окне не дали новых сообщений: после выпуска V1.8.4 линейка продуктов Ruiqing не имеет последующих версий или случаев внедрения, в статьях сообщества также нет новых длинных материалов по применениям, поэтому данный раздел в этом выпуске не выделяется.
  • В окне запросы Google News на английском и китайском не вернули действительных материалов, связанных с RT-Thread; четыре результата поиска на HN оказались буквальными ложными совпадениями по слову threads (пул потоков Brotli, магазин приложений iPhone и т.п.), исключены по семантике заголовков и не рассматриваются как кандидаты.
  • В окне экосистемного поиска topic:rt-thread только репозиторий zlgopen/awtk имел пуш; этот репозиторий — универсальный встраиваемый GUI, коммиты не имеют специальной связи с RT-Thread, рассматривается как экосистемная справка, отдельной записью не выделен.
  • На организационном уровне в окне пуш был только в двух репозиториях — основном и packages, время последней активности остальных репозиториев совпадает с прошлым выпуском; при лимитах анонимного интерфейса полная проверка пушей на уровне организации не проводилась, вместо этого использована перекрёстная проверка через потоки коммитов репозиториев, страницы организации и подписки Atom.
  • Официальная страница списка новостей рендерится на клиенте, при загрузке получается только пустая оболочка, данные новостей берутся из интерфейса; интерфейс статей сообщества возвращает лишь первые несколько записей, последняя из которых — редакционное обновление уже включённой в прошлом выпуске работы.

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

Источник Результат проверки
Официальный новостной интерфейс RT-Thread (по категориям организаций) Новых записей нет, в этот раз возвращено 5 записей, самая свежая по-прежнему от 06-17
Страница списка новостей на официальном сайте Динамический рендеринг на стороне клиента, при парсинге получена только пустая оболочка загрузки
Интерфейс статей форума сообщества Среди первых нескольких записей нет совершенно новых длинных статей, самая свежая — редакционное обновление работы, уже включённой в прошлый выпуск (10-21 10:08)
Коммиты основного репозитория GitHub 4 коммита в окне мониторинга, положен конец трёхдневному отсутствию коммитов с 10-19
PR основного репозитория GitHub 13 обновлений в окне мониторинга, слито 3 (#11870, #11904, #11908), открыт 1 новый (#11918)
Issue основного репозитория GitHub Открыт 1 новый (#11919, утечка кучи NVMe), для старого #4940 получено минимальное воспроизведение
releases / tags основного репозитория GitHub Новых релизов нет, самая свежая по-прежнему v5.3.0 от 09-10
GitHub RT-Thread-packages Слито 2 (at_device GD32VW553, LVGL GD32EmbeddedUI demos)
Другие репозитории организации на GitHub В окне мониторинга push-событий нет, время последней активности совпадает с прошлым выпуском
Поиск по экосистеме GitHub topic:rt-thread Только zlgopen/awtk, универсальный GUI, не тематическая динамика, не включено
Агрегация Google News (китайский и английский, через прокси) В окне мониторинга нет действительных материалов, связанных с RT-Thread
HN Algolia Все четыре кандидата — буквальное ложное совпадение по слову threads, исключены
Отраслевые СМИ и каналы производителей В окне мониторинга нет материалов о новых релизах или о внедрениях

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