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

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

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

    1. Динамика ядра и версий
      • Проведена дополнительная сверка предложения по планировщику временных слотов, висевшего три года: критерий совпадает с #11907, но «отложенная запись READY» на одноядерной системе приводит к повторному освобождению (10-21)
      • Исправление неинициализированных глобальных переменных динамических модулей: устранены четыре дефекта, включая непродвижение указателя выделения сегмента BSS (10-21)
      • После 10-19 в основной ветке нет новых коммитов, v5.4.0 по-прежнему имеет только макрос версии без артефактов релиза (10-22)
    1. Безопасность и стабильность
      • В пути чтения NFS длина memcpy берётся из счётчика сервера: одного cat достаточно для перезаписи адреса возврата (10-22)
      • В обходе опций сервера DHCP raw-API отсутствует граница: максимум выхода за буфер 1500 байт составляет 4 байта (10-21)
      • Предложения по исправлению двух дефектов памяти предыдущего дня всё ещё на рассмотрении, в этом выпуске ничего не принято (10-21)
    1. Официальные и общественные мероприятия
      • В официальном новостном интерфейсе нет новых поступлений, на форуме сообщества в окне мониторинга нет новых длинных статей (10-22)
      • Пресс-релиз RuiQing V1.8.4 и анонс прямой трансляции опубликованы в один день, обзоров в окне не обнаружено (10-21)
    1. Экосистема и адаптация производителей
      • Принято в пакет ESP-IDF v6.1: для C3/C6 появился официальный переключатель замены FreeRTOS на RT-Thread (10-21)
      • Разблокировано而同批 предложение на стороне BSP: все тринадцать конфигураций C3 проходят, проверка на плате待验 (10-21)
      • OSPI и OctaFlash переходят на уровень компонентов: SFUD поддерживает режимы 1-1-1 и 8-8-8 (10-21)
      • Исправлен спецификатор формата в функции печати GIC для Cortex-A: передача %p не-указателя является неопределённым поведением (10-21)
      • RuiQing V1.8.4 и новая IDE: кодеры, MIPI RGB666, подтяжка GPIO, поддержка проектов GD32H7 (10-21)
      • Создан репозиторий примеров встраиваемого UI для GD32, остальные основные репозитории организации продолжают бездействовать (10-21)
    1. Отраслевые применения
      • Исправления RuiQing V1.8.4 для промышленных площадок: аффинность прерываний EtherCAT, зависание netstat при telnet, скорость UART DMA (10-21)
    1. Итоги и наблюдения за трендами
      • Тренды выпуска
      • Ограничения и пояснения по дедупликации

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

1.1 Проведена дополнительная сверка предложения по планировщику временных слотов, висевшего три года: критерий совпадает с #11907, но «отложенная запись READY» на одноядерной системе приводит к повторному освобождению (10-21)

Дата: 2026-10-21 14:16 ~ 14:41 (время комментариев)　Источник: PR #6645, PR #11907

