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

Источники: официальный новостной интерфейс RT-Thread и список новостей на официальном сайте, коммиты / PR / Issue / releases / tags основного репозитория на GitHub, проверка всех 35 репозиториев организации RT-Thread по времени пуша, поиск по репозиториям GitHub (ключевое слово rt-thread и topic:rt-thread), GitHub-организации производителей чипов (HPMicro — 64 репозитория), семь групп запросов Google News на китайском и английском (через прокси), HN Algolia, официальная колонка RT-Thread в EE Times China, сайт Шанхайской комиссии по экономике и информатизации, форум club.rt-thread.org (в этом выпуске по-прежнему ограничен WAF сайта)

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

    1. Динамика ядра и версий
      • Два исправления USB device с контролируемой хостом длиной слиты одновременно: индекс строкового дескриптора и совместимый ID MS OS (11-02)
      • 32-байтовый буфер имени при инициализации хоста SDHCI: при RT_NAME_MAX = 64 происходит переполнение стека (11-02)
      • Байтовый цикл klibc распознаётся GCC как memset, компоновка без libc завершается ошибкой (11-02)
      • tiny vsnprintf обрабатывает long long как long, INT64_MAX печатается как -1 (11-02)
      • Контроллер сброса SCMI берёт неверный контейнер, порядок регистрации драйвера перенесён на инициализацию подсистемы (11-02)
      • Правила версий X/Y/Z выходят на ревью документации, одновременно вывешен список тестов QEMU для версии Z (11-02 ~ 11-03)
    1. Сопровождение безопасности и очередь на слияние
      • Отрицательное смещение в графическом устройстве: pread и pwrite обходят проверку позиции и достигают произвольного чтения-записи в ядре (11-02)
      • Патч для pipe готов в тот же день: исправление на стороне драйвера с самопроверкой по команде (11-02)
      • Сопровождающий лично переделал два старых предложения: getaddrinfo и таблица разделов GPT (11-03)
      • В очереди остаются пять: имя каталога cromfs, счётчик poll, длина 9pfs, исчерпание пула DHCP, signalfd (10-21 ~ 11-03)
    1. Официальные и общественные мероприятия
      • Завершился Шанхайский конкурс инноваций в области open source ПО, RuiSaide — один из 12 постановщиков отраслевых задач (10-29 ~ 10-30, официальная публикация 11-02)
      • Запущен опрос пользователей RT-Thread и NXP, охват адаптации NXP расширен до MCX A366 и A156 (11-02)
      • Официальный новостной интерфейс по-прежнему на 17 июня, публикации продолжаются в медиаколонке (11-03)
    1. Экосистема и адаптация производителей
      • HPMicro одним разом вывела 12 репозиториев BSP на v1.13.0 и открыла HPM5100EVK (11-02)
      • Основная ветка AWTK итерируется как обычно, в этом выпуске коммиты не связаны специально с RT-Thread (11-02)
    1. Отраслевые применения
      • Промышленный шлюз с открытым кодом: FreeModbus master, панель LVGL, 4G-подключение к облаку и HTTP OTA объединены в один образ (11-02)
      • Прошивка умных часов Sifli SF32LB52 ставит RT-Thread на носимую базу (11-02)
    1. Тенденции и итоги выпуска
      • Тенденция: шесть слияний за день — всё старые долги, очередь безопасности начинает брать на себя сопровождающий
      • Ограничения и пояснения по дедупликации

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

1.1 Два исправления USB device с контролируемой хостом длиной слиты одновременно: индекс строкового дескриптора и совместимый ID MS OS (11-02)

Дата: 2026-11-02 11:47 (время слияния)　Источник: предложение #11545, предложение #11546, дефект #4782, дефект #11287

Два исправления от одного автора, слитые в один час, устраняют одну и ту же старую проблему в стеке протокола USB device — «длина и индекс приходят от хоста».

#11545 обрабатывает индекс строкового дескриптора (39 строк добавлено, 15 удалено). Исходная реализация перед получением строки не проверяла индекс, заданный хостом, а сразу читала таблицу строк по индексу; при выходе за границы читался указатель соседней интерфейсной строки, а при отсутствии регистрации могло произойти разыменование нулевого указателя. Способ исправления двойной: перед чтением таблицы проверять границы индекса, для неизвестного или незарегистрированного индекса EP0 всегда возвращает STALL; строка OS возвращается только при зарегистрированном дескрипторе совместимого ID Microsoft OS. Соответствующий дефект #4782 открыт 10 июня 2021 года и висел более четырёх лет.

#11546 Обработка длины ответа с ID совместимости MS OS (4 добавленные строки, 1 удалённая). Хост при запросе этого дескриптора может задать произвольный wLength; исходная реализация формировала передачу EP0 в соответствии с wLength, что могло привести к отправке содержимого за пределами уже сформированного буфера дескриптора. Исправление заключается в ограничении длины ответа фактическим размером сформированного дескриптора; поведение выделения памяти и кэширования не меняется. Соответствующий дефект #11287 открыт 23 марта 2026 года.

