Apache NuttX 분석 — POSIX·PX4·NASA Ingenuity

#한 줄 요약

“NuttX는 MCU에 올라가는 미니 Unix입니다.” — pthread·socket·VFS가 모두 표준 POSIX이며, PX4와 NASA Ingenuity가 같은 이유로 선택했습니다.

#어떤 문제를 푸는가

대부분의 RTOS는 자체 API를 가집니다. FreeRTOS의 xQueueSend, ThreadX의 tx_queue_send, Zephyr의 k_msgq_put은 모두 비슷한 일을 하지만 시그니처가 다릅니다. 이 비표준성은 Linux에서 작성한 코드 재활용과 교차 RTOS 이식을 비싼 작업으로 만듭니다.

NuttX는 다른 길을 택했습니다. 처음부터 POSIX 1003.1을 따라가는 RTOS입니다. pthread_create, open, socket, signal이 표준 시그니처 그대로 동작합니다. Linux 코드를 거의 그대로 옮길 수 있고, application 엔지니어가 RTOS API를 새로 배울 필요가 거의 없습니다.

이번 편은 두 가지를 봅니다. 첫째, NuttX의 빌드 모드 세 가지(Flat·Protected·Kernel)와 그 의미입니다. 둘째, PX4와 NASA Ingenuity가 NuttX를 채택한 기술적 근거를 따라가며 임베디드 POSIX RTOS의 가치를 짚습니다.

저장소는 github.com/apache/nuttx, 라이선스는 Apache 2.0입니다.

#역사

채택 사례

• PX4 Autopilot — 드론·UAV 표준 flight stack
• NASA Ingenuity Mars Helicopter — 2021년 첫 화성 비행
• Sony Spresense — Cortex-M4F 6-core 보드
• Xiaomi Vela — 스마트홈 IoT (수억 대)
• Espressif ESP32 — ESP-IDF 대안

특히 NASA Ingenuity는 지구 밖 첫 동력 비행을 NuttX 위에서 수행했고, 50+ 비행을 무사고로 완수해 space-grade validation을 사실상 받은 RTOS입니다.

#저장소 구조

1
nuttx/
2
├── sched/               # 스케줄러·task·thread·signal·pthread
3
├── fs/                  # VFS·FAT·NFS·SmartFS·ROMFS·BinFS
4
├── net/                 # TCP·UDP·ICMP·IPv6·DHCP·DNS
5
├── drivers/             # 캐릭터·블록·sensor·usbhost·lcd
6
├── arch/                # 아키텍처 (ARM·RISC-V·Xtensa·x86)
7
├── boards/              # 보드 정의
8
├── libs/                # libc·libxx·기타
9
├── include/
10
└── apps/                # 별도 저장소 (apache/nuttx-apps)

크기는 ~100K LoC로 FreeRTOS(~20K)와 Zephyr(~50K) 사이입니다. 다만 POSIX 호환을 위한 인프라가 차지하는 비중이 커서 단순한 코어보다 무겁게 느껴질 수 있습니다.

#POSIX 호환

1
#include <pthread.h>
2
#include <unistd.h>
3
#include <fcntl.h>
4
#include <signal.h>
5

6
pthread_t tid;
7
pthread_create(&tid, NULL, thread_func, NULL);
8
pthread_join(tid, NULL);
9

10
int fd = open("/dev/ttyS0", O_RDWR);
11
write(fd, data, len);
12
close(fd);
13

14
struct sigaction sa = { .sa_handler = on_signal };
15
sigaction(SIGINT, &sa, NULL);

Linux용 코드 거의 그대로입니다. 이 호환성이 PX4 같은 대규모 항공 코드베이스가 NuttX를 선택한 결정적 이유입니다. 같은 코드가 Linux 시뮬레이션 환경과 실 비행 보드에서 동일하게 컴파일됩니다.

#Task vs Thread vs Process

1
/* Task — Linux process에 가까움 */
2
task_create("name", priority, stack_size, entry, argv);
3

4
/* pthread — Linux thread */
5
pthread_create(&tid, &attr, func, arg);
6

7
/* Process — 부모-자식 hierarchy (Protected/Kernel 빌드) */
8
task_spawn(...);

Task와 process는 별도 address space를 가질 수 있습니다(MMU/MPU 활성 시). thread는 같은 task 안의 실행 흐름입니다. 이 분리가 Linux와 같은 방식으로 동작하므로 권한 분리가 자연스럽게 표현됩니다.

#세 가지 빌드 모드

NuttX의 가장 독특한 점입니다. 빌드 모드를 세 가지로 선택할 수 있고, 각각 다른 격리 모델을 가집니다.

Flat build (기본)

• kernel + application 같은 address space
• FreeRTOS·Zephyr 일반 빌드와 비슷
• MPU/MMU 없는 소형 MCU에 적합

Protected build (MPU)

• kernel과 user 영역을 MPU로 분리
• syscall 경유 호출
• Cortex-M MPU 시스템에 적합

Kernel build (MMU)

