모니터링 기간: 2026-10-23 08:00 ~ 2026-10-26 08:00 (베이징 시간, 72시간, 주말 포함)

출처: RT-Thread 공식 뉴스 API, 커뮤니티 포럼 게시글 API, GitHub(메인 저장소 commits / PR / Issue / Releases / tags, RT-Thread/sdk와 toolchains-ci, RT-Thread-packages 조직 내 각 저장소, pkgs-test, topic:rt-thread 생태계 검색), Google News 집계(중·영문 다중 쿼리, 프록시 경유), HN Algolia, 업계 미디어(EE Times China RT-Thread 칼럼) 및 벤더 채널 검증(상세 내용은 부록 출처 목록 참조)

이번 호 인덱스

    1. 커널 및 버전 동향
      • 메인라인 72시간 동안 커밋 두 건뿐: lwIP 루프백 netdev 병합, clang-format 규칙 세분화 및 thread.c 예시 포함 (10-25)
      • qemu-virt64에서 RT-Thread Smart 활성화: riscv64 SMP 비활성화, ext4와 elm 블록 디바이스 마운트, ptyfs와 procfs 마운트 (10-25)
      • lwp_syscall.c 1만 1천 행 분할: 165개 시스템 콜 진입점을 서브시스템별 파일로 분리, 동작 변경 없음 (10-25)
    1. 보안 및 안정성 후속 조치
      • 시간 서브시스템 하룻밤 사이 4건 연속 보고: settimeofday 협소화, gmtime_r 음수 타임스탬프, timer_gettime 절단, A~F 작업 항목 조사 첨부 (10-23／10-24)
      • 32비트 RT-Smart의 sys_poll 랩어라운드: 8바이트 힙 블록이 0x20000001 항목으로 순회되어 커널 힙 범위 초과 읽기/쓰기 발생 (10-24)
      • 지난 호에 병합된 ESP-IDF v6.1 대응이 master에서 C3／C6 빌드를 실패시킴, include 순서 수정 PR 제출됨 (10-25)
      • 기존 결함 제안 상태 점검: NVMe 누수, 9PFS 길이, tmpfs UAF, dlmodule 전역 변수, FDT 깊이 모두 병합 대기 중 (10-25)
    1. 공식 및 커뮤니티 활동
      • 제6회 RISC-V 중국 서밋의 시스템 소프트웨어 관점 보도 게재: RISC-V 병목이 코어에서 시스템 소프트웨어로 이동 중 (10-24)
      • GDR: RT-Thread 커널 객체 조회 기능을 GDB로 이전, QEMU 폐쇄 루프로 3.1.x／4.0.x／4.1.x 지원 (10-25)
      • 커뮤니티 장문 2편: Env 도구 v2.0.3 사용자 지정 설치, Studio 24개 암시적 선언 경고 완전 분석 (10-25)
      • 10-26 저녁 라이브: RT-Thread와 엣지 AI 기반 손 재활 외골격 (10-25)
      • 임베디드 대회 작품 3편: 단말 측 Agent 다중 센서 융합, ART-Pi2 USB 열거 진단, OpenMV 용의자 추적 (10-24／10-25)
    1. 생태계 및 벤더 대응
      • TriCore(AURIX) Env SDK 편입: tricore-gcc 13.4.1과 qemu-tricore 두 패키지 병합, TC2xx／TC3xx／TC4xx 지원 (10-26)
      • ai/Agent 패키지에 음성 전사 엔드포인트 추가, 기본 백엔드를 SiliconFlow에서 DeepSeek 공식 API로 전환 (10-23)
      • Allwinner F101과 H616 BSP 제안 172개 파일, ESP32-S3-DevKitM-1 보드 지원도 보완 (10-24／10-26)
      • 드라이버 및 CI: OSPI 8선 Flash, I2C 제어 트랜잭션 직렬화, STM32 패키지 테스트 동시성 락 (10-23／10-25)
    1. 요약 및 트렌드 관찰
      • 이번 호 트렌드
      • 한계 및 중복 제거 설명

1. 커널 및 버전 동향

1.1 메인라인 72시간 동안 커밋 두 건뿐: lwIP 루프백 netdev 병합, clang-format 규칙 세분화 및 thread.c 예시 포함 (10-25)

날짜: 2026-10-23 17:09 및 2026-10-25 19:26 (병합 시각)　출처: PR #11859, PR #11893, 메인 저장소 커밋 기록

주말 사흘간의 모니터링 기간 동안 master에는 이 두 건의 커밋만 반영되었으며, 이는 지난 호의 “3일간 커밋 없음 후 집중 마무리” 판단과 이어지는 흐름이다. 병합 작업은 모두 비근무 시간대(금요일 17:09, 일요일 19:26)에 이루어졌고, 리뷰 자체는 멈추지 않았으나 개발 측의 신규 코드는 없었다.

첫 번째 항목은 clang-format 규칙 정리로, 2개 파일 +83/-77이며 .clang-format과 src/thread.c만 수정합니다. 브랜치 이름에 토론 단서인 style/clang-format-discussion-11653이 붙어 있고, 두 커밋 날짜는 모두 10-09이며, 본문은 ‘정렬, 중괄호 줄바꿈 및 공백 규칙’의 세분화이고, 두 번째 커밋은 src/thread.c를 새 규칙에 따라 전체 포맷팅한 예시로 사용합니다. 즉 이것은 2주 끌린 리뷰 마무리이지 새로운 작업이 아닙니다. 제안서에는 도구 관련 사실도 하나 기록되어 있습니다: index++ 같은 표기는 clang-format 18.1.8과 23.1.3에서 모두 그대로 유지되며, 강제로 바꾸도록 지정하는 설정 항목이 없고, 검증은 --dry-run --Werror를 사용합니다.

두 번째 항목은 lwIP 루프백 장치를 netdev 프레임워크에 편입하는 것으로, 3개 파일 +54/-0입니다. 이전에는 lwIP의 루프백 포트가 netdev로 등록되지 않아 두 가지 문제가 있었습니다: 127.0.0.1을 사용하는 툴체인이 실행되지 않았고; 물리 링크가 없는 네트워크 네임스페이스에는 기본 사용 가능한 인터페이스가 없었습니다. 변경 사항은 RT_LWIP_USING_LOOPBACK 설정 항목을 추가하고, lo／lo0을 netdev로 등록해 link up 상태로 설정하며, 인터페이스를 지정하지 않을 때 루프백을 기본 인터페이스로 선택하고, 동시에 RAW 수신 메일박스를 키워 루프백 에코를 수용합니다. 검증 설정은 qemu-virt64-riscv로 제시되었고, 제안서에는 “로컬에서 컴파일하지 않았으며, CI에서 빌드를 검증한다”고 명시되어 있습니다 — 이는 지난달 여러 제안서의 승인 기준과 일치합니다: 병합은 빌드 통과를 조건으로 하고, 보드 테스트는 별도로 후속 진행합니다.

버전 측면에서는 여전히 움직임이 없습니다: 최신 릴리스와 태그는 여전히 09-10의 v5.3.0이고, 10-17의 v5.4.0 버전 매크로는 지금까지 릴리스 노트, 바이너리 또는 프리릴리스 태그가 구성되지 않았습니다.

1.2 qemu-virt64에서 RT-Thread Smart 활성화: riscv64 SMP 비활성화, ext4와 elm 블록 장치 마운트, ptyfs와 procfs 마운트 (10-25)

날짜: 2026-10-25 19:50 (최종 업데이트)　출처: PR #11896