Оба предложения открыты 1 июля 2026 года и в тот же день попали в очередь на слияние. Автор в предложениях честно указал, что проверка ограничилась git diff --check и проверкой символов перевода строки, а сборка и USB device utest не запускались, поскольку на имеющейся машине с Windows отсутствуют scons, компилятор C и встраиваемый кросс-тулчейн. Это стоит зафиксировать: оба изменения невелики, но путь USB-дескрипторов не покрыт автоматическими тестами, и уверенность при слиянии основана главным образом на ревью кода.

1.2 Буфер имени на 32 байта при инициализации хоста SDHCI: при RT_NAME_MAX = 64 происходит переполнение стека (11-02)

Дата: 2026-11-02 11:24 (время слияния)　Источник: предложение #11542

6 добавленных строк, 4 удалённые, изменения в dev_sdhci.c драйвера SDHCI. Симптом: на qemu-virt64-aarch64 при включённом SDHCI и RT_NAME_MAX = 64 процесс загрузки завершается data abort, fault addr 0x228.

Первопричина — локальный буфер жёстко задан размером 32 байта: char dev_name[32], тогда как sdio_host_set_name() по правилам именования объектов ядра записывает до RT_NAME_MAX символов; после заполнения имени до 32 байт следующие две строки rt_sprintf(&dev_name[len], "-timer") и -data-timer продолжают запись, переполняя стек. Как только длина имени превышает 32, выход за границы из «возможного» становится «неизбежным».

Исправление меняет буфер на char dev_name[RT_NAME_MAX] и после возврата из sdio_host_set_name() добавляет dev_name[sizeof(dev_name) - 1] = '\0' перед пересчётом длины; обе конкатенации суффиксов заменены с rt_sprintf на rt_snprintf с параметром остатка длины. Таким образом, даже при RT_NAME_MAX = 64 или 128 общая длина имени и суффикса ограничивается самим буфером.

Проблема такой формы в RT-Thread не редкость: ядро допускает настройку RT_NAME_MAX, но в драйверах немало мест с жёстко заданными малыми буферами. Этот случай выявлен при запуске инициализации SD-карты на QEMU на плате конкурсной работы, что показывает: комбинации с нестандартным значением RT_NAME_MAX обычно не тестируются.

1.3 Побайтовый цикл klibc распознаётся GCC как memset — сбой линковки на целях без libc (11-02)

Дата: 2026-11-02 18:08 (время слияния)　Источник: предложение #11965, дефект #6128

13 добавленных строк, 1 удалённая, изменён только src/klibc/SConscript, ни одна строка C-кода не затронута.

rt_memset(), rt_memcpy() и rt_memmove() в kstring.c завершаются побайтовыми циклами. GCC при -O2 и -Os с включённым -ftree-loop-distribute-patterns распознаёт такие циклы как вызовы стандартной библиотеки и переписывает их в обращения к memset и memcpy. Если на целевой платформе нет C-библиотеки, эти символы отсутствуют, и прошивка падает на этапе линковки с чередой undefined reference, по которой невозможно понять, что причина связана с реализацией строковых функций.

Автор воспроизвёл проблему с arm-none-eabi-gcc 10.3.1 на проекте платы vexpress-a9 в QEMU с -Os: до исправления в kstring.o из klibc появляется U memset, причём два bl 0 <memset> находятся внутри самого rt_memset() — собственный memset ядра вызывает несуществующий memset. Дефект #6128 открыт 30 июня 2022 года; в первоначальном отчёте говорилось лишь о проблеме компиляции rt_memset в aarch64-gcc.

Исправление добавляет -fno-tree-loop-distribute-patterns в группу Libc, причём только при CROSS_TOOL == 'gcc'; сборки Keil и IAR не затрагиваются. Цена — эти циклы больше не векторизуются и не сворачиваются, но данные функции klibc и так не находятся на горячем пути. Этот опыт универсален для команд, занимающихся портированием на bare-metal: между собственной реализацией строковых функций и опциями оптимизации компилятора существует неявный контракт, который легче всего нарушается при обновлении тулчейна.

1.4 tiny vsnprintf обрабатывает long long как long, INT64_MAX печатается как -1 (02.11)

Дата: 2026-11-02 16:25 (время слияния)　Источник: предложение #11600

Добавлено 20 строк, удалено 3 строки, изменены rt_vsnprintf_tiny.c и соответствующие тесты. В tiny-версии для экономии места квалификатор ll в %lld и %lli объединён с путём обработки long, в результате чего 64-битные целые усекаются до 32 бит, а определение знака также смещается — наиболее наглядное проявление: INT64_MAX печатается как -1.

Исправление разделяет две внутренние знаковые ветви L (представляющую ll) и l: ll принимает аргумент как long long и определяет знак по 64-битному диапазону, l сохраняет путь long. Одновременно добавлены регрессионные тесты граничных значений для rt_sprintf, охватывающие четыре значения: INT32_MIN, UINT32_MAX, INT64_MIN, INT64_MAX.

Конфигурация проверки — qemu-vexpress-a9 с опцией поддержки long long в tiny-версии (VSNPRINTF_LONGLONG, стандартный vsnprintf не включён). Предложение открыто 9 июля 2026 года и пролежало в очереди почти четыре месяца. Tiny-версия — выбор по умолчанию для многих проектов с ограниченными ресурсами; такое молчаливое усечение трудно обнаружить при печати логов и форматировании временных меток.