• full process·user mode
• fork·exec·shared library 가능
• Linux-like 동작
• Cortex-A·RISC-V S-mode에 적합

같은 application 코드가 세 모드 모두에서 동작하도록 설계되어 있습니다. 작은 MCU에서 prototyping한 코드를 Cortex-A 보드에서 권한 분리가 적용된 채로 그대로 돌릴 수 있습니다.

#VFS — 표준 파일 시스템

1
mkdir("/data", 0777);
2
DIR *dir = opendir("/data");
3
struct dirent *e;
4
while ((e = readdir(dir)) != NULL) {
5
    printf("name: %s\n", e->d_name);
6
}
7
closedir(dir);

VFS 위에 FAT, SmartFS, ROMFS, NFS, BinFS 등이 모두 마운트됩니다. SD 카드, SPI flash, USB mass storage가 같은 POSIX API 뒤에 숨습니다.

#/proc 호환 procfs

1
FILE *fp = fopen("/proc/uptime", "r");
2
char buf[64];
3
fgets(buf, sizeof(buf), fp);
4
fclose(fp);

Linux /proc과 호환되는 구조가 제공됩니다. /proc/meminfo, /proc/version, /proc/<pid>/status 같은 친숙한 경로가 동일하게 동작하므로 디버깅과 모니터링 코드를 그대로 가져올 수 있습니다.

#네트워크 — POSIX Socket

1
int sock = socket(AF_INET, SOCK_STREAM, 0);
2
struct sockaddr_in addr = { .sin_family = AF_INET };
3
inet_pton(AF_INET, "192.168.1.100", &addr.sin_addr);
4
addr.sin_port = htons(80);
5

6
connect(sock, (struct sockaddr*)&addr, sizeof(addr));
7
send(sock, request, sizeof(request), 0);
8
recv(sock, buffer, sizeof(buffer), 0);
9
close(sock);

내장 IPv4/IPv6, TCP/UDP, ICMP, DHCP, DNS, 6LoWPAN, 802.11 지원이 표준 socket API로 노출됩니다. Linux 네트워크 코드 재활용이 자연스럽습니다.

#NSH — NuttShell

1
nsh> ls /
2
.    ..   dev  proc  data
3

4
nsh> cat /proc/uptime
5
0:23:14
6

7
nsh> ps
8
   PID GROUP PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK  STACK COMMAND
9
     0     0   0 FIFO     Kthread N-- Ready              0000000  1024 Idle Task
10
     1     1 100 RR       Task    --- Running            0000000  2048 init
11

12
nsh> free
13
                   total       used       free    largest
14
       Mem:       262144      40960     221184     221184
15

16
nsh> ifconfig
17
eth0    Link encap:Ethernet HWaddr 00:e0:de:ad:be:ef
18
        inet addr:192.168.1.42 Mask:255.255.255.0
19

20
nsh> ping 8.8.8.8
21
nsh> echo "Hello" > /dev/console

Linux shell과 거의 같은 사용감입니다. 디버깅 시 시스템 상태를 인터랙티브하게 점검할 수 있어 임베디드 개발 효율이 크게 올라갑니다.

#PX4 — 드론 표준 flight stack

PX4 Autopilot

• open-source flight stack (BSD)
• NuttX 기반 (Cortex-M7·H7·F7)
• 1 kHz 제어 루프
• IMU·GPS·기압계·자력계 sensor fusion
• EKF 기반 자세 추정
• MAVLink 프로토콜
• mission planning

채택

• Skydio, Auterion, Quanergy 등 상업 드론
• 학계·hobbyist 표준
• DJI 생태계의 open 대안

PX4가 NuttX를 선택한 핵심 이유는 POSIX 호환성입니다. 같은 application 코드가 *Linux 시뮬레이션 환경(SITL)*과 실 비행 컨트롤러에서 동일하게 동작합니다. 개발과 테스트 사이클이 짧아집니다.

#NASA Mars Ingenuity

• 2021-04 — 첫 화성 비행 (“Wright Brothers moment”)
• ~ 2024 — 72회 비행 누적, 임무 종료

하드웨어

• Qualcomm Snapdragon 801 (Cortex-A53) — main vision computer
• Cortex-M chip — flight control (FCU)
• Linux + ROS — main OS
• NuttX — FCU의 RTOS

NASA의 채택 근거 (paper 인용)

“Apache NuttX is the RTOS chosen for the FCU because of its small footprint, real-time characteristics, and POSIX compliance.”

NASA가 든 세 가지 이유 — 작은 footprint, 결정적 실시간성, POSIX 호환 — 가 NuttX의 정체성을 그대로 요약합니다. 화성 표면에서 70회 이상 무사고로 작동한 사실이 임베디드 POSIX RTOS의 검증 사례로 남았습니다.

#micro-ROS 통합

1
#include <rcl/rcl.h>
2

3
rcl_node_t node = rcl_get_zero_initialized_node();
4
rcl_node_options_t opts = rcl_node_get_default_options();
5
rcl_node_init(&node, "my_node", "", &support, &opts);

