# 1. NuttX RTOS 연동 및 Kconfig 기반 하드웨어 설정 시스템

PX4-Autopilot의 심장 깊숙한 곳에는 소프트웨어(Application)와 쇳덩어리(Pixhawk Hardware) 사이의 위태로운 경계를 사수하는 마이크로커널(Microkernel) 실시간 운영체제, Apache NuttX RTOS가 존재한다. 리눅스 개발자에게 친숙한 POSIX 표준 인터페이스를 제공하면서도 단 수 밀리초(ms)의 정밀 기한을 칼같이 지켜야 하는 이 기계 심장과, 펌웨어 모듈들을 융통성 있게 엮어내는 설정 맵인 Kconfig 구조체의 치밀한 연동 관계를 해부한다.

NuttX RTOS 아키텍처: POSIX의 거울, 그러나 가차 없는 시간의 집행자
드론 비행 제어기 코드를 보면 open(), read(), write(), ioctl(), pthread_create() 등 우리에게 너무나 익숙한 리눅스/유닉스 계열 C 표준 함수들이 춤을 춘다. 백지상태의 칩셋 위에서 어떻게 이것이 가능한가? 그 속임수의 근원이 바로 NuttX다.
NuttX는 하드웨어 타이머와 인터럽트 레지스터를 장악한 채, 그 위에 두꺼운 유닉스 레이어(가상 파일 시스템 VFS 등) 가죽을 덮어씌웠다. I2C 센서를 읽을 때 레지스터 헥스(Hex) 값을 치는 것이 아니라 open("/dev/i2c-1", O_RDONLY) 통로를 여는 방식으로 PX4 드라이버 아키텍처는 극한의 추상화를 이룩했다. 하지만 이 평화 이면에는 피비린내 나는 선점 스케줄링(Preemptive Scheduling)이 도사린다.
NuttX 스케줄러는 자비가 없다. 고순위 우선권(Priority)을 부여받은 자이로(Gyro) 센서 인터럽트 쓰레드가 깨어나면, 지금 그 어떤 중요 연산(로깅, 텔레메트리, 계산)이 돌아가고 있든 즉석에서 CPU 컨텍스트(Context)를 잘라버리고 빼앗아 최단 지연(Low Latency) 속도로 자세 값을 찍어 올려 보낸다. 이것이 RTOS(실시간 운영체제)의 존재 이유다.

Kconfig의 폭정: 보드 형상의 융통성 기반 구조
수백 종의 센서와 마더보드가 혼재하는 생태계에서, 코드를 일일이 주석 처리하며 하드웨어 종류를 분기하는 것은 자살행위다. PX4와 NuttX는 리눅스 커널 빌드에서 차용해 온 Kconfig 매핑 프레임워크를 절대 권력으로 사용한다.

소스코드 디렉토리 곳곳에 심어진 Kconfig 파일들은 마치 이 거대한 함선의 배전반(Switchboard)과 같다. 개발자가 make px4_fmu-vX_default menuconfig (또는 boardconfig) 명령어를 치우면, MS-DOS 시절을 방상케 하는 파란 텍스트 UI 화면이 터미널에 팝업된다.
여기서 개발자는 스페이스바 하나로

• [ ] Ublox GPS 드라이버를 탑재할 것인지 제거할 것인지
• [ ] PWM 출력 핀 개수를 8개로 할지 14개로 할지
• [ ] USB 콘솔 통신을 살릴 것인지

강제로 ON/OFF 시킬 수 있다. 이 선택의 결과는 .config 텍스트 매크로 파일에 일괄 기록되며, 빌드 메타 엔진(CMake)이 이 텍스트 파일을 읽어 들여 수천만 줄 코드 중 필요 없는 기능 덩어리들을 컴파일 단계에서 전기톱으로 도려내 버린다. 이 Kconfig 아키텍처 덕분에 1MB짜리 플래시를 가진 빈약한 하드웨어부터 2MB를 가진 고급 하드웨어까지 하나의 메인 소스 베이스(Single Codebase)로 수백 개의 다중 자아(Mutliple Targets)를 자유자재로 찍어낼 수 있는 것이다.