1.5 Контроллер сброса SCMI берёт неверный контейнер, порядок регистрации драйверов также перенесён на инициализацию подсистемы (02.11)

Дата: 2026-11-02 18:20 (время слияния)　Источник: предложение #11946

Добавлено 22 строки, удалено 7 строк, изменены два файла reset-scmi.c и pm-domain-scmi.c — последний push в данном окне мониторинга.

Проблема на стороне сброса — неверный объект в преобразовании контейнера. scmi_reset_reset(), assert(), deassert() и функция разбора дерева устройств используют raw_to_scmi_reset(rstc), принимая указатель rt_reset_control за контроллер сброса SCMI для обратного вывода; правильный способ — через rstc->rstcer, сначала получить контроллер сброса, затем преобразовать. Последствие передачи неверного указателя — не крах, а чтение смещённых полей; проявление зависит от раскладки памяти, поэтому такие ошибки обычно обнаруживаются только когда на конкретной плате «сброс не срабатывает».

На стороне регистрации два драйвера ранее использовали RT_SCMI_DRIVER_EXPORT, заменено на явную функцию регистрации плюс INIT_SUBSYS_EXPORT. Различие двух экспортных макросов — момент регистрации: драйвер должен регистрироваться после готовности инфраструктуры сброса и доменов питания, иначе потребитель, выполнивший probe раньше, не получит provider. В описании предложения также упоминается поиск атрибутов по reset domain ID, разобранному из дерева устройств, и сохранение ссылки на устройство SCMI в экземпляре контроллера сброса, чтобы время жизни контроллера не было короче устройства.

1.6 Правила версий X/Y/Z выходят на ревью документации, список тестов QEMU для Z-версии опубликован одновременно (02.11 ~ 03.11)

Дата: 2026-11-02 15:24 (список) / 2026-11-03 07:23 (обновление документа)　Источник: предложение #11955, дефект #11972, предложение #11974, предложение #11976

Предложение по управлению версиями #11955, о котором сообщалось в прошлом выпуске, обновлено в конце окна мониторинга (03.11 07:23); содержание документа уже конкретизировано: правила определения трёхуровневых номеров версий X/Y/Z, цикл Y-версии 3–6 месяцев, цикл Z-версии 1 месяц, обязанности по выпуску и требования совместимости на каждом уровне. Всё ещё на ревью, не слито.

Сопутствующий список выполнения опубликован CYFS3 02.11 в 15:24 как дефект #11972 с весьма прямолинейным заголовком — автоматизированные тесты CI для выпуска Z-версии. Ключевая идея — «заменить реальное оборудование эмулируемыми устройствами QEMU»: на примере микрофона достаточно зарегистрировать набор виртуальных ops, создав эмулируемый микрофон, и полностью протестировать входные параметры интерфейсов фреймворка, не дожидаясь платы. Список по каждому фреймворку перечисляет текущее состояние обеих сторон — utest и QEMU: для SPI есть тест loopback, для PWM — тест частоты и скважности, для RTC — тест будильника, для audio уже есть эмулируемый микрофон и плеер с обратными вызовами DMA внутри прошивки, тесты фреймворков adc и dac в процессе дополнения (соответствуют #11974 и #11976), а на стороне QEMU для i2c, can, watchdog, touch, usb, sdio, flash, ethernet в основном пусто.

Ценность этого списка в том, что он превращает вопрос «можно ли выпускать версию Z» из субъективного суждения сопровождающих в таблицу с отмечаемыми пунктами. Вместе с #11955 он составляет две половины одного целого: одна половина задаёт правила, другая предоставляет доказательства. На момент сдачи материала у #11972 было 6 комментариев, два предложения utest для adc и dac уже выставлены, но ещё не слиты.

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

2.1 Отрицательное смещение графического устройства: pread и pwrite обходят проверку позиции и получают прямой произвольный доступ на чтение-запись в ядре (11-02)

Дата: 2026-11-02 12:01 (время отчёта)　Источники: дефект #11969, предложение #11970

Автор отчёта XueDugu, проверка проводилась относительно master 08cad4ee того же дня. Область влияния описана чётко: от v5.3.0 до текущего master, дефект внесён коммитом 5abecc1fd0c3 от 2025-12-12, текущий blob файла graphic.c — 14de5a6c.

_graphic_read() и _graphic_write() принимают знаковое смещение устройства, но не проверяют pos >= 0 и не проверяют pos < framebuffer_len. Оставшаяся длина вычисляется как rt_min_t(rt_ssize_t, plane->framebuffer_len - pos, size): при отрицательном pos framebuffer_len - pos становится большим положительным числом, res напрямую принимает значение size, и затем rt_memcpy(plane->framebuffer + pos, buffer, res) выполняет чтение-запись до или после фреймбуфера.