이 제안서는 14개 파일 +1263/-1075로, qemu-virt64-riscv와 qemu-virt64-aarch64 두 BSP의 RT_USING_SMART를 활성화합니다. 이전에 이 두 virt 플랫폼은 명목상 Smart를 지원했지만, virtio 블록 장치에 표준 루트 파일 시스템 초기화 흐름이 없었고 pty에도 마운트 지점이 없어 QEMU에서 많은 기능을 테스트할 수 없었습니다.

변경 사항은 네 부분으로 나눌 수 있습니다: riscv64 측에서 SMP를 비활성화하여 Smart의 단일 코어 설정과 맞춤; virtio-blk0에 ext4 또는 elm을 마운트하는 초기화 흐름 추가; ptyfs를 /dev/pts에, procfs를 /proc에 마운트; .config와 rtconfig.h 재생성. 빌드 검증은 riscv64에 RISC-V musl 범용 툴체인, aarch64에 aarch64 musl 툴체인을 사용한다고 명시되어 있으며, 로컬에서는 실행하지 않고 CI에서 검증합니다.

주목할 점은 의존 관계입니다: 이 제안서는 방금 병합된 #11893(RT_LWIP_USING_LOOPBACK 설정 심볼)에 명시적으로 의존하며, .config는 #11893 위에서 생성되었고, 작성자는 의존 항목이 병합된 후 rebase하고 설정을 재생성하겠다고 설명합니다. 이러한 제안서 간 설정 결합은 qemu 플랫폼 개조에서 흔하며, 루프백 포트가 Smart 활성화보다 먼저 적용되어야 하는 이유도 설명합니다 — 루프백이 없으면 Smart에서 로컬 주소에 의존하는 많은 테스트가 실행되지 않습니다.

1.3 lwp_syscall.c 1만 1천 줄 분할: 165개 시스템 콜 진입점을 하위 시스템별 파일로 분리, 동작 불변 (10-25)

날짜: 2026-10-25 19:50 (최종 업데이트)　출처: PR #11894

components/lwp/lwp_syscall.c 단일 파일이 1만 1천 줄을 넘어, 메모리, 파일 시스템, socket, 프로세스, IPC, 시간 여섯 가지 시스템 콜을 한데 모아 리뷰와 검색이 매우 어려웠습니다. 제안서는 이를 components/lwp/syscall/ 디렉터리로 분할하고, 하위 시스템별 파일로 나누며, 공유 시스템 콜 디스패치 테이블과 내부 헤더 파일을 추가하고, LWP 빌드 스크립트에 새 디렉터리를 등록합니다.

규모 면에서 이는 이번 모니터링 기간 최대 항목입니다: 22개 파일 +12223/-11638로 거의 전부 이동과 이름 변경입니다. 제안서는 “기계적 리팩터링, 기능 변경 없음”이라고 자평하며, 165개 시스템 콜 진입점과 동작이 완전히 변하지 않음을 강조합니다. 검증 역시 “로컬에서 컴파일하지 않았으며, CI에서 검증”이고 설정은 CONFIG_RT_USING_SMART=y입니다.

공학적 관점에서 이런 분할 자체는 새로운 능력을 낳지 않지만, 이후 lwp 결함(예: 이번 호 2.2의 sys_poll 랩어라운드)을 읽기 쉬운 파일에서 찾을 수 있는지를 결정합니다. 지난 호에 기록된 9PFS 길이 수렴 제안서도 같은 흐름에 속합니다: Smart 측 코드가 ‘동작 가능’에서 ‘유지보수 가능’으로 전환되고 있습니다.

2. 보안 및 안정성 후속

2.1 시간 서브시스템에서 하룻밤 사이 4건 연속 보고: settimeofday 협소화, gmtime_r 음수 타임스탬프, timer_gettime 절단, 부록으로 A~F 작업 항목 조사 (10-23/10-24)

날짜: 2026-10-23 21:04 및 2026-10-24 20:25 (생성 시간)　출처: Issue #11922, Issue #11923, Issue #11924, Issue #11927

10-23 저녁, 같은 연구자가 components/libc/compilers/common/ctime.c에서 연달아 세 건을 열었고, 다음 날 조사 건 하나를 더해 시간 서브시스템의 의미론적 문제를 한꺼번에 드러냈다. 세 건의 기준선은 모두 master의 a59e72fb5c이며, 전부 소스 수준 격리 재현으로 보드에서는 검증하지 않았다.

첫 번째 건은 settimeofday()의 타입 협소화다. 검증 시 먼저 (long)tv->tv_sec으로 강제 변환하는데, time64/long32의 32비트 ARM ABI에서(time_t는 64비트 부호 있음, long은 32비트) 유효한 양수 타임스탬프가 음수로 변환되어 RTC 드라이버를 호출하기 전에 -1을 반환하고 EINVAL을 설정한다. 작성자는 GNU Arm Embedded 10.3-2021.10으로 타입 크기와 협소화 동작을 격리 검증했다.

두 번째 건은 gmtime_r()의 음수 타임스탬프 처리다. 함수는 NULL이 아닌 값을 반환하지만 필드가 유효하지 않다. 제시된 네 가지 대조값은 직관적이다. -1은 1970-01-01 00:00:-1, -86400은 1970-01-00 00:00:00(yday가 -1), -31536000의 연도 필드는 1970-01--364, -2208988800은 1900-01-01이어야 하지만 1970-01--25566이 된다. 근본 원인은 나머지 연산이 모두 C의 0 방향 절단 의미론을 사용해 음수 입력에서 나머지가 음수가 되고, 연도 루프는 미래 방향으로만 진행할 수 있기 때문이다.

세 번째 건은 timer_gettime()의 절단이다. 총 잔여 나노초를 먼저 rt_uint32_t에 저장한 뒤 초와 나노초로 분해하는데, 10초는 100억 나노초이므로 32비트 변수에 대입하면 상위 비트가 직접 손실된다. 영향을 받는 설정은 RT_USING_POSIX_TIMER와 RT_USING_CLOCK_TIME이 동시에 켜진 경우다.

네 번째 건(10-24 20:25)은 결함이 아니라 조사다. tick, clock_time, RTC, libc, VDSO가 각각 시간 기준선을 유지하는 문제를 작업 항목이 포함된 설계 제안으로 정리하고, 열 가지 부족점(시각 설정 불통일, clockid 의미론 혼란, 소프트 RTC 가짜 동기화, 랩어라운드와 오버플로, hrtimer 회귀, PM 분기, 부팅 시각 부여 상태, NTP 버전 경계 등)을 나열하며, A~F 여섯 가지 추적 가능 작업 항목과 P0~P2 우선순위를 제시하고, 일반 MCU는 A~D만 완료하면 단계적 종점에 도달한다고 명확히 했다. 이 건은 스스로 정적 분석이라고 밝혔으며 컴파일도 보드 검증도 하지 않았다.

부속 수정 제안은 이미 두 건이 열렸다. #11928은 settimeofday()가 필드 자체 타입에 따라 검증하고 더 이상 일괄적으로 long으로 변환하지 않도록 하며, #11929는 gmtime_r()의 기원전 타임스탬프 정규화를 처리한다. 두 건 모두 10-24에 제출되었으며 아직 병합되지 않았다.

2.2 32비트 RT-Smart의 sys_poll 랩어라운드: 8바이트 힙 블록이 0x20000001개 항목으로 순회되어 커널 힙 범위 초과 읽기/쓰기 (10-24)