Патч планировщика временных слотов, отправленный 2022-11-23 (#6645), долго находился в состоянии Status: waiting for test; участник сообщества Yunlk в течение окна мониторинга опубликовал три комментария подряд, вернув его в поле зрения рецензентов. Во-первых, изменения в src/scheduler.c в текущей основной ветке уже разделены на scheduler_comm.c, scheduler_up.c, scheduler_mp.c, исходный патч нельзя применить напрямую; в комментарии приведено поточечное соответствие изменений новым файлам. Во-вторых, ключевой критерий патча — только «всё ещё выполняется и вытеснен при неисчерпанном временном слоте» ставится в начало очереди, всё остальное — в конец — полностью совпадает с выводом, независимо полученным в #11907; два не знавших друг о друге пути сошлись к одному суждению, и автор назвал это само по себе косвенным подтверждением правильности направления. В-третьих, реальное расхождение — в способе реализации: данный патч удаляет перезапись записи READY при вставке в начало, заменяя её единой установкой флага при вставке в конец с очисткой YIELD, из-за чего во время вставки состояние потока остаётся RUNNING.

После переноса по этой логике на однопутевой путь порядок пробуждения семафоров на QEMU vexpress-a9 исправлен с BA на AB, порядок загрузки — с DC на CD, трёхпоточное циклическое квантование работает нормально, но utest группы планирования стабильно падает: срабатывает утверждение в rt_smem_free, обратная трассировка rt_free ← rt_defunct_execute ← idle_thread_entry, то есть idle при переработке завершённого потока дважды освобождает один и тот же TCB, оба запуска воспроизводят это в одном и том же тест-кейсе. В изоляционном эксперименте возврат прежнего очищения YIELD в rt_schedule() не устранил падение, что показывает: проблема не в месте очищения, а в «отложенной записи READY». После дополнительной проверки SMP (двухъядерная конфигурация) дискриминант также оказался действителен, повторное освобождение наблюдается только на однопутевом пути; автор также исправил своё прежнее утверждение «SMP не тестировался». Вывод и рекомендация: дискриминант стоит сохранить, но продвигать на основе #11907 «сначала сохранить stat_before, затем проверять»; если #6645 продолжать, необходимо сначала проверить повторное освобождение на однопутевом пути.

1.2 Исправление неинициализированных глобальных переменных в динамических модулях: четыре дефекта, включая отсутствие продвижения указателя при выделении сегмента BSS (10-21)

Дата: 2026-10-21 21:09 (время создания)　Источник: PR #11915, Issue #5705

Участник usualtreee открыл исправление для #5705, зарегистрированного в марте 2022 года; проблема по-прежнему воспроизводится на текущей основной ветке 1c801efa. Дефекты сосредоточены в пути загрузки перемещаемых модулей (ET_REL) dlmodule_load_relocated_object(), то есть в пути, используемом платами Cortex-M и другими с включённым RT_USING_MODULE: во-первых, после загрузки сегмента BSS (SHT_NOBITS) указатель выделения не продвигается, несколько сегментов NOBITS накладываются на одну и ту же область памяти; во-вторых, формула релокации символьных ссылок сегмента не содержит поправки на адрес компоновки сегмента; в-третьих, символы SHN_COMMON (неинициализированные глобальные переменные с tentative-определением) молча пропускаются, поскольку код читает shdr[0xfff2] для получения имени сегмента, получает мусорное значение и не находит совпадения; в-четвёртых, этот путь никогда не строит module->symtab, поэтому dlsym() для ET_REL-модулей всегда завершается неудачей.

Исправление соответствует четырём пунктам: после загрузки сегмента BSS продвигать указатель на размер сегмента; релокацию сегментов rodata/bss/data унифицировать как «адрес загрузки сегмента − адрес компоновки сегмента + значение символа»; для SHN_COMMON отдельно выделять общий блок и вынести эту ветвь до сопоставления имени сегмента, чтобы избежать чтения за границей; собирать глобальные функциональные символы из .symtab для построения module->symtab. Изменения затрагивают два файла +147/-9, проверены на qemu-vexpress-a9 тремя тестовыми модулями: до исправления dlsym для ET_REL-модулей завершался неудачей, после исправления успешен, адреса двух неинициализированных глобальных переменных (0x600d2008 и 0x600d2004) не пересекаются, запись и чтение характеристических значений проходит, результаты для двух ET_DYN-модулей не изменились. Предложение прошло CLA и находится на рассмотрении группы components.

1.3 В основной ветке после 10-19 нет новых коммитов, v5.4.0 по-прежнему имеет только макрос версии без артефактов релиза (10-22)

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

В окне мониторинга в основной ветке ноль коммитов и ноль слияний, последний — всё ещё [bsp][spacemit/k1] first version от 10-19 18:49; время пуша на странице организации также остановилось на 10-19, последняя активность остальных репозиториев — rtthread-skills и smart-build от 10-18, env и репозиторий спецификаций портирования от 10-17. Со стороны версий изменений нет: последний тег и артефакт релиза — по-прежнему v5.3.0 от 09-10, коммит «Bump version to v5.4.0» от 10-17 до сих пор имеет только макрос версии, без примечаний к релизу и бинарников. Фактическая активность кода в этом выпуске целиком приходится на рассматриваемые предложения, баг-репорты и репозитории пакетов на стороне RT-Thread-packages.

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

2.1 Путь чтения NFS использует счётчик сервера в качестве длины memcpy: одного cat достаточно для перезаписи адреса возврата (10-22)

Дата: 2026-10-22 02:13 (время создания)　Источник: Issue #11917, dfs_nfs.c

Участник XueDugu открыл новую заявку на дефект клиента NFS — относится к напрямую эксплуатируемому повреждению памяти. nfs_read() ограничивает длину запроса 1024 байтами, но при копировании использует READ3resok.count из ответа сервера, не сравнивая его ни с длиной запроса вызывающей стороны, ни с длиной данных, декодированных из того же ответа; на стороне декодирования XDR в качестве верхней границы используется xdr_bytes(..., ~0), поэтому проверка длины никогда не срабатывает. Два счётчика в протоколе независимы друг от друга, и вредоносный сервер вполне может на запрос в 80 байт ответить count = 512 и 512 байтами данных.

Последствия затрагивают встроенную команду cat: dfs_file.c принимает чтение в char buffer[81], и однократный cat одного файла позволяет выйти за хвост буфера максимум примерно на 430 байт, перезаписав адрес возврата в стеке потока finsh. Дефект внесён коммитом 0fbfdec40d от 2010-05-20, затронуты все версии начиная с v1.2.0, включая v5.3.0 и текущую основную ветку. Автор воспроизвёл его на QEMU vexpress-a9 и на реальной плате RP2350; клиент NFS сам формирует AUTH_SYS и работает по UDP без аутентификации, поэтому содержимым переполнения может управлять как смонтированный сервер, так и внедряющийся на пути. Заявка пока не принята в работу.

2.2 Отсутствие границ при обходе опций DHCP-сервера raw-API: выход за 1500-байтовый буфер максимум на 4 байта (10-21)

Дата: 2026-10-21 15:49 (время создания)　Источник: Issue #11913, dhcp_server_raw.c

Другой исследователь, K-ANOY, сообщил о чтении за границами в DHCP-сервере raw-API. Функция поиска опций гарантирует лишь то, что возвращаемый указатель лежит внутри буфера; при обходе buf[1] не проверяется предварительно на buf + 1 < end, поэтому заголовок опции, от которого в конце остался один байт, приводит к чтению на один байт за границей; вызывающая сторона затем читает фиксированную ширину (для запрошенного IP — 4 байта, для типа сообщения — 1 байт), и, разместив заголовок опции в хвосте, можно заставить opt[2]..opt[5] выйти за пределы 1500-байтового блока pbuf максимум на 4 байта. Расположенный в том же каталоге dhcp_server.c на основе сокетов как раз выполняет эти проверки — не выходит ли длина за границы, действительна ли объявленная длина, length < 4 и length < 1 — что доказывает от противного: версии raw не хватает именно этих барьеров.

Условие срабатывания — всего лишь пакет от любого хоста в той же подсети на UDP/67 с усечённой областью опций, без аутентификации; автор выполнил логическое воспроизведение под ASan и отметил, что считанные значения используются только для сравнения и ветвления и напрямую не выводятся наружу. Заявка помечена тегами bug и component: net, пока не принята в работу.

2.3 Предложения по исправлению двух дефектов памяти за предыдущий день всё ещё на рассмотрении, в этом выпуске слияний нет (10-21)

Дата: 2026-10-21 (время проверки)　Источник: PR #11911, PR #11910

Для обоих дефектов памяти, вошедших в предыдущий выпуск, в процессе находятся соответствующие исправления: предложение об ограничении длины имён каталогов в cromfs (#11911, подано тем же исследователем, соответствует заявке на дефект #11905) и исправление использования после освобождения при усечении tmpfs до нулевой длины (#11910, подано remukisama после воспроизведения на aarch64 в RT-Smart). В данном окне у обоих обновились только статус и комментарии, в основную ветку они не влиты; в этом выпуске технические подробности повторно не раскрываются.

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

3.1 Новых записей в официальном новостном API нет, в окне на форуме сообщества нет принципиально новых длинных материалов (10-22)

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

Категория организации в официальном новостном API по-прежнему возвращает 25 архивных материалов, последняя запись датируется 2026-06-17 — обновления прекратились более четырёх месяцев назад; страница списка новостей на официальном сайте рендерится динамически на фронтенде, при выборке получается лишь пустая оболочка загрузки, поэтому за основу берутся данные API. Среди первых 25 записей API статей сообщества в окне нет принципиально новых длинных материалов; последнее обновление — 10-21 10:08, работа «двухплатный скоординированный интеллектуальный терминал», технические моменты которой уже вошли в предыдущий выпуск, в этом выпуске она обрабатывается как редакционное обновление; кроме того, объявление о конкурсе универсальной адаптации Edgi-X, опубликованное 10-19, выходит за пределы окна.

3.2 Публикация о выпуске Ruiqing V1.8.4 и анонс прямой трансляции вышли в один день, обзоров в окне не появилось (10-21)

Дата: 2026-10-21 11:50 (время публикации)　Источник: EE Times China: выпуск платформы Ruiqing V1.8.4

Пресс-релиз платформы Ruiqing V1.8.4 вышел в окне мониторинга; его содержание взаимно подтверждается с анонсом прямой трансляции предыдущего дня, перечень функций см. в 4.5, исправления стабильности для промышленных площадок — в 5.1. Пресс-релиз по-прежнему завершается фразой «сегодня в 20:00 прямая трансляция с разбором на реальном оборудовании», что указывает на то, что на момент публикации трансляция ещё не состоялась; в окне мониторинга не найдено ни обзора, ни описания записи этой трансляции, поэтому в данном выпуске оценка эффекта не приводится — фиксируется только факт выпуска версии и синхронного обновления IDE до V1.5.62.

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

4.1 Со стороны пакета принят ESP-IDF v6.1: для C3/C6 появился официальный переключатель замены FreeRTOS на RT-Thread (10-21)

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

Пакет esp-idf из RT-Thread-packages прошёл полное обновление с 5.1 до 6.1.0 и был слит; изменено более двадцати тысяч файлов. Относительно официального v6.1 это слияние несёт три структурных изменения со стороны RT-Thread: добавлен components/rtthread/ (слой портирования для C3/C6, rtconfig.h, board/context, CMake и скрипты компоновки), добавлен components/riscv/vectors_rtthread.S, а в FreeRTOS, esp_system, esp_timer и других местах добавлены ветки переключателя CONFIG_IDF_RTOS_RTTHREAD; в menuconfig это соответствует пункту «Component config → FreeRTOS → Extra → Replace FreeRTOS with RT-Thread». Для RISC-V значение этого шага в том, что C3 и C6 относятся к ядрам RISC-V (в отличие от Xtensa в S2/S3): ранее RT-Thread можно было запускать только на IDF 5.x по старой схеме интеграции, а теперь есть база 6.1 плюс официально признанный канал замены ядра.

4.2 Снята блокировка однотипного предложения на стороне BSP: все тринадцать конфигураций C3 проходят, проверка на плате ожидается (10-21)

Дата: 2026-10-21 15:24 (время комментария)　Источник: PR #11870

Сопутствующее пакету предложение в основном репозитории #11870 получило в этом окне ответ мейнтейнера «esp-idf уже слит», прежняя блокирующая точка устранена. Предложение изменяет 55 файлов +4554/-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. Автор сообщает о проверке: все тринадцать конфигураций attachconfig для C3 компилируются, конфигурация C6 по умолчанию компилируется и линкуется, проверка на реальной плате ещё предстоит; портирование ESP32-S3 и изменения слоя совместимости с FreeRTOS вынесены в отдельное предложение и в этот коммит не входят.

4.3 OSPI и OctaFlash выходят на уровень компонентов: SFUD поддерживает режимы 1-1-1 и 8-8-8 (10-21)

Дата: 2026-10-21 15:22 (время создания)　Источник: PR #11912

В существующем драйверном слое есть только пути SPI и QSPI, нативного пути доступа к восьмилинейной Flash через SFUD нет. Данное предложение добавляет OSPI на уровне компонентов: новые определения шины, устройства, конфигурации и сообщений, а также помощник передачи, при этом сохраняются существующие пути SPI/QSPI; передача OSPI и обнаружение устройств подключены к SFUD с покрытием чтения, записи, стирания и запроса состояния, а в таблицу устройств добавлен MX25LM51245G для проверки. Чтобы замкнуть всю цепочку, дополнительно добавлен универсальный низкоуровневый драйвер STM32 OctoSPI drv_ospi.c (504 строки) и заголовки конфигурации серии L4, а на плате stm32l4r9-st-eval добавлены конфигурация выводов, тактирования и MSP для OCTOSPI1 и вспомогательные функции входа в режимы OPI STR/DTR, попутно исправлено перекрытие .bss, вызванное раскладкой кучи и компоновки данной платы. Изменено 32 файла +3728/-956, четыре коммита, CLA подписан, ревью назначено трём мейнтейнерам группы STM32; автор сообщает о запуске на реальной плате со сборкой GCC — оба режима, 1-1-1 и 8-8-8, распознаются SFUD.

4.4 Исправлен спецификатор формата в функции печати GIC для Cortex-A: передача non-pointer в %p является неопределённым поведением (10-21)

Дата: 2026-10-21 18:00 (время создания)　Источник: PR #11914

Для libcpu/arm/cortex-a функции печати информации GICv2 и GICv3 содержат четыре типа несоответствия спецификаторов формата и типов аргументов: физический адрес имеет тип rt_uint32_t, но печатается через %p, что является неопределённым поведением; номер версии GIC имеет тип unsigned long, максимальный номер прерывания и номер прерывания имеют тип unsigned int, но все печатаются через %d. При компиляции платы Cortex-A с -Wall -Wformat всё это выдаёт предупреждения. Предложение заменяет %p на 0x%08x, %d на %u, а для номера версии, извлекаемого из 0xfUL, добавляет явное приведение к unsigned int; в двух файлах +64/-40, изменяются только спецификаторы формата, логика выполнения не затрагивается.

4.5 RuiChing V1.8.4 и новая IDE: энкодер, MIPI RGB666, подтяжка GPIO, поддержка проектов GD32H7 (10-21)

Дата: 2026-10-21 11:50 (время публикации)　Источник: EE Times China: публикация платформы RuiChing V1.8.4, Центр документации RuiChing

Платформа RuiChing выпустила V1.8.4: на стороне SDK 6 новых функций и 4 исправления, IDE RuiChingStudio синхронно обновлена до V1.5.62. Новые возможности сосредоточены на периферии и дисплее RC3506: добавлен драйвер абсолютного поворотного энкодера QY1503, работающий через интерфейс SSI и предоставляющий пример вывода ортогональных импульсов через PWM, ориентированный на замкнутый контур управления двигателем и измерение угла; в MIPI DSI добавлена адаптация RGB666 (18-битная глубина цвета), формат отображения и число lane настраиваются через дерево устройств; открыт интерфейс mipi_display_start(), позволяющий приложению самостоятельно определять момент инициализации дисплея для упорядочивания подачи питания на дисплей и подсветку; в GPIO добавлены два входных режима PIN_MODE_INPUT_PULLUP и PIN_MODE_INPUT_PULLDOWN, избавляющие от внешних подтягивающих резисторов; добавлена отладочная команда amp_device, позволяющая просматривать принадлежность устройств в архитектуре AMP (сторона RT-Thread или сторона Linux), аффинность прерываний и тактовые частоты. На стороне IDE добавлена поддержка создания проектов, сборки и загрузки/отладки через J-Link/DAP-Link для серии GD32H7, а также оптимизирован процесс компоновки проектов GD32H7 и RK3576; полный журнал изменений и SDK синхронизированы с центром документации.

4.6 Создан репозиторий примеров встраиваемого UI для GD32, остальные основные репозитории организации продолжают молчать (10-21)

Дата: 2026-10-21 17:58 (время коммита)　Источник: GD32EmbeddedUI-demos

В организации RT-Thread-packages добавлен GD32EmbeddedUI-demos, созданный мейнтейнером Rbb666 в пределах окна мониторинга; сейчас в нём только один Initial commit, содержимое ещё не сформировано, в этом выпуске фиксируется лишь факт создания репозитория. Остальные репозитории организации без новых пушей: основной репозиторий остановился на 10-19, rtthread-skills и smart-build на 10-18, env и репозиторий спецификаций портирования на 10-17, индекс packages на 10-14; слой совместимости FreeRTOS и стандартные драйверы n32h7xx имели пуши 10-16 и 10-14 соответственно. На стороне экосистемы в окне мониторинга появились также несколько личных репозиториев (rt-thread-am, rtthread-nano-fw, извлечение фреймворка initcall, плагин автодополнения для Studio и др.), все — новые репозитории с единичными звёздами, не образующие достойной освещения динамики проекта.

5. Отраслевые применения

5.1 Исправления RuiChing V1.8.4 для промышленных площадок: аффинность прерываний EtherCAT, зависание netstat под telnet, скорость UART DMA (10-21)

Дата: 2026-10-21 11:50 (время публикации)　Источник: EE Times China: публикация платформы RuiChing V1.8.4, Журнал изменений RuiChing

Все четыре исправления этой версии указывают на промышленные площадки: задача и прерывание EtherCAT ранее не были привязаны к одному CPU, прерывание по умолчанию попадало на CPU0, при переключении нескольких задач периодически возникали конфликты доступа и зависания; после исправления оба привязаны к одному ядру; удалённое выполнение netstat через telnet блокировалось без отклика — исправлено; в примере UART DMA не удавалось установить скорость передачи, корневая причина в процедуре инициализации последовательного порта DMA — исправлено; в примере с 4,3-дюймовым экраном повышена PWM подсветки для улучшения видимости на улице. В сочетании с уже освещёнными в предыдущем выпуске виртуальным сетевым интерфейсом и монтированием NFS промышленного шлюза EG1200, а также решением управления движением колёсных двигателей ROS2 на базе RC-Pi-3506, эта продуктовая линейка RuiChing в данном выпуске демонстрирует два параллельных направления развития — «сетевые возможности на стороне шлюза» и «реальное время на стороне управления движением», причём исправления в основном приходят из обратной связи реальных проектов, а не из внутреннего тестирования.

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

6.1 Тренды текущего выпуска

  • Обсуждение планировщика перешло от «каждый предлагает своё» к «сравнению реализаций»: отложенный на три года #6645 был повторно проверен, его критерий независимо сошёлся с #11907, но два способа реализации разошлись по уровню безопасности памяти — отложенная запись READY на одноядерной системе порождает путь повторного освобождения через idle-рекультивацию, а вариант с сохранением старого состояния — нет. Такое горизонтальное сравнение между предложениями ценнее для принятия решений, чем отдельный патч, и фактически делает #11907 базовой линией продвижения.
  • Отчёты о дефектах по-прежнему инициируются внешними исследователями и содержат полную зону влияния: за день два отчёта о проблемах с памятью — вводящий коммит переполнения стека NFS прослеживается до 2010 года, затронуты все версии начиная с v1.2.0, а выход за границы при чтении в DHCP подтверждается反 примером отсутствия проверки в другой реализации в том же каталоге. Оба отчёта содержат среду воспроизведения и условия срабатывания, что значительно снижает стоимость исправления.
  • На стороне RISC-V получен канал замены ядра: после слияния полного обновления ESP-IDF 6.1 C3/C6 могут заменить FreeRTOS на RT-Thread через CONFIG_IDF_RTOS_RTTHREAD, инструментальная цепочка одновременно переходит на GCC 15.2; блокирующий пункт предложения BSP в основном репозитории в тот же день устранён, осталась только проверка на плате. Это самый весомый шаг, связанный с RISC-V, за текущий период.
  • Основная ветка неподвижна, версия застряла на сентябре: три дня подряд ноль коммитов, ноль слияний, в v5.4.0 только макрос версии. Вся активность сосредоточена в предложениях на рассмотрении, заявках о дефектах и репозиториях пакетов, что形成 тот же ритм, что и прекращение обновлений официальных каналов.
  • Платформы производителей стабильно итерируются по версиям и включают в исправления проблемы с мест эксплуатации: шесть新增 и четыре исправления в RuiQing V1.8.4 соответствуют конкретным сценариям (замкнутый контур энкодера, адаптация MIPI-экрана, отладка AMP, аффинность EtherCAT), IDE синхронно расширена до GD32H7, что показывает: конкурентоспособность промышленных платформ смещается от «работает ли вообще» к «стабильно ли на месте».

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

  • Данный выпуск охватывает 24-часовое окно (10-21 08:00 ~ 10-22 08:00), не понедельник, объединение за несколько дней не выполняется.
  • В окне основного репозитория ноль коммитов и ноль слияний; все пункты взяты из предложений на рассмотрении, заявок о дефектах, репозиториев на стороне RT-Thread-packages и релизов производителей, статус каждого указан.
  • Дедупликация с прошлым выпуском: #11907, #11909, #11911, #11910, #11903, #11870 уже были включены в прошлый выпуск; в этом выпуске описаны только новые выводы в окне (подтверждение мейнтейнером слияния esp-idf по #11870, данные повторной проверки #6645, статус процесса #11910 и #11911).
  • В результатах поиска #11815 (макропереключатель lwip) и #11814 (распределение ресурсов RA6W1) отображаются как обновлённые в окне, фактическое время слияния — 10-14 и 10-15 соответственно; в окне были только комментарии и изменения статуса, новые включения не выполнялись.
  • Интерфейс статей форума выдаёт только первые 25 записей, последняя — редактированное обновление уже включённой в прошлый выпуск работы; страница списка официальных новостей рендерится на фронтенде, новости берутся по интерфейсу.
  • Google News на английском: три дня без попаданий; на китайском за трёхдневное окно действительна только одна публикация — RuiQing V1.8.4; запрос по RuiQing по-прежнему тонет в одноимённых автомобильных материалах, отсеяно по семантике заголовка.
  • При анонимном лимите GitHub на локальной машине полная проверка推送 на уровне организации не проводилась; вместо этого использовалась перекрёстная проверка потока коммитов репозиториев и страницы организации; время推送 страницы организации RT-Thread-packages сверено по каждому репозиторию.

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

Источник Результат проверки
Официальный новостной интерфейс RT-Thread (категория организации) Нет新增, последняя из 25 архивных записей по-прежнему 06-17
Страница списка новостей официального сайта Динамический рендеринг на фронтенде, при захвате получается только пустая оболочка загрузки
Интерфейс статей форума сообщества Среди первых 25 записей нет совершенно новых длинных материалов, последняя — редактированное обновление уже включённой в прошлый выпуск работы (10-21 10:08)
commits основного репозитория GitHub В окне 0, последний по-прежнему первая версия K1 от 10-19
PR основного репозитория GitHub В окне 13 обновлений, открыто 4 новых (#11912, #11914, #11915, ещё #11916 — тестовый черновик, не учитывается), ни один не слит
Issue основного репозитория GitHub Открыто 2 новых (#11913, #11917), оба не взяты в работу
releases / tags основного репозитория GitHub Новых релизов нет, последний по-прежнему v5.3.0 от 09-10
GitHub RT-Thread-packages esp-idf #18 слит (10-21), GD32EmbeddedUI-demos создан (10-21), FreeRTOS-Wrapper остановлен 10-16
Другие репозитории организации GitHub rtthread-skills, smart-build остановлены 10-18; env, репозиторий спецификаций остановлены 10-17; packages остановлен 10-14
Поиск по экосистеме GitHub topic:rt-thread За последнюю неделю несколько личных новых репозиториев, все не проектного уровня, не включены
Агрегация Google News (китайский, через прокси) За трёхдневное окно 1 действительная публикация (RuiQing V1.8.4), остальное — одноимённый шум
Агрегация Google News (английский) За трёхдневное окно ноль попаданий
HN Algolia Кандидаты в окне — ложные совпадения threads, релевантных обсуждений нет
Отраслевые СМИ и каналы производителей Релизная публикация RuiQing V1.8.4 и журнал обновлений центра документации

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