Точка входа — pread64() и pwrite64() в RT-Smart. Текущая rw_verify_area() отклоняет отрицательную позицию только при count >= -pos, поэтому комбинация вида count=8, pos=-210456 проходит проверку и доходит до драйвера. В отчёте приведены два уровня проверки: qemu-virt64-aarch64 с собственным устройством ramfb из QEMU, что доказывает путь выхода за границы из пользовательского пространства в ядро; Raspberry Pi Pico 2 W (RP2350) через USB CDC, что подтверждает сам примитив board-level API ядра.

Предложение об исправлении #11970 появилось через 31 минуту (12:32), автор usualtreee, 10 добавленных строк, изменён только один файл graphic.c: обе функции перед вычислением оставшейся длины сначала проверяют pos, отрицательные значения и позиции больше либо равные framebuffer_len сразу возвращают 0, поведение обрезки на фронте легальных операций чтения-записи остаётся неизменным. Это самый быстрый отклик в данном окне — от отчёта до патча полчаса, но патч ещё не слит.

2.2 Патч для pipe появился в тот же день, изменён на стороне драйвера с самозащитой по команде (11-02)

Дата: 2026-11-02 15:23 (время предложения)　Источники: предложение #11971, дефект #11958

Дефект pipe FIONREAD, о котором сообщалось в прошлом выпуске, дождался патча. 22 добавленных строки, 4 удалённых, изменён только файл, где находится pipe_fops_ioctl.

Суть изменения: длина данных или оставшееся пространство кольцевого буфера сначала вычисляются в стековую переменную int, в сборке с MMU используется lwp_put_to_user() для копирования обратно в пользовательский адрес, в сборке без MMU сохраняется прямая запись — в едином адресном пространстве изоляции нет, и этот дополнительный слой лишь нарушил бы совместимость. Попутно добавлены проверки на null для pipe и pipe->fifo, а include lwp_user_mm.h обёрнут в ARCH_MM_MMU.

В предложении есть пояснение, почему не стали перехватывать централизованно в sys_ioctl(): семантика ioctl различается от драйвера к драйверу, где-то это скалярный arg, где-то указатель на структуру, глобальная проверка легко может навредить, поэтому самозащита по команде на стороне драйвера уместнее. Этот компромисс стоит запомнить: в прошлом выпуске pipe, блочное устройство и терминал были отнесены к одной причине, но единая точка входа — не единственное решение, ценой является то, что каждый драйвер должен помнить о необходимости делать это сам.

2.3 Сопровождающий лично переделал два старых предложения: getaddrinfo и таблица разделов GPT (11-03)

Дата: 2026-11-03 00:08 / 07:18 (время предложения)　Источники: предложение #11977, предложение #11978

Оба предложения поданы BernardXiong, первая фраза текста обоих гласит: «это переделка #xxxx (исходный PR конфликтует и устарел)».

#11977 Переделано #11454, усилена обработка пользовательских указателей в sys_getaddrinfo() (57 строк добавлено, 17 удалено). Исходная реализация проверяла только верховный буфер res, после чего через управляемый пользователем вложенный указатель res->ai_addr записывала результаты разрешения — в сборках Smart/MMU это эквивалентно произвольной записи в ядро; поля hints после верховной проверки по-прежнему читались из пользовательской памяти, что создавало окно TOCTOU. Новая реализация с помощью lwp_get_from_user() копирует res и hints за один раз во временную структуру ядра, и все последующие вложенные указатели берутся из этого снимка; вложенные sockaddr и внешняя структура единообразно записываются обратно через lwp_put_to_user(); попутно исправлена проверка возвращаемого значения при копировании servname — исходный код сравнивал size_t с 0, что всегда ложно.

#11978 Переделано #11275, исправлен переворот начала и конца в таблице разделов GPT (11 строк добавлено, 5 удалено, изменён только efi.c). is_pte_valid() требовала лишь, чтобы starting_lba и ending_lba находились в пределах диска, и не проверяла ending_lba >= starting_lba; сконструировав GPT-образ с корректным CRC, можно вызвать беззнаковое переполнение вниз в size = ending_lba - starting_lba + 1ULL, получить огромный размер раздела и зарегистрировать его как логический раздел. Исправление — добавить в функцию проверки условие end < start и перенести вычисление start и size после проверки корректности, вычисляя size по уже проверенному start. Соответствующий дефект #11271, исходное предложение #11275 закрыто 11-03 07:20.

Если посмотреть на оба изменения вместе, сигнал важнее самого способа исправления: как только патчи, выставленные внешними репортёрами, устаревают и конфликтуют, мейнтейнеры начинают переделывать их сами, а не ждать rebase от автора. Это две стороны одного и того же, что и быстрые патчи в 2.1 и 2.2 — очередь движется.

2.4 В очереди ещё пять изменений: имена каталогов cromfs, счётчик poll, длина 9pfs, исчерпание пула DHCP, signalfd (10-21 ~ 11-03)

Дата: 2026-10-21 ~ 2026-11-03 (время предложения и последнего обновления)　Источники: предложение #11911, предложение #11954, предложение #11918, предложение #11947, предложение #11935