날짜: 2026-10-24 03:39 (생성 시간)　출처: Issue #11925

이 결함 건은 10-24 새벽에 제출되었으며, 문제는 components/lwp/lwp_syscall.c의 sys_poll()과 libc 측 poll() 사이에 있다. 사용자 공간에서 전달된 nfds로 할당 크기를 계산할 때 nfds * sizeof(struct pollfd)가 32비트 대상에서 size_t 너비로 연산되어 약 1억 7900만 항목을 넘으면 작은 값으로 랩어라운드된다. 그 결과 커널은 8바이트 힙 블록으로 0x20000001개 항목을 순회하며 읽기와 쓰기가 모두 힙 밖에서 발생한다.

영향 범위는 작성자가 제시한 기준으로 32비트 RT-Smart만 영향을 받으며, 64비트 빌드에서는 곱이 64비트로 승격되어 초대형 할당이 -ENOMEM으로 직접 실패하고 랩어라운드되지 않는다. 도입 지점은 2022-12-03의 ecf2d821(sync branch rt-smart, #6641)이며, 첫 영향 버전은 v5.0.0이고 v5.0.0부터 v5.3.0 및 현재 master(5d1fb66d)가 모두 해당된다. 재현에는 bsp/qemu-vexpress-a9를 사용했다.

이 항목은 이전 회차의 9PFS, NVMe 계열인 「디바이스 또는 서버 측이 제어 가능한 메타데이터를 길이로 사용」하는 것과 다르다. 이번 것은 사용자 공간에서 제어 가능한 카운트가 좁은 비트 폭에서 랩어라운드되는 것으로, 전형적인 정수 경계 문제이지만 착지점이 시스템 콜 진입점과 커널 힙 사이이기 때문에 결과가 직접적으로 커널 힙 범위 초과 읽기/쓰기가 된다. 해당 건은 현재 대응하는 수정 제안이 없다.

2.3 이전 회차에 머지된 ESP-IDF v6.1 적응이 master에서 C3／C6 빌드를 레드로 만들었고, include 순서 수정이 제출됨 (10-25)

날짜: 2026-10-25 17:49 (최종 업데이트)　출처: PR #11926, PR #11870 (이전 회차 머지)

이전 회차에 기록된 ESP32-C3／C6의 ESP-IDF v6.1 적응은 10-22에 머지되었으며, 당시 보드 검증 항목에는 「검증 대기」로 적혀 있었다. 이틀 후 master의 C3／C6 빌드가 레드로 전환되었다. 제안 설명에 따르면 master의 두 CI 실행(40043597502, 39929831359)에서 동일한 현상이 재현되었고, 모든 PR의 RT-Thread BSP Static Build Check와 MemBrowse Memory Report도 함께 레드로 바뀌었다.

근본 원인은 적응 코드 자체가 아니라 빌드 순서에 있다. ESP-IDF 패키지는 components/rtthread/scons/ 아래에 FreeRTOS.h의 scons shim을 두고, #include_next로 <freertos/FreeRTOS.h>로 포워딩하는데, RT-Thread의 FreeRTOS-Wrapper include 디렉터리가 shim 뒤, ESP-IDF 자체 FreeRTOS V11 커널 헤더 앞에 와야 한다. 그러나 두 패키지의 SConscript 로딩 순서는 디렉터리 순회 순서에 의해 결정되어 안정적이지 않다. ESP-IDF가 먼저 로드되면 #include_next가 V11 헤더로 해석되어, Wrapper가 제공하는 configNUMBER_OF_CORES, configMINIMAL_STACK_SIZE, configUSE_PREEMPTION 등의 기본값이 모두 적용되지 않고, drv_uart.c 컴파일 시 바로 #error가 발생한다.

수정 제안은 3개 파일만 변경하여 FreeRTOS include 디렉터리 순서를 고정한다. 이 항목을 기록할 가치가 있는 이유는 결함 자체가 아니라 피드백 체인에 있다. 이전 회차에서 「빌드 통과」를 릴리스 조건으로 한 머지가, 이번 회차에서 CI가 순서 의존성을 잡아냈고 수정 제안이 당일에 제출되었다.

2.4 기존 결함 제안 상태 점검: NVMe 누수, 9PFS 길이, tmpfs UAF, dlmodule 전역 변수, FDT 깊이 모두 머지 대기 (10-25)

날짜: 2026-10-25 (확인 시간)　출처: PR #11920, PR #11918, PR #11910, PR #11915, PR #11901

이전 회차에 수록된 몇 건의 수정은 모니터링 기간 내에 모두 업데이트가 있었지만 머지되지 않았고, 상태는 「제안 제출됨, 리뷰 대기」에 머물러 있다. NVMe 비활성 네임스페이스를 만날 때마다 할당 누수 (#11920, 10-25 00:35 업데이트), 9PFS가 서버 측 길이 필드를 실제 수신 바이트로 수렴 (#11918, 10-24 17:19 업데이트), tmpfs가 0 길이로 절단될 때의 해제 후 사용 (#11910, 10-23 23:31 업데이트), 로드 가능 모듈의 미초기화 전역 변수 (#11915, 10-24 17:27 업데이트).

모니터링 기간에 추가로 편입된 두 건은 새로운 것입니다. 첫째는 FDT 언플래튼의 깊이 제한(#11901, 10-25 15:49 업데이트)으로, fdt_unflatten_single()가 고정 64개 항목의 스택 np_stack에 순회 경로를 임시 저장하는데, 푸시 전에 깊이를 검사하지 않아 깊이가 64계층을 초과하는 DTB에서는 스택 범위를 벗어난 쓰기가 발생합니다. 작성자는 qemu-virt64-aarch64에서 이를 재현했으며, 수정 방식은 언플래튼 전에 독립적인 수동 스택 순회로 최대 깊이를 산출하고 63계층을 초과하면 즉시 거부하는 것입니다. 둘째는 시리얼 rx_indicate가 잘못 초기화되는 문제(#11931, 10-26 01:34 업데이트)로, echo xxx /dev/uart0 이후 콘솔이 더 이상 응답하지 않습니다. 작성자는 “open_flag가 덮어써진다”는 기존 설명을 배제했습니다. 현재 rt_device_open()은 OFLAG_MASK가 일치할 때 드라이버의 open을 아예 호출하지 않기 때문입니다. 실제 원인은 serial_fops_close()가 무조건 rx_indicate를 초기화하는 것으로 판정했으며, 이때 장치는 여전히 콘솔이 보유하고 있습니다(ref_count가 3에서 2로만 감소).

같은 배치에는 드라이버 계층의 정확성 수정 두 건도 있습니다. #11891은 TIOCGWINSZ가 더 이상 finsh_getchar()로 터미널 응답을 읽지 않도록 변경했으며(기존에는 입력을 소비하고 tshell 스레드에서만 사용 가능), termios가 변경되지 않았을 때는 UART 재구성을 건너뛰어 FIFO 리셋을 방지합니다. #11885는 utimensat()의 UTIME_OMIT 판정이 반전된 것을 수정했습니다. 이전에는 “mtime을 변경하지 않음”을 요청해도 오히려 mtime을 덮어쓰고 호출자가 제공한 타임스탬프를 무시했습니다.

3. 공식 및 커뮤니티 활동

3.1 제6회 RISC-V 중국 서밋의 시스템 소프트웨어 관점 보도 게재: RISC-V 병목이 코어에서 시스템 소프트웨어로 이동 중 (10-24)

날짜: 2026-10-24 (게시)　출처: EE Times China: 엣지 AI가 RISC-V의 새로운 전장으로, RT-Thread 칼럼 페이지

RT-Thread의 EE Times China 칼럼에 10-24 서밋 참관기가 게재되었으며, 제목은 “엣지 AI가 RISC-V의 새로운 전장으로”라는 점에 초점을 맞췄습니다. 보도에 따르면 서밋 규모는 메인 포럼 1개, 병렬 분과 포럼 7개, Member Day 기술 세션으로 구성되었으며, 의제는 인공지능, 데이터센터 및 고성능 컴퓨팅, 소프트웨어 생태계, 임베디드 및 IoT, 칩 설계 및 검증, 자동차 전자 및 로보틱스를 아우릅니다.

RT-Thread와 직접 관련된 두 가지 표현이 있습니다. 서밋 기간 동안 RT-Thread는 다수의 RISC-V IP 및 칩 제조사와 커널 적응, 툴체인 연결, 공동 솔루션 구체화에 대해 의견을 교환했습니다. 업계는 RISC-V가 임베디드 및 IoT에서 규모화 조건을 갖추었으며 병목이 “코어”에서 시스템 소프트웨어로 이동하고 있다고 판단하며, 운영체제의 참여가 실시간성, 기능 안전 및 엔지니어링 납품이라는 고리를 보완한다고 보았습니다. 보도에서는 구체적인 발표 제목과 제품 출시를 상세히 다루지 않았고, 본문은 이미지 위주이므로 이번 호에서는 위에서 확인 가능한 표현만 취하고 세부 사항을 대신 구성하지 않습니다.

유의할 점은 서밋 본체가 10-18부터 10-20까지 선전에서 개최되었으며, 산업 측 칩 발표는 이전 몇 회차 RISC-V 데일리 리포트에서 이미 수록되었으므로, 이번 호에서는 시스템 소프트웨어 관점과 RT-Thread 관련 이 한 편만 보충하여 주제 간 중복을 피합니다.

3.2 GDR: RT-Thread 커널 객체 조회를 GDB로 이전, QEMU 폐쇄 루프가 3.1.x/4.0.x/4.1.x 커버 (10-25)

날짜: 2026-10-25 (게시)　출처: EE Times China: LoRaWAN 이식 삽질에서 출발하여, GDR 저장소

“디버깅 스캐폴딩”을 정식 엔지니어링으로 다루는 드문 커뮤니티 장문입니다. 출발점은 2년 전 Semtech의 LoRaWAN 프로토콜 스택 SWL2001을 Zephyr에서 자원이 제한된 국산 MCU로 이식한 것으로, 하부는 축소된 RT-Thread Nano입니다. 40여 개의 HAL 인터페이스를 하나씩 매핑했으며, 어떤 의미론적 편차든 런타임에서만 드러납니다. 진짜 어려움은 관측에 있었습니다. FinSH가 실행되면 radio planner의 타이밍이 교란되어 관측 행위가 피관측 시스템을 변화시킵니다. GDB는 기본적으로 포인터만 제공하므로, 세마포어 하나를 보려면 rt_object_container를 따라 연결 리스트를 순회하고 container_of 변환 후 cast해야 하며, 객체 열 개면 오륙십 개의 명령이 필요합니다.

GDR의 방식은 이런 기계적 노동을 GDB의 Python 명령으로 고정화하여 세 계층의 능력을 제공합니다. 집계 명령(rtthread threads/timers/system/semaphores/objects)은 전역 스냅샷을 출력하며, 스레드 테이블에는 스택 채움 패턴 기반의 피크 워터마크인 StkUsed와 MaxStkUsed 두 가지가 포함됩니다. 편의 함수 $gdr_thread("worker2")와 $gdr_object(...)는 네이티브 gdb.Value를 반환하며, 이후 필드 탐색은 여전히 GDB 표현식을 사용합니다. pretty-printer는 커널 객체를 한 줄 요약으로 축약하며, 예를 들어 뮤텍스는 소유자를 직접 표시합니다.

FinSH와의 본질적인 차이는 완전 무침투라는 점입니다. 모든 정보는 GDB로 심볼과 대상 메모리를 읽기만 하며, 펌웨어 내부의 어떤 함수도 호출하지 않습니다. 따라서 셸이 아예 없는 Nano 시나리오에도 적용할 수 있고, HardFault 이후 코드 실행이 불가능한 사후 분석에도 적용할 수 있습니다. 엔지니어링 측면에서 기억할 만한 몇 가지 결정이 있습니다. 더 이상 RTOS를 자동 탐지하지 않고(명시적으로 gdr init rtthread 4.0.5로 변경, 다만 SMP, 힙 관리자, IPC 컴포넌트 같은 구성 차이는 심볼 존재 여부로 탐지), 모든 레이아웃 지식을 하나의 파일에 모으고 COUPLED로 표기하며, QEMU로 실제 펌웨어를 부팅해 pytest 단언을 수행하고, CI 매트릭스가 Cortex-A9(3.1.0~3.1.5, 4.x)와 RV64(4.0.4~4.1.1)를 커버합니다. 저자는 경계도 명시했습니다. 본인은 더 이상 MCU 개발을 하지 않으며, 도구는 QEMU 매트릭스에서만 검증되었고 실제 보드에서는 아직 검증되지 않았습니다. 후속 계획은 agent skill, VSCode 플러그인, FreeRTOS 적응입니다.

3.3 커뮤니티 장문 2편: Env 도구 v2.0.3 사용자 지정 설치, 그리고 Studio의 24개 암시적 선언 경고 완전 추적 (10-25)

날짜: 2026-10-25 18:45~18:46 (게시)　출처: Env 도구 v2.0.3 사용 기록, Studio 24개 암시적 선언 경고 추적

커뮤니티 글 인터페이스에는 10-25 저녁 연속으로 툴체인 장문 두 편이 올라왔으며, 모두 “함정에 빠지고 수정하는” 유형입니다.

첫 번째 글은 Env 2.0.3의 사용자 지정 위치 설치를 다룹니다. Env는 v2.0부터 아키텍처를 대대적으로 재구성했습니다. 명령 진입점은 rt-env로 통일되었고, menuconfig／pkgs／scons는 그 하위 명령이 되었으며, 추가로 sdk, plugin, webui, system이 있습니다. 의존성은 전부 Python 가상 환경에서 실행됩니다. 새로운 플러그인 체계와 브라우저 측 WebUI가 추가되었습니다. 각 터미널은 먼저 활성화 스크립트를 dot-source해야 사용할 수 있습니다. 공식 설치 스크립트는 위치를 ~/.env로 고정하므로, 툴체인을 프로젝트 디렉터리에 넣으려면 디렉터리 구조를 수동으로 복제해야 합니다. 글에서는 전체 단계와 로컬에서 검증한 버전 조합(rt-env v2.0.3, SCons 4.11.1, kconfiglib 14.1.0, pyyaml 6.0.3)을 제공합니다. 또한 호환성 경계선도 명시했습니다. Env v2.0은 RT-Thread 5.1.0 이상 master 브랜치를 완전히 지원하며, 5.1.0 및 그 이전 버전은 계속 v1.5.x를 사용합니다.

두 번째 글은 RT-Thread Studio 빌드 경고의 완전한 추적으로, 이번 호 메인라인 제안 #11930과 정확히 대응합니다. scons --dist-ide로 내보낸 프로젝트를 Studio에서 컴파일하면 다섯 개 커널 소스 파일에서 24개의 -Wimplicit-function-declaration 경고가 발생합니다(clock.c 1, ipc.c 7, thread.c 12, timer.c 1, scheduler_comm.c 3). 모두 rt_sched_* 계열 내부 스케줄링 API를 가리킵니다. 저자의 추적 경로는 다음과 같습니다. 먼저 두 빌드의 컴파일 명령줄을 비교해 scons에는 -D__RT_KERNEL_SOURCE__가 있고 Studio의 make에는 없음을 발견합니다. 다음으로 include/rtsched.h로 돌아가 매크로 가드를 찾습니다. 마지막으로 매크로가 LOCAL_CPPDEFINES를 통해 주입되는데, Studio 빌드 전 Eclipse 프로젝트 생성기가 전역 CPPDEFINES만 수집하고 LOCAL_CPPDEFINES는 생성된 rtconfig_preinc.h에 전혀 들어가지 않는다는 점을 확인합니다. 글에서는 특히 GCC 14부터 이 경고가 기본적으로 오류로 승격되므로, 새 툴체인을 사용하는 사람에게는 소음이 아니라 빌드 실패임을 상기시킵니다. 대응 제안 #11930은 단 1줄만 수정해 매크로를 Kernel 그룹의 전역 CPPDEFINES로 옮기며, msvc 브랜치의 방식과 일치시킵니다.

3.4 10-26 저녁 라이브: RT-Thread와 엣지 AI의 손 재활 외골격 (10-25)

날짜: 2026-10-25 (게시)　출처: EE Times China: 다음 주 월요일 저녁 8시

10-25에 게시된 라이브 예고: 10-26 20:00~21:00, 커뮤니티 개발자 Cui Junshuo가 손 재활 외골격 프로젝트를 공유합니다. 작품은 뇌졸중, 수부 외상 수술 후, 말초 신경 손상 환자의 손 기능 훈련을 대상으로 하며, 감지, 인식, 보조, 상호작용, 평가를 하나의 플랫폼으로 구성합니다. 두 가지 관전 포인트가 구체적으로 작성되었습니다. 근전도 신호에서 운동 의도로 이어지는 인식 체인, 그리고 하나의 개발 보드에서 듀얼 코어가 어떻게 분담 협력하는지입니다.

주제를 보면 이 항목은 이번 호 3.5의 엣지 Agent 작품, 4.2의 ai/Agent 패키지 업데이트와 같은 방향입니다. RT-Thread 측 커뮤니티 콘텐츠는 “점등과 네트워킹”에서 “센싱 더하기 엣지 추론”의 완제품 솔루션으로 전환하고 있으며, 듀얼 코어 이기종과 실시간성 분담은 반복적으로 등장하는 구조입니다.

3.5 임베디드 대회 작품 3편: 엣지 Agent 다중 센서 융합, ART-Pi2 USB 열거 진단, OpenMV 용의자 추적 (10-24／10-25)

날짜: 2026-10-24 12:03 ~ 2026-10-25 10:39 (게시)　출처: 엣지 Agent 다중 센서 융합, ART-Pi2 USB 열거 진단기, OpenMV 용의자 추적

2026 임베디드 대회 작품이 모니터링 기간에 세 편 집중적으로 공개되었으며, 하드웨어와 소프트웨어 지향점이 각기 다르다.

엣지 Agent 편은 Infineon Edgi-Talk 보드(PSoC E84: Cortex-M55 + Ethos-U55 NPU, 별도 Cortex-M33 코프로세서, 온칩 최대 6 MB SRAM) 기반으로, 시스템은 분산 센서 수집, MQTT 집계, 엣지 다중 소스 융합, 지능형 인식 의사결정 및 LVGL 대시보드로 구성된다. 주목할 만한 구현 세부 사항은 agent 패키지가 MQTT의 구독, 구독 취소, 이력 조회를 “도구”로 캡슐화하여 agent 커널이 등록된 도구에 따라 스케줄링한다는 점이다. UI는 하나의 스레드와 타이머 그룹으로 구성되며, 800×480 논리 캔버스를 480×800 세로 화면에 그린 후 GPU로 회전시키고, 모든 페이지는 LVGL 스레드에서만 수정된다. Agent 커널의 프레임워크 문서는 저자 자신의 저장소를 가리킨다.

ART-Pi2 편은 USB 열거의 관측 가능성을 다룬다. CherryUSB의 호스트 어댑테이션 계층으로 제어 전송 시작과 완료 시 요청 파라미터, 반환 상태 및 디스크립터 바이트를 기록하고, 이벤트는 유계 큐에 들어가 RT-Thread 분석 스레드가 공유 C99 규칙 코어를 호출하여 판정을 생성한다. 규칙 결론은 출처 이벤트와 바이트 참조를 보존하며, 보드 측은 불변 증거 스냅샷을 게시하고 4.3인치 LCD와 LAN 웹 페이지가 이 세션을 중심으로 표시되어 규칙 결론에서 원시 바이트까지 역추적할 수 있다. 하드웨어는 ART-Pi2(STM32H7R7) + ALIENTEK 4.3인치 RGB 화면이며, Wi-Fi는 온보드 CYW43438이 제공한다.

세 번째 편은 RA8P1 Titan Mini + PC 호스트의 보행자 추적이다. 보드 측은 OpenMV 펌웨어로 YOLOv8n(192 입력, Ethos-U55 NPU)을 실행하고, USB CDC 사용자 정의 프로토콜을 통해 검출 결과와 비디오 스트림을 Python 호스트로 전송하며, 운영자가 화면을 한 번 클릭하면 대상이 고정되고 빨간 박스가 운동 예측과 함께 추적하며 녹화에 삽입된다. 실측 프레임레이트는 상세히 제시되었다: QVGA 검출 없음 약 25 fps, 검출 포함 16~19 fps, VGA 검출 포함 약 8 fps.

4. 생태계와 벤더 적응

4.1 TriCore(AURIX) Env SDK 진입: tricore-gcc 13.4.1과 qemu-tricore 두 패키지 병합, TC2xx／TC3xx／TC4xx 지원 (10-26)

날짜: 2026-10-26 00:10 및 07:57 (병합 시간)　출처: RT-Thread/sdk PR #9, RT-Thread/sdk PR #10, toolchains-ci v1.12, toolchains-ci v1.13

이번 호의 가장 실질적인 성과는 메인 저장소가 아닌 Env의 SDK 저장소에서 나왔다. 두 PR이 연이어 병합되어 Infineon TriCore(AURIX)라는 차량용 아키텍처의 컴파일 및 시뮬레이션 경로를 RT-Thread 도구 체인 체계에 보강했다.

첫 번째는 tricore-gcc 도구 체인 패키지로, 4개 파일 +112, Linux와 Windows 각각 한 세트의 Kconfig와 package.json, 패키지명 tricore-gcc, 버전 v13.4.1, 스위치 PKG_USING_TRICORE_GCC이다. 도구 체인 업스트림은 NoMore201/tricore-gcc-toolchain(EEESlab 11.3.0의 다운스트림, CI 자동 빌드 포함)이며, 구성은 GCC 13.4.1, binutils 2.40, newlib, GDB 14.0, 대상 트리플 tricore-elf, TriCore 1.3／1.3.1／1.6／1.6.1／1.6.2／1.8 지원으로 TC2xx, TC3xx, TC4xx 3세대 칩에 대응한다. 릴리스물은 toolchains-ci의 v1.12에 배치되었다: Linux 패키지 251 MB, Windows 패키지 466 MB. Windows 패키지는 업스트림에서 누락된 libwinpthread-1.dll을 보충했으며(bin/와 libexec/gcc/tricore-elf/13.4.1/ 양쪽에 배치), 그렇지 않으면 MSYS2가 설치되지 않은 머신에서 컴파일러가 기동되지 않는다.

두 번째는 qemu-tricore 에뮬레이터 패키지로, 마찬가지로 4개 파일 +112이며, 스위치 PKG_USING_QEMU_TRICORE, 버전 v1.0.0, 릴리스 산출물은 toolchains-ci의 v1.13(Linux 5.4 MB, Windows 9.4 MB)에 있습니다. 배경은 명확하게 기술되어 있습니다: tricore-gcc 패키지에 포함된 QEMU 9.2.3은 KIT_AURIX_TC277_TRB(TC2xx)와 tricore_testboard 두 머신만 있어 TC3/TC4를 시뮬레이션할 수 없으므로, Zephyr 측에서 사용 중인 브랜치를 별도로 도입한 것입니다. 소스는 linumiz/qemu-tricore의 release/ifx/tricore-1.0 브랜치(tag v1.0.0, QEMU 10.2.94)이며, 지원하는 세 머신은 KIT_AURIX_TC277_TRB, KIT_AURIX_TC397B_TRB, KIT_A3G_TC4D7_LITE이고 CPU 모델은 tc2x/tc3x/tc4x입니다. 외부 장치는 ASCLIN0 시리얼, STM 시스템 타이머, IR 인터럽트 라우팅, SCU와 클럭, SFR 브리지, 온칩 RAM과 Flash 매핑만 구현되었고 CAN, 이더넷, ADC, GPIO, DMA는 모두 없습니다—커널과 시리얼 shell을 실행하기에는 충분하지만 외부 장치 드라이버 검증에는 부족합니다. Windows 크로스 컴파일을 지원하기 위해 TriCore 측에서는 이식성 문제 두 곳을 수정했습니다(ENOTBLK/O_* 조건부 컴파일과 hwaddr 로그 형식).

두 가지는 반드시 명확히 해야 합니다. 첫째, 이것은 단지 툴체인과 에뮬레이션이 먼저일 뿐입니다: 메인라인의 libcpu 디렉터리에는 현재 19개 아키텍처(aarch64, arc, arm, avr32, blackfin, c-sky, ia32, m16c, mips, nios, ppc, risc-v, rx, sim, sparc-v8, ti-dsp, unicore32, v850, xilinx)가 있으며, tricore는 없고, bsp 아래에도 AURIX 보드 레벨 디렉터리가 없습니다. 저장소에서 확인할 수 있는 TriCore 기록은 2020년 전후의 몇 차례 시도(#4311 아키텍처 적응, #4488과 #4527의 TASKING 툴체인 및 FinSH 지원)이며, 상태는 모두 Closed로 메인라인에 병합되지 않았습니다. 둘째, 두 제안의 Windows 패키지는 모두 PE 가져오기 테이블 검사만 수행했고 Windows 실기에서 실행하지 않았으며, 작성자 스스로 PR에서 병합 전에 컴파일을 한 번 더 실행할 것을 권고했습니다.

이 두 가지를 종합해 보면, 의의는 노선의 변화에 있습니다: 초기의 TriCore 적응은 TASKING 상용 툴체인에 의존해 진입 장벽이 높았고 커뮤니티에 들어가기 어려웠습니다. 이번에는 오픈소스 GCC 13.4.1과 QEMU 에뮬레이션으로 전환하여 먼저 “컴파일 가능, 실행 가능, 디버깅 가능”을 해결했으며, BSP와 드라이버는 나중의 일입니다. 차량 규격 시나리오(도메인 컨트롤러, 안전 아일랜드, AURIX TC3xx/TC4xx가 이 분야의 주력)에서 이것은 필요하지만 충분하지 않은 한 걸음입니다.

4.2 ai/Agent 패키지에 음성 전사 엔드포인트 추가, 기본 백엔드가 SiliconFlow에서 DeepSeek 공식 API로 전환(10-23)

날짜: 2026-10-23 10:12(병합 시간)　출처: RT-Thread-packages PR #2046

소프트웨어 패키지 인덱스의 ai/Agent 패키지가 모니터링 기간 내에 Kconfig를 업데이트했으며, +32/-4로 파일 하나만 변경했지만 두 곳의 기본값 변경은 기록할 만합니다. 모델 이름 기본값이 deepseek-ai/DeepSeek-V4-Pro에서 deepseek-flash로 변경되었고, 인터페이스 주소 기본값이 서드파티 집계 플랫폼의 api.siliconflow.cn에서 DeepSeek 공식 엔드포인트 api.deepseek.com으로 변경되었습니다(두 경로 모두 chat/completions로 동일)—즉, 기본 경로가 집계 플랫폼에서 원제조사 엔드포인트로 바뀐 것입니다.

새로 추가된 것은 음성 전사 설정 블록입니다: 스위치 옵션 하나(PKG_AGENT_STT_ENABLE/DISABLE, 기본 켜짐)와 STT File Server 문자열 하나로, 의미는 HTTP 파일 업로드 엔드포인트이며 예시는 로컬 주소에 /stt 경로를 붙인 형태입니다. 멀티모달 스위치의 설명 텍스트도 “이미지/파일”에서 “이미지/파일/오디오”로 확장되어 STT 설정과 대응합니다.

이 항목은 이번 호 3.5의 온디바이스 Agent 대회 작품과 대조해 읽을 수 있습니다: 작품에서는 agent 패키지가 MQTT 작업을 도구로 등록해 커널이 스케줄링하도록 하며, 인용된 Agent 프레임워크 저장소와 이번 제안의 작성자는 동일한 GitHub 계정에 속합니다. 한 편은 사용법을 설명하고, 한 건은 설정을 변경하며, 같은 사용 방식을 가리킵니다—RTOS를 agent의 런타임으로 삼아 모델이 “도구”를 통해 장치 기능을 조작하도록 하는 것입니다. 기본 백엔드가 공식 API로 전환된 후에는 즉시 사용 가능한 진입 장벽이 다소 낮아지지만, 대가는 네트워크 의존성을 단일 공급자에 묶는 것이며, 이 점은 리소스 제약 시나리오에서 스스로 저울질해야 합니다.

4.3 Allwinner F101과 H616의 BSP 제안 172개 파일, ESP32-S3-DevKitM-1도 보드 레벨 지원 완비(10-24/10-26)

날짜: 2026-10-24 03:32 및 2026-10-26 02:05 (최종 업데이트)　출처: PR #11877, PR #11844, PR #11903

이번 모니터링 기간의 BSP 측은 제안이 주를 이루며, 규모가 가장 큰 것은 Allwinner 계열(#11877)로 172개 파일 +35428/-6이며, F101 YuzukiNeko와 H616 두 플랫폼을 한 번에 포함한다. F101 측에는 Sun252i의 디바이스 모델 드라이버 세트가 추가되었다: 클록, 리셋, pinctrl, DMA, SDIO, SPI, USB, 오디오, 온도, RTC, PWM, ADC, NVMEM, 워치독, DVFS, G2D 및 JPEG; 디스플레이 측에는 Sunxi DE0/TCON0 백엔드가 새로 추가되어 RGB, LVDS 및 MIPI-DSI를 지원하며, ST77916 QSPI 스크린의 보드 레벨 설정과 검증 명령도 제공한다; 또한 CherryUSB 하에서의 Sunxi MUSB 글루 레이어와 공유 드라이버 프레임워크 수정 사항(전원 도메인, DVFS, 그래픽, UART 리셋과 레지스터 시프트, QSPI 설정, 온도 워크큐, 입력 캡처, 디바이스 모델 USB 통합)이 추가되었다. H616 측은 또 다른 드라이버 세트이다: CCU/리셋, pinctrl, 온도, CPU DVFS, codec, AHUB HDMI 오디오, CE 하드웨어 암호화, DE33 HDMI framebuffer, TCON TOP, 그리고 RTC, DMA, SDIO, I2C, SPI, PWM, 워치독, IR, SID NVMEM, GPIO LED, JPEG 디코딩, G2D, GPADC, LRADC가 포함되며, AXP313A 전압 조정기 지원도 새로 추가되었다.

또 다른 건은 ESP32-S3-DevKitM-1(#11844)로 52개 파일 +7152/-29이다. 이 건은 커널을 명확히 구분해야 한다: ESP32-S3는 Xtensa이며 RISC-V에 속하지 않는다(C3/C6가 해당). 제안에는 몇 가지 실무 세부 사항이 기술되어 있다: builtin_imgs의 bootloader와 파티션 테이블은 반드시 S3용을 사용해야 하며 C3용으로 교체할 수 없고, Flash는 DIO, 8 MB, 80 MHz이며, 애플리케이션은 0x10000에 위치한다; 보드 레벨 공유 변경은 세 군데다(SoC를 choice에 포함하되 기본값은 여전히 C3, S3의 틱 인터럽트는 tick만 추가, sdkconfig.h는 sdkconfig_s3.h를 포함하도록 전환). 보드 검증은 완료되었다: msh 진입 가능, help/version/ps/free 응답 있음, 버전은 5.3.1 보고, free는 total 76704, used 12192, available 64512 표시, ps에서 timer와 main의 error 열은 EINTRPT이지만 shell과 틱은 정상. GPIO, I2C, SPI, ADC, PWM, Wi-Fi, BLE 및 온칩 8 MB PSRAM은 모두 보드 검증되지 않았으며, README에 지원 예정으로 표기되어 있다.

또 하나의 작은 건은 D1s의 QEMU 시작 스크립트(#11903)로 4개 파일 +145이며, allwinner d1s BSP에 qemu-d1s.sh와 문서를 추가하여 이 BSP가 d1s 머신에서 직접 실행될 수 있게 한다; 작성자는 스크립트와 문서가 AI 보조로 작성되었으며 수동 검토와 실측을 거쳤다고 명시했다.

4.4 드라이버와 CI: OSPI 옥타 플래시, I2C 제어 트랜잭션 직렬화, STM32 패키지 테스트 동시성 잠금 (10-23/10-25)

날짜: 2026-10-23 ~ 2026-10-25 (업데이트 및 병합 시각)　출처: PR #11912, PR #11820, pkgs-test PR #37

드라이버 계층에서 가장 큰 건은 OSPI와 OctaFlash 지원(#11912)으로 32개 파일이다. 이전에 RT-Thread의 SPI 드라이버 계층에는 네이티브 OSPI 경로가 없어 옥타 플래시는 우회해야 했다. 변경 사항은 components 계층에 OSPI의 버스, 디바이스, 설정 및 메시지 정의를 추가하고, 전송 보조 함수와 빌드 옵션을 추가하며, 기존 SPI와 QSPI 경로를 유지한다; OSPI 전송과 탐지를 SFUD에 연결하여 읽기, 쓰기, 지우기 및 상태/제어 작업을 지원하고, SFUD 디바이스 테이블에 MX25LM51245G를 추가하여 검증에 사용한다; 전체 경로가 하드웨어에서 동작할 수 있도록 범용 STM32 OctoSPI 드라이버와 stm32l4r9-st-eval의 보드 레벨 OSPI Flash 지원을 추가하여 SFUD가 1-1-1과 8-8-8(OPI STR/DTR) 두 모드로 접근할 수 있게 한다.

I2C 건(#11820)은 버스 제어와 전송의 경쟁 조건을 수정한 것입니다. rt_i2c_control()이 rt_i2c_transfer()가 버스를 사용하는 동안, 특히 SET_MAX_HZ에서 컨트롤러 설정을 변경할 수 있었습니다. 수정 방식은 제어 명령이 동일한 버스 뮤텍스를 획득하고 통합된 출구에서 해제되도록 하며, API 문서에 제어에 스레드 컨텍스트가 필요하다는 점을 명시하는 것입니다. 검증에는 호스트 측 pthread 뮤텍스 어댑터를 사용해 동시 전송과 제어, 제어와 제어, 주파수 업데이트, 잠금 및 콜백 오류, 그리고 제어 내 중첩 전송을 커버했습니다. 패치되지 않은 소스는 동일한 회귀 집합에서 실패했습니다.

CI 측 건은 pkgs-test(#37)에 있으며, 1개 파일 +11/-7로 설명이 매우 완전합니다. STM32 소프트웨어 패키지 테스트는 여러 버전을 병렬로 실행하며, 각 작업은 독립적인 BSP 복사본을 가지지만 여전히 bsp/stm32/libraries 아래의 HAL/CMSIS 드라이버 디렉터리를 공유합니다. 기존의 sem_stm32는 컴파일만 보호하고 의존성 업데이트는 보호하지 않아, 한 작업이 다른 작업의 의존성 클론이 완료되지 않은 상태에서 동일 디렉터리에 git pull을 수행하면 Git이 추적되지 않은 파일이 덮어쓰여질 것이라고 보고 중단하며, 실패는 다시 프레임워크에 의해 일괄적으로 compile failure로 보고되었습니다. 지난 호에 합입된 #11870 테스트가 바로 이 문제로 실패했습니다(실패 로그 확인 가능). 수정 방식은 잠금을 __build()로 상향 이동시켜 의존성 업데이트와 컴파일이 동일한 임계 구역에 있도록 하고, 동시에 __build_scons() 내의 중복 잠금을 제거해 자기 교착을 방지하며, try/finally로 예외 시 해제를 보장하는 것입니다.

5. 요약 및 트렌드 관찰

5.1 이번 호 트렌드

  • 차량 규격 아키텍처는 「툴체인 선행」: TriCore/AURIX는 이번에 메인 저장소가 아닌 Env SDK에 들어갔습니다. 오픈소스 GCC 13.4.1과 qemu-tricore 두 패키지가 먼저 컴파일과 시뮬레이션을 보완했으며, 메인라인 libcpu에는 여전히 tricore 포팅이 없고 bsp 아래에도 AURIX 보드 레벨 디렉터리가 없습니다. 2020년 전후 TASKING 상용 툴체인에 의존했던 시도들(모두 Closed로 종결)과 비교하면 이번 경로가 실현 가능성이 더 높지만, 「보드에 올릴 수 있는」 단계까지는 아직 BSP와 드라이버가 필요합니다.
  • 메인라인은 극히 조용하고 제안 면은 극히 활발: 72시간 동안 master에는 단 2건의 커밋만 있었지만, 모니터링 기간 내 25건의 PR이 업데이트되었고 6건이 합입되었습니다(메인 저장소 2, sdk 2, packages 1, pkgs-test 1). 합입 동작은 금요일 저녁과 일요일 저녁에 집중되었으며, 리뷰는 멈추지 않았고 개발 측은 실제로 마무리 중입니다.
  • 결함 연구가 단일 지점에서 서브시스템으로 전환: 시간 서브시스템에 하룻밤 사이 4건(3개 결함 + A부터 F까지 작업 항목이 포함된 조사 1건)이 올라왔고, 두 건의 수정 제안이 다음 날 제출되어 「보고—분석—수정」의 짧은 폐루프를 형성했습니다. lwp의 sys_poll 랩어라운드는 32비트 RT-Smart가 사용자 상태에서 제어 가능한 카운터의 정수 경계 문제를 별도로 나열했으며, 지난 호의 「디바이스 또는 서버 측 메타데이터를 길이로 사용」하는 결함군과 상호 보완적이어서 커널이 여전히 역사적 부채를 지불하고 있음을 보여줍니다(ecf2d821은 2022년까지 거슬러 올라갈 수 있음).
  • 빌드를 통과 조건으로 하는 합입이 CI에 역습당하기 시작: 지난 호 ESP-IDF v6.1 적응 합입 이틀 후, master에서 C3/C6 빌드가 빨갛게 변해 모든 PR의 정적 빌드 검사를 파급했습니다. 수정 제안은 당일 개설되었습니다. 이 사슬 자체는 건강하지만, 「로컬 미컴파일, CI 검증」이라는 기준에는 순서 안정성 보장이 뒷받침되어야 함도 보여줍니다.
  • 엣지 AI의 착점이 모델 실행에서 도구 연결로 전환: ai/Agent 패키지에 STT 업로드 엔드포인트 추가, 기본 백엔드를 DeepSeek 공식 API로 교체, 커뮤니티 대회 작품이 agent 패키지로 MQTT 조작을 도구로 등록해 커널 스케줄링에 제공, 그리고 10-26 저녁의 「듀얼코어 + 근전도 의도」 라이브 방송까지 방향이 일치합니다. RTOS는 agent의 런타임으로 간주되고 있으며, 실시간성과 이기종 분업이 범용 Linux 대비 강점입니다.

5.2 한계 및 중복 제거 설명

  • 이번 호는 72시간 모니터링 기간(10-23 08:00 ~ 10-26 08:00, 베이징 시간)으로 월요일이며 토요일과 일요일을 포함하고, 이전 호(10-22 08:00 ~ 10-23 08:00, 24시간)와 연결되며 중복은 없습니다.
  • 이전 호와의 중복 제거: #11920, #11918, #11910, #11915는 이전 호에 이미 수록되었으므로 이번 호에서는 상태가 실제로 갱신된 경우에만 일괄 정리하고 결함 메커니즘은 반복 서술하지 않습니다. #11870은 이전 호에 「차단 해제, 보드 검증 대기」로 수록되었으므로 이번 호에서는 master에서 발생시킨 빌드 회귀와 새 수정 제안만 기술합니다. #11896, #11894는 이전 호에 기록이 있으므로 이번 호에서는 최신 상태와 변경 세부 사항을 보충합니다.
  • 익명 GitHub API 할당량이 수집 도중 소진되어 이후에는 웹 페이지 확인과 기존 검색 결과를 기준으로 했으며, 조직 수준 전체 푸시 검증은 수행하지 않았습니다. sort=pushed 상위 100개 저장소 중 모니터링 기간 내 푸시가 있는 저장소는 5개(sdk, toolchains-ci, rt-thread, pkgs-test, packages)로 나타났습니다.
  • 공식 뉴스 API는 여전히 2026-06-17에 멈춰 있으며(이번 반환 5건), 공식 사이트 뉴스 목록 페이지는 프런트엔드 렌더링 방식이라 스크래핑 시 빈 껍데기만 얻을 수 있습니다. 커뮤니티 기사 API는 이번 기간 신규 5편이 추가되었으며 모두 제목과 갱신 시간을 확인했습니다.
  • 업계 미디어 측면에서 EE Times China의 RT-Thread 칼럼은 모니터링 기간 내 총 4편입니다: 10-24 서밋 기사, 10-25의 GDR 및 외골격 라이브 방송, 그리고 10-23의 CherryUSB HID 튜토리얼입니다. 마지막 편은 게시 시간이 모니터링 기간 시작점에 가깝고 튜토리얼류에 속하므로 이번 호에 별도 항목으로 싣지 않았습니다. 검색 시 같은 칼럼의 a422289는 2025년 제5회 서밋 구 기사로 제목이 비슷해 혼동하기 쉬우므로, 이번 호는 칼럼 페이지의 10-24 a533499를 기준으로 합니다.
  • topic:rt-thread 생태계 검색에서 모니터링 기간 내 푸시가 있는 저장소는 2개입니다: sejtam-dev/AKP05E-Open-Firmware(ArtInChip D13x, RISC-V, RT-Thread 기반 서드파티 오픈소스 펌웨어, 스타 0)와 zlgopen/awtk(범용 임베디드 GUI, 커밋이 RT-Thread와 특별한 연관 없음)이며, 모두 생태계 참고 자료로만 다루고 별도 항목으로 싣지 않았습니다.
  • 보드 검증 미수행: TriCore 두 패키지의 Windows 빌드는 PE 가져오기 테이블 검사만 수행했고, 시간 하위 시스템 3건은 소스 수준 격리 재현이며, OSPI 제안의 하드웨어 검증은 stm32l4r9-st-eval 기반입니다. 보고서의 관련 결론은 모두 출처 원문 서술에 따르며 외삽하지 않습니다.

부록: 출처 검증표

출처 검증 결과
RT-Thread 공식 뉴스 API(조직 분류) 신규 없음, 여전히 5건 반환, 최신은 06-17에 멈춤
공식 사이트 뉴스 목록 페이지 프런트엔드 동적 렌더링, 스크래핑 시 로딩 빈 껍데기만 획득
커뮤니티 기사 API(article) 모니터링 기간 내 신규 5편: Env v2.0.3 기록, Studio 24 경고 트러블슈팅, 임베디드 대회 작품 3편
GitHub 메인 저장소 commits 모니터링 기간 내 2건: #11859 clang-format 규칙, #11893 lwIP 루프백
GitHub 메인 저장소 PR 25건 갱신, 2건 병합
GitHub 메인 저장소 Issue 신규 5건: #11922 ~ #11925 및 #11927, 시간 하위 시스템과 lwp에 집중
GitHub 메인 저장소 releases / tags 신규 릴리스 없음, 최신은 여전히 09-10의 v5.3.0
GitHub RT-Thread/sdk 2건 병합: tricore-gcc 및 qemu-tricore, toolchains-ci에서 v1.12, v1.13 릴리스
GitHub RT-Thread/packages 1건 병합: ai/Agent의 STT 설정 및 DeepSeek 기본 백엔드
GitHub RT-Thread/pkgs-test 1건 병합: STM32 패키지 테스트 동시성 잠금 수정
GitHub topic:rt-thread 2개 저장소 푸시, 모두 생태계 참고 자료로 미수록
Google News 집계(중영문, 프록시 경유) 중국어 7일 기간 유효 1건(EET-China 10-24 서밋 기사), 영어 0건
HN Algolia 네 개 후보 모두 threads 문자열 오매칭으로 제외
업계 미디어(EET-China 칼럼) 모니터링 기간 내 4편, 3편 수록, 10-23 튜토리얼 기사는 별도 미수록
메인라인 아키텍처 디렉터리 확인 libcpu에 현재 19개 아키텍처 존재, tricore 없음; 구 제안 #4311 상태는 Closed

전체 출처 목록

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

[47] PR #11820(I2C 제어 트랜잭션 직렬화) — https://github.com/RT-Thread/rt-thread/pull/11820