micro-ROS는 ROS 2 노드를 RTOS 위에서 돌리는 클라이언트 라이브러리입니다. NuttX, Zephyr, FreeRTOS 위에서 동작하며, Linux ROS 2 노드와 같은 메시지·서비스 시스템에 참여할 수 있습니다. 자율 로봇과 드론에서 표준화가 진행 중입니다.

#Sony Spresense — 멀티코어 NuttX

Sony Spresense

• Cortex-M4F × 6 core
• NuttX 공식 RTOS
• GPS 내장
• Hi-Res audio
• Edge AI (DNNRT)

교육·취미·IoT prototype 시장에서 인기.

Spresense는 NuttX의 SMP 지원이 정식 활용되는 대표 보드입니다. 6-core 위에서 SMP NuttX가 affinity 기반 task 분배로 동작합니다.

#Xiaomi Vela — 가장 큰 NuttX 배포

Xiaomi Vela

• NuttX fork
• 스마트홈 IoT 디바이스
• 수억 대 디바이스 deployment
• 글로벌 출시 라인업

Vela는 현존하는 가장 큰 NuttX 사용자입니다. 작은 IoT 디바이스에서 Linux 호환 application 모델을 유지하면서도 MCU footprint에 맞춘 결과입니다.

#빌드

1
git clone https://github.com/apache/nuttx
2
git clone https://github.com/apache/nuttx-apps apps
3
cd nuttx
4

5
./tools/configure.sh stm32f4discovery:nsh
6
make menuconfig
7
make -j8
8

9
make flash

Linux 스타일 Makefile + KConfig입니다. Zephyr와 비슷한 빌드 경험이지만 west 같은 메타툴 없이 단순 git + make로 끝납니다.

#NuttX vs FreeRTOS vs Zephyr — 한 줄 비교

POSIX 호환이 핵심 가치이고, Linux 코드 자산이 큰 조직과 권한 분리가 중요한 시스템에서 NuttX의 가치가 두드러집니다.

#자주 보는 함정

경고 — POSIX 100% 가정

1
fork();          /* Flat/Protected 빌드에서는 없음 */
2
mmap(...);       /* MMU 없는 빌드에서 제한 */

POSIX 호환은 모드 의존적입니다. Kernel build(MMU)에서만 fork와 mmap 같은 기능이 완전해집니다. Flat build에서는 task_create나 task_spawn을 써야 합니다.

경고 — Linux 헤더 포함

1
#include <linux/...>     /* NuttX는 BSD/POSIX 스타일 */

NuttX는 POSIX 표준 헤더만 제공합니다. <linux/...>는 존재하지 않으며, GNU 확장도 제한적입니다. 표준 POSIX 시그니처에 머무는 것이 안전합니다.

경고 — ESP-IDF와 NuttX 혼동

Espressif ESP32 보드에는 두 가지 RTOS 옵션이 있습니다.

ESP-IDF 문서를 보면서 NuttX 코드를 작성하면 driver API와 timer 동작에서 차이로 막힙니다. 어느 RTOS를 사용할지 프로젝트 초기에 명확히 정해야 합니다.

경고 — 큰 RAM 가정

1
malloc(1024 * 1024);    /* 1 MB — Cortex-M flat에서는 거의 실패 */

POSIX API가 친숙하다 보니 Linux 감각으로 큰 메모리 alloc을 시도하는 실수가 잦습니다. NuttX는 임베디드 MCU의 RAM 한도를 그대로 가집니다.

#정리

• NuttX는 POSIX 1003.1을 처음부터 따라가는 임베디드 RTOS이며, Linux 코드 재활용이 가장 자연스럽습니다.
• Flat/Protected/Kernel 세 가지 빌드 모드로 MCU에서 Cortex-A까지 동일한 application을 다른 격리 모델에서 실행할 수 있습니다.
• VFS, POSIX socket, signal, /proc 호환 procfs가 Linux와 같은 디버그 경험을 제공합니다.
• PX4가 채택한 핵심 이유는 Linux SITL과 실 비행 컨트롤러의 코드 일치입니다.
• NASA Ingenuity가 화성에서 70회 이상 무사고로 비행해 space-grade validation을 사실상 확보했습니다.
• Sony Spresense, Xiaomi Vela 등 대규모 배포에서 검증되며, micro-ROS 통합으로 자율 로봇 영역에서도 자리잡고 있습니다.
• ESP32에서는 ESP-IDF와 NuttX가 서로 다른 선택지이므로 프로젝트 초기에 결정해야 합니다.
• POSIX 호환은 빌드 모드 의존적이므로 fork/mmap 같은 기능을 가정하기 전에 모드를 확인합니다.

다음 편은 5-07 PREEMPT_RT Linux에서 2024년 mainline에 합류한 real-time Linux를 RTOS와 비교합니다.

#관련 항목

• 5-02: Zephyr 커널 분석
• 5-04: RTOS 포팅 가이드
• 5-05: RTOS 선택 가이드
• 5-07: PREEMPT_RT Linux