#11911 — чтение имён каталогов в cromfs (421 строка добавлена, 116 удалено, 7 файлов, по состоянию на 11-03 07:50 всё ещё обновляется). dfs_cromfs_getdents() напрямую берёт uint16 name_size из образа как длину для memcpy при копировании в d_name, не сравнивая с DIRENT_NAME_MAX (256) и не проверяя, попадает ли имя в только что загруженный blob каталога; сразу следующая строка записывает NUL в позицию name_size, поэтому при name_size до 256 исходный код сам по себе пишет на один байт за границу. Вызывающая сторона также не обрезает — ls() в msh размещает struct dirent в стеке потока shell и запрашивает у getdents только один элемент, так что слишком длинное имя каталога перезаписывает стек потока shell.

#11954 — переполнение при умножении счётчиков в poll и epoll (166 строк добавлено, обновлено 11-03 07:24, масштаб вырос почти в шесть раз по сравнению с прошлой записью). sys_poll() вычисляет размер буфера ядра по числу, заданному пользователем; на 32-битной системе произведение переполняется, но затем всё равно выполняется обход по исходному числу: при nfds = 0x20000001 и pollfd размером 8 байт произведение усекается до 8, проверка и выделение проходят по 8 байтам, а poll() обходит 530 миллионов элементов.

#11918 — клиент 9pfs доверяет длине, переданной сервером (66 строк добавлено, 6 удалено). Возвращаемое p9_transaction() число байт отбрасывается, и при разборе напрямую используются count, stat_size и name_len из пакета; сконструировав ответ «count огромен, но фактически очень короток», можно прочитать за пределы приёмного буфера — на практике зафиксирован выход за 8,3 MB, ASAN сообщает use-after-poison, одновременно утекает информация о каталоге.

#11947 — неограниченный поиск после исчерпания пула адресов DHCP (19 строк добавлено, 5 удалено). dhcp_client_alloc() при занятости кандидата продолжает поиск через goto, не ограничивая число попыток; когда пул полностью заполнен, DISCOVER нового MAC заставляет её бесконечно крутиться в пути приёма lwIP, и все последующие пакеты блокируются. Исправление — запоминать первого кандидата текущего раунда, останавливаться при возврате к началу и возвращать NULL при заполненном пуле.

#11935 — это удаление слушателя в signalfd_close (91 добавленная строка, 35 удалённых). Исходная реализация регистрировала уведомления с помощью глобального счётчика индексов; при закрытии она не отцепляла узел от цепочки и не освобождала его, оставляя висячие узлы; новый подход заменяет это пограничным поиском по верхнему пределу количества зарегистрированных слотов, при закрытии обходит зарегистрированные lwp, отцепляет соответствующие узлы от цепочки уведомлений и освобождает их, одновременно очищая указатель контекста файла.

Общая черта всех пяти коммитов — всё та же старая проблема: длина, счётчики и индексы приходят из пользовательского пространства или от второй стороны, и перед входом в логику ядра нет слоя проверки. Разница в том, что теперь к каждому коммиту прилагается соответствующее предложение, и большинство содержит шаги воспроизведения на QEMU.

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

3.1 Завершился Шанхайский конкурс инноваций в области открытого программного обеспечения, Ruiside — один из 12 постановщиков отраслевых задач (10-29 ~ 10-30, официальная публикация 11-02)

Дата: 2026-11-02 (официальная публикация) / 2026-10-29 ~ 10-30 (мероприятие)　Источники: Шанхайская комиссия по экономике и информатизации: конкурс завершён, People.cn: продвигать больше открытых результатов с площадки конкурса на рынок

Финал Шанхайского конкурса инноваций в области открытого программного обеспечения 2026 и конференция инновационного роста прошли с 29 по 30 октября в Шанхайском инновационном городке искусственного интеллекта Чжанцзян, организатором выступил OSChina. С момента старта регистрации 5 августа было получено 766 заявок, участие приняли более 40 партнёрских компаний и сообществ открытого ПО; 12 реальных отраслевых задач привлекли 269 проектов, 30 команд вышли в финал и боролись за призовой фонд общей стоимостью 1 млн юаней.

Среди постановщиков 12 задач Ruiside (RT-Thread) вместе с COMAC, Zhongchuan Haizhou, DaoCloud, Yunzhou Technology и Mofa Technology находится на стороне местных шанхайских компаний, а на другой стороне — общенациональные технологические компании и сообщества, такие как Baidu Maps, сообщество openKylin, сообщество open-supOS и другие. Для RT-Thread эта позиция означает, что «промышленные и встраиваемые сценарии рассматриваются как источник реальных отраслевых задач», а не как спонсорское место.

На церемонии награждения 30 октября OSChina объявила о своём официальном переезде в Шанхай, а бренд конкурса повышается до ежегодного мероприятия в области открытого ПО и искусственного интеллекта Шанхая, которое будет проводиться каждый год начиная с этого года; проекты 30 финальных команд охватывают промышленное моделирование, планирование вычислительных ресурсов и ускорение вывода, управление безопасностью интеллектуальных агентов, контроль качества данных для воплощённого интеллекта, вычисления в науках о жизни, причём команды шанхайских вузов, предприятий и сообществ открытого ПО составляют около трети.

3.2 Запущен совместный опрос пользователей RT-Thread и NXP, список поддержки NXP расширен до MCX A366 и A156 (11-02)

Дата: 2026-11-02 17:30 (публикация)　Источники: EE Times China: опрос RT-Thread и NXP

Официальная колонка RT-Thread опубликовала совместное исследование пользователей с NXP, период проведения — с 2 по 23 ноября, розыгрыш призов — 24 ноября. В начале статьи сотрудничество описано вполне конкретно: уже адаптированы MCX N947, MCX A366, MCX A156 и другие микросхемы. Опрос требует указать конечное устройство, сценарий применения и сложности разработки, а также приглашает вносить предложения по улучшению производительности чипов, периферии и адаптации экосистемы.

Сама по себе это акция по работе с сообществом, но раскрытый список адаптаций представляет ценность: серия MCX A — это линейка универсальных MCU, которую NXP активно продвигает последние два года, и появление A366 и A156 в списке адаптаций показывает, что покрытие RT-Thread на продуктовой линейке NXP расширилось от моделей с NPU, таких как N947, к универсальным моделям. Предложение по скрипту компоновки промышленного Ethernet NXP i.MX RT1180 (#11959), о котором сообщалось в прошлом выпуске, всё ещё находится в очереди, и эти две линии можно сопоставить — одна представляет широту на стороне MCU, другая — глубину на стороне кроссоверных процессоров.

3.3 Официальный новостной интерфейс по-прежнему застрял на 17 июня, выход публикаций остаётся в медиаколонке (11-03)

Дата: 2026-11-03 (проверка)　Источники: Официальный список новостей RT-Thread

Последняя запись, возвращаемая официальным новостным интерфейсом getList?type=rt_org, — это всё ещё «Ruiside Technology приглашена на Инвестиционный форум Абу-Даби 2026» от 2026-06-17, новостной раздел главной страницы официального сайта также остановился на июне, новых записей в этом выпуске нет. Это уже шестой месяц подряд без обновлений данного интерфейса.

Фактический выход публикаций находится в медиаколонке: в окне мониторинга этого выпуска официальная колонка RT-Thread в EE Times China обновилась одной статьёй (опрос NXP от 11-02), другая статья о промоакции к 11.11 от 11-01 не включена. На форумной стороне club.rt-thread.org по-прежнему возвращает 468, страницу вызова WAF, поэтому список и текст невозможно прочитать напрямую, и динамику сообщества приходится перекрёстно проверять по GitHub и медиаколонке.

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

4.1 HPMicro за один раз выдвинула 12 репозиториев BSP до v1.13.0 и открыла новый HPM5100EVK (11-02)

Дата: 2026-11-02 11:43 ~ 11:56 (время публикации)　Источники: репозиторий: rtt-bsp-hpm5100evk, репозиторий: rtt-bsp-hpm6800evk, репозиторий: rtt-bsp-hpm6e00evk

Среди 64 репозиториев организации HPMicro на GitHub 12 репозиториев RT-Thread BSP были массово отправлены за тринадцать минут — с 11:43 до 11:56 2 ноября: HPM6750EVK, HPM6750EVK2, HPM6750EVKMINI, HPM6E00EVK, HPM6P00EVK, HPM6800EVK, HPM6300EVK, HPM6200EVK, HPM5E00EVK, HPM5300EVK, HPM5301EVKLITE, а также новый HPM5100EVK.

При проверке по каждому репозиторию сообщения коммитов совпадают: в HPM5100EVK, HPM6800EVK и HPM6E00EVK — «RT-Thread BSP v1.13.0 for <имя платы="">», временные метки попадают в один и тот же интервал с точностью до секунды, что позволяет заключить, что это единовременный скриптовый релиз, а не отдельная разработка по каждому репозиторию. Предыдущими коммитами в HPM6800EVK и HPM6E00EVK были v1.11.0 от 2026-02-03; до этого коммита прошло около девяти месяцев, записей о коммитах v1.12.0 между ними нет.

HPM5100EVK — новый репозиторий (создан 11-02 10:59), первый же коммит — v1.13.0, в README указано, что это RT-Thread Studio BSP, в комплекте примеры: adc, blink_led, flashdb, mcan, pwm, spi_nor_flash_fs, timer, uart_dma, usb_device_generic_hid и usb_host_msc_udisk. Список примеров показывает позиционирование платы: двойная роль CAN и USB, файловая система и FlashDB входят в охват по умолчанию — уклон в промышленные сценарии и сценарии регистрации данных.

Разделение BSP производителями чипов на отдельные репозитории и их поддержка в виде проектов Studio — обычная практика экосистемы RT-Thread за последние два года (так делают GigaDevice, ST, Renesas). Что стоит отметить — ритм релизов: двенадцать репозиториев в один день с одной версией означают, что у HPMicro есть внутренний набор скриптов синхронизации от SDK до BSP каждой платы, и это лучше обеспечивает согласованность между платами, чем ручное слияние по каждому репозиторию.

4.2 Основная ветка AWTK итерируется как обычно, в коммитах этого выпуска нет специальной связи с RT-Thread (11-02)

Дата: 2026-11-02 17:42 (время публикации)　Источники: репозиторий: zlgopen/awtk

AWTK от Zhiyuan Electronics (3325 звёзд) имел одну отправку в окне мониторинга, заголовки трёх последних коммитов — «improve edit», это повседневная итерация универсального GUI-фреймворка, специальных изменений под RT-Thread не обнаружено. Репозиторий имеет тег topic:rt-thread и давно поддерживает RT-Thread BSP, поэтому включён в обзор экосистемы, в этом выпуске отдельным пунктом не раскрывается.

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

5.1 Открытый исходный код промышленного шлюза: FreeModbus-мастер, панель LVGL, выход в облако через 4G и HTTP OTA объединены в один образ (11-02)

Дата: 2026-11-02 13:59 (создание репозитория)　Источники: репозиторий: rtthread-industrial-gateway

Новый личный проект, реализующий четыре канала промышленного шлюза данных на одной плате STM32F407VGT6: по нисходящему каналу FreeModbus работает как RTU-мастер и циклически опрашивает регистры хранения полевых подчинённых устройств; локально LVGL 8.3 обеспечивает HMI, управление кнопками и обратное считывание используют общую таблицу зеркала регистров хранения; по восходящему каналу через 4G-модуль ML307 по MQTT QoS1 осуществляется подключение к ThingsBoard с поддержкой обратного управления через RPC; удалённое обновление использует блочную HTTP-загрузку с проверкой CRC32, запись в раздел download, после чего rtboot переносит образ в раздел app и выполняет переход.

Аппаратная конфигурация описана подробнее, чем в большинстве аналогичных репозиториев: 16-битный TFT с параллельным интерфейсом FSMC 8080, резистивный экран xpt2046 по SPI, W25Q128 (16 MB) на SPI1 с программным управлением выбором кристалла через PG15, ML307 на uart6 с AT-командами, подчинённое устройство Modbus на uart3 9600 8N1. Проект развивается по девяти этапам, на последнем этапе все четыре канала объединяются в один образ.

Смысл этой комбинации в том, что «весь тракт находится на плате»: многие проекты шлюзов перекладывают облачное подключение на внешний модуль или второй MCU, а этот проект укладывает 4G, преобразование протоколов, HMI и OTA на один M4F, ценой чего является необходимость разместить в 192 KB SRAM одновременно буферы LVGL, кадры Modbus и сессии MQTT. Для команд, выбирающих промышленный шлюз, структура каталогов и разбиение на разделы этого репозитория дают больше ориентиров, чем готовое изделие.

5.2 Прошивка умных часов Sifli SF32LB52: RT-Thread на носимой базе (02.11)

Дата: 2026-11-02 18:03 (время публикации)　Источник: Репозиторий: helios-sf32

Прошивка умных часов на основе OpenSifli SDK, целевая плата — LCD-экран отладочной платы Sifli SF32LB52, UI на LVGL, база — RT-Thread. Репозиторий создан 4 сентября, в окне мониторинга был один пуш, сейчас 5 звёзд и 1 форк.

Носимые устройства — относительно редкая область применения RT-Thread. Ограничения таких продуктов противоположны промышленным платам: обновление экрана должно быть плавным, энергопотребление в режиме ожидания — низким, ресурсы UI должны поддерживать горячее обновление, а преимущество RT-Thread здесь — урезаемость компонентов и зрелая привязка к LVGL. OpenSifli SDK использует RT-Thread как RTOS по умолчанию, что говорит о том, что эта продуктовая линейка Sifli выбрала базу ещё на уровне SDK, и сторонние проекты прошивок могут наследовать её напрямую.

6. Тренды и итоги выпуска

6.1 Тренд: шесть слияний за день — всё старые долги, очередь безопасности переходит к мейнтейнерам

За 24 часа этого выпуска в основной репозиторий слито 6 изменений, все — 2 ноября с 11:24 по 18:20. Немного, но структура очень концентрированная: четыре предложения были открыты 1 июля 2026 года (#11542, #11545, #11546 отправлены в тот же день, #11600 — 9 июля), одно соответствует дефекту #6128 от июня 2022 года, одно — дефекту #4782 от июня 2021 года. Иными словами, в этот день разбирали накопившееся, а не новую работу.

Первая линия — «скрытые дефекты в комбинациях конфигураций». Переполнение стека SDHCI в #11542 срабатывает только при RT_NAME_MAX = 64, усечение long long в #11600 появляется только при включённом tiny vsnprintf, ошибка линковки в #11965 проявляется только на целевой платформе без C-библиотеки. Общее у всех трёх — их не поймать при конфигурации по умолчанию, а как раз эти нестандартные комбинации чаще всего встречаются в реальных проектах: сменил чип, сменил инструментальную цепочку, сэкономил немного Flash — и наткнулся.

Вторая линия — разбор границ RT-Smart и устройств перешёл во вторую фазу. В прошлом выпуске вывод был «отчётов много, патчей мало», в этом выпуске изменения в том, что патчи начали подтягиваться и реакция ускорилась: отрицательное смещение графического устройства — от отчёта до предложения 31 минута (#11969 до #11970), патч для pipe на месте в тот же день (#11971 соответствует #11958 из прошлого выпуска), сам мейнтейнер переделал два устаревших предложения по getaddrinfo и GPT (#11977, #11978). В очереди по-прежнему пять на рассмотрении, но у каждого есть воспроизводимые шаги, стоимость ревью уже снизилась.

Третья линия — управление версиями перешло от «плана» к «доказательствам». #11955 фиксирует в документации циклы и обязанности X/Y/Z, #11972 разбивает вопрос о возможности выпуска Z-версии на пофреймворковый список QEMU-виртуальных устройств и utest, даже для тестов эмулируемых устройств adc и dac приложено предложение. Обе вещи не меняют ядро, но определяют критерии для каждого последующего релиза Z-версии — в прошлом выпуске говорилось «превратить этапы, полагающиеся на ручную сортировку, в проверяемый процесс», в этом выпуске видно, как список воплощается.

Действия на стороне экосистемы более прямые: HPMicro за тринадцать минут продвинула 12 репозиториев BSP до v1.13.0 и открыла HPM5100EVK, что говорит о том, что поддержка BSP на стороне производителя уже скриптована; на стороне сообщества появился проект промышленного шлюза, в котором Modbus, LVGL, 4G и OTA ужаты на одном M4F. С одной стороны, производитель обеспечивает единообразие между платами, с другой — разработчики собирают компоненты до предела, и эти два конца как раз и есть самая реальная картина экосистемы RT-Thread на сегодня.

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

Форум club.rt-thread.org в этом выпуске по-прежнему возвращает 468 с предварительной страницей вызова WAF, список тем и текст сообщений напрямую прочитать невозможно; пробел в информации со стороны обсуждений сообщества заполнен GitHub и колонками СМИ, построчное сравнение не проводилось. Официальный новостной API и список новостей на официальном сайте одинаково застыли на 17 июня, информация со стороны релизов может опираться только на колонки СМИ.

Две группы запросов Google News на английском дали ноль попаданий, три группы на китайском дали результаты: Шанхайский конкурс open source (включён), опрос NXP (включён), материал Zhi Dianxi о роботе-собаке сообщества Arm js (в тексте нет конкретного технического содержания RT-Thread, не включён). Также есть рекламный материал к 11.11 от 01.11, выходящий за окно и являющийся продвижением, не включён. В окне HN Algolia попаданий, связанных с RT-Thread, нет.

Сторона GitHub в этом выпуске затронута лимитом анонимного API (60 раз в час); коммиты, предложения и детали дефектов основного репозитория получены, номера версий 12 репозиториев HPMicro перекрёстно сверены по HTML и фидам коммитов Atom, из них в трёх местах подтверждено, что сообщение коммита — v1.13.0, остальные девять определены как одновременный выпуск на основании одного и того же интервала времени, текст коммитов по каждому репозиторию отдельно не извлекался. Внесённые в очередь на рассмотрение в прошлом выпуске #11897 (K230D), #11892 (RISC-V Smart MMU), #11944 (RTL8125), #11943 (дисплей и аудио RK3588), #11959 (линкер-скрипт NXP RT1180) в этом выпуске по-прежнему в очереди, слияния не было, отдельными пунктами не повторяются; #11954 и #11958 были доложены в прошлом выпуске, в этом фиксируются только обновления и прогресс по патчам.

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

Таблица проверки источников

Источники Результаты проверки
Официальный новостной интерфейс (rt_org) За 24 часа новых записей нет, последняя запись от 2026-06-17
Список новостей на официальном сайте Новостной раздел на главной странице по-прежнему за июнь, новых материалов нет
Интерфейс статей сообщества Страница проверки WAF перед сайтом (HTTP 468), список и текст недоступны для чтения
Коммиты основного репозитория 6 коммитов в окне мониторинга, сосредоточены 11-02 11:24 ~ 18:20
PR основного репозитория Смержено 6 (#11542, #11545, #11546, #11600, #11965, #11946); создано и на рассмотрении более десяти, включая #11970, #11971, #11974, #11976, #11977, #11978
Issue основного репозитория Создан 1 (#11969 отрицательное смещение графики); #11972 список опубликован и обновлён в тот же день
Releases и tags основного репозитория Новых нет, последний по-прежнему v5.3.0 (2026-09-10)
RT-Thread org (35 репозиториев) Отправка только в основном репозитории в окне мониторинга, остальные репозитории без активности
HPMicro org (64 репозитория) 12 репозиториев RT-Thread BSP в тот же день отправили v1.13.0, открыт новый HPM5100EVK
Поиск по репозиториям GitHub (rt-thread) В окне мониторинга создано 2 (промышленный шлюз, HPM5100EVK BSP), 4 репозитория отправлены по topic
Google News на китайском 3 совпадения, включено 2 (Шанхайский конкурс открытого исходного кода, опрос NXP)
Google News на английском Ноль совпадений
HN Algolia Совпадений, связанных с RT-Thread, нет
Официальная колонка EE Times China 1 статья в окне мониторинга (11-02 опрос NXP), включена
Сайт Шанхайской комиссии по экономике и информатизации 11-02 опубликовано резюме конкурса, включено

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