Raspberry Pi 5 (AI) Peripheral 시험 #1 — 계획과 개발환경

 

보드 한 대로 GPIO·UART·SPI·I2C·PWM·카메라를 하나씩 시험하고, 그 과정을 자료로 남기는 연재를 시작합니다. 특이한 점은 개발–검증–정리–집필을 AI 에이전트로 자동화한다는 것입니다. 어디까지 자동화가 이루어 질지는 모르겠지만, 최대한 AI를 사용해서 해 보려고 합니다. 이번 1편에서는 전체 계획과 자동화 구조를 잡고, 파이에서 C로 개발하는 환경 구성까지 함께 정리합니다.

※ 정말 AI의 발달이 너무 무섭게 느껴지는 요즘 입니다. PC, Phone 등의 application 개발은 정말이지 사람보다 빠르고, 효율적인것 같습니다. 이제 임베디드 개발을 AI로 시험하면서 어디까지 가능할지 저도 무척 궁금 합니다.

1. 들어가며

임베디드 실습에서 제일 귀찮은 건 코드가 아니라 "이게 진짜 됐는지 확인하고, 그걸 기록으로 남기는 일"입니다. LED가 깜빡이는 걸 눈으로 보고, 로그를 캡처하고, 배선 사진을 찍고, 블로그로 정리하는 반복 노동이죠. 그래서 이번 시리즈는 목표를 두 개로 잡았습니다.

1. Raspberry Pi 5의 주요 peripheral을 제어가 쉬운 순서로 체계적으로 시험한다.
2. 그 개발·검증·정리·집필 과정을 AI 에이전트로 자동화한다.

2. 결론부터 말하면

검증이 개발보다 어렵습니다. AI 에이전트는 LED가 깜빡이는 걸 볼 수 없습니다. 그래서 이 프로젝트는 실습마다 기계가 읽을 수 있는 증거(machine-readable evidence)를 반드시 남깁니다. 시각으로만 보이는 것도 로그·되읽기·사진으로 근거를 만듭니다.

※ 사실 컴파일러에서 제공하는 많은 명령어를 AI가 직접 운영하면서 Register를 읽던지, 또는 직접 python으로 반대편 시뮬레이터를 작성해서 검증을 합니다.

 

진행 순서는 제어가 쉬운 것부터입니다. 독자가 따라오기 좋게 가장 직관적인 GPIO(LED·버튼) → UART로 시작합니다. 그리고 3편에서 만드는 UART Shell이 이 연재의 척추입니다. peripheral을 하나 시험할 때마다 shell에 명령어를 하나씩 붙여, 마지막엔 모든 peripheral을 한 곳에서 시험하는 통합 도구가 됩니다. 자동화는 개발·검증·안전·정리·집필 5개 에이전트로 구성합니다.

※ 에이전트로 연제를 진행하면서 수정, 보안해 나갈 예정 입니다. 최종 연제 이후에는 해당 에이엔트도 같이 공유 드리겠습니다.

3. 시험 대상 하드웨어

보드	Raspberry Pi 5 Model B Rev 1.1
SoC / CPU	Broadcom BCM2712 · Cortex-A76 쿼드코어 @ 2.4GHz (aarch64)
메모리	8GB LPDDR4X
OS	Ubuntu 24.04.4 LTS (커널 6.8.0-raspi)
저장장치	227GB microSD

스캔으로 확인한 현재 연결 상태는, 카메라 Module 3(imx708)가 이미 연결·정상(4608×2592)이고, 헤더 I2C 버스(i2c-1)는 비어 있으며, GPIO 헤더 핀은 대부분 자유롭게 쓸 수 있는 상태입니다.

4. 파이에서 C 개발환경 구성

이 보드엔 이미 도구가 깔려 있지만, 새로 시작하는 분을 위해 맨바닥에서 재현하는 방법을 정리합니다. 이 시리즈는 파이용 리눅스 헤더(termios.h, gpiod.h 등)를 쓰므로 빌드는 반드시 파이에서 합니다.

4.1 툴체인 설치

# 컴파일러·make·헤더 한 번에 (gcc, g++, make, libc-dev 포함)
sudo apt update
sudo apt install -y build-essential gdb git

# peripheral 라이브러리
sudo apt install -y libgpiod-dev gpiod   # GPIO (libgpiod)
sudo apt install -y i2c-tools            # I2C 스캔/디버그

이 글을 쓰는 보드에 실제 설치된 버전은 다음과 같습니다.

도구	버전	용도
gcc	13.3.0	C 컴파일러 (Ubuntu 24.04 기본)
GNU Make	4.3	빌드 자동화
gdb	15.1	디버깅
libgpiod-dev	1.6.3	GPIO 제어 API
i2c-tools	4.3	i2cdetect 등
git	2.43.0	형상관리

4.2 인터페이스 활성화 (Ubuntu 기준)

Raspberry Pi OS와 달리 Ubuntu는 /boot/firmware/config.txt를 직접 편집해 켭니다. 이미 이렇게 설정돼 있습니다.

# /boot/firmware/config.txt
dtparam=i2c_arm=on      # I2C  (SDA=GPIO2, SCL=GPIO3)
dtparam=spi=on          # SPI  (spidev0.0 / 0.1)
enable_uart=1           # UART (/dev/ttyAMA0)
dtoverlay=imx708,cam0   # 카메라 모듈 3

매번 sudo 없이 쓰려면 사용자를 관련 그룹에 넣고 재로그인합니다. sudo usermod -aG gpio,i2c,spi,dialout $USER — 여기서 dialout은 UART(/dev/ttyAMA0) 접근용입니다.

4.3 Makefile 작성

peripheral마다 소스가 늘어나므로 처음부터 make로 관리합니다. 첫 편에서 쓰는 최소 형태입니다.

# Makefile  — 들여쓰기는 반드시 Tab
CC      = gcc
CFLAGS  = -Wall -Wextra -g -O2
LDFLAGS = -lgpiod            # GPIO 실습에서 링크
TARGET  = blink
SRCS    = blink.c
OBJS    = $(SRCS:.c=.o)

all: $(TARGET)
$(TARGET): $(OBJS)
	$(CC) $(OBJS) -o $@ $(LDFLAGS)
%.o: %.c
	$(CC) $(CFLAGS) -c $< -o $@
clean:
	rm -f $(OBJS) $(TARGET)
.PHONY: all clean

주의 — Makefile 들여쓰기를 스페이스로 넣으면 missing separator 오류가 납니다. 반드시 Tab이어야 합니다.

4.4 원격 빌드 흐름 (Windows → 파이)

코드는 Windows에서 편집하더라도(네트워크 공유로 파이 파일시스템 마운트), 컴파일은 SSH로 파이에서 실행합니다. Windows의 gcc에는 termios.h·gpiod가 없어 빌드가 되지 않습니다.

# 최초 1회: 비밀번호 없이 접속하도록 SSH 키 등록
ssh-keygen -t ed25519
ssh-copy-id kingdomy@192.168.0.82

# 이후 빌드·실행
ssh kingdomy@192.168.0.82 "cd ~/00_Task/control_c && make && ./blink"

4.5 설치 검증

이 시리즈의 방침대로, 환경 구성도 증거로 확인합니다.

gcc --version        # gcc (Ubuntu ...) 13.3.0
gpiodetect           # gpiochip0 ~ gpiochip4 나열
i2cdetect -y 1       # 헤더 I2C 버스 스캔
ls -l /dev/ttyAMA0   # UART 장치 존재 확인

참고로 Ubuntu 24.04은 libgpiod v1.6대입니다. 인터넷 예제 중 v1 API와 v2 API가 섞여 있으니, 헤더 버전에 맞춰 예제를 골라야 합니다. 이 시리즈는 설치된 v1.6.3 API로 통일합니다.

5. 검증 가능성으로 peripheral을 분류한다

peripheral 시험의 성패는 "AI가 스스로 통과/실패를 판정할 수 있는가"에 달려 있습니다. 이 기준으로 세 부류로 나눕니다.

검증 유형	예시	자동 검증
소프트웨어 루프백	UART TX→RX, SPI MOSI→MISO, GPIO 출력→입력	가능
센서 리드백	I2C 센서가 알려진 ID·값 반환	가능
시각·물리 전용	LED 점멸, 모터 회전, 부저	사람/카메라 필요

블로그는 독자 눈높이가 중요하니 가장 직관적인 LED·버튼으로 시작하지만, 시각 전용 실습이라도 검증을 놓지 않습니다. 버튼 입력은 소프트웨어가 되읽을 수 있고, LED 출력도 구동 핀을 다른 입력 핀에 연결(핀 루프백)하면 자동 판정이 됩니다. "쉬운 순서로 진행하되 증거는 항상 남긴다"가 이 시리즈의 방입니다.

6. 연재 계획 — 제어가 쉬운 순서로

독자가 따라오기 좋게 제어 난이도가 낮은 것부터 배치했습니다. 3편에서 만드는 UART shell은 이후 모든 편에서 계속 확장됩니다.

편	주제	핀(BCM)	검증
#2	GPIO 출력/입력 — LED·버튼	17 / 27	점퍼 루프백 (drive=read)
#3	UART 루프백	14 ↔ 15	TX→RX 바이트 일치
#4	UART Shell (통합 테스트 도구)	UART	명령 응답 검증
#5	SPI 통신	10·9·11·8	MOSI↔MISO 루프백
#6	I2C 센서 (ISM303/LSM303AGR)	2 / 3	칩 ID·측정값 범위
#7	PWM 서보·모터	12 / 13	계측 파형·듀티
#8	TCP 통신	network	소켓 에코
#9	PCM(I2S) 오디오	18·19·20·21	DOUT→DIN 루프백
#10	카메라 Module 3	CSI	해상도·밝기

UART Shell은 각 편에서 만든 기능을 shell 명령으로 노출합니다. 예를 들어 gpio 17 on, spi test, i2c scan, pwm 12 50 처럼요. 연재가 끝나면 이 shell 하나로 보드의 모든 peripheral을 대화식으로 시험할 수 있습니다.

 

 

그림 1. Raspberry Pi 5 40핀 헤더와 이번 시리즈에서 사용할 핀 (파란 테두리 = 사용 핀)

기능	BCM	물리	기능	BCM	물리
UART TXD	14	8	I2C SDA	2	3
UART RXD	15	10	I2C SCL	3	5
SPI MOSI	10	19	PWM0	12	32
SPI MISO	9	21	PWM1	13	33
SPI SCLK	11	23	LED (예)	17	11
SPI CE0	8	24	버튼 (예)	27	13
PCM CLK	18	12	PCM FS	19	35
PCM DIN	20	38	PCM DOUT	21	40

※ BCM은 Broadcom(브로드컴)의 약자예요. 라즈베리파이의 GPIO 핀 번호를 매기는 방식 중 하나를 가르킵니다. 라즈베리파이의 메인 칩(SoC)이 브로드컴사 제품이라, 그 칩이 정의한 GPIO 채널번호를 그대로 쓰는 방식을 BCM 번호라고 부릅니다. 위 그림의 17 / 27 이 바로 BCM 번호예요. 즉 "GPIO17", "GPIO27" 핀을 뜻합니다.

7. 자동화 구조 — 5개 에이전트

개발–검증–정리–집필의 반복 노동을 다음 에이전트들이 나눠 맡습니다.

에이전트	역할	핵심 산출물
개발	peripheral 시험 코드 작성·수정	.c / .py 소스
검증	실제 HW 실행 → 증거 수집 → PASS/FAIL 판정	로그·측정값
안전 게이트	새 배선 전 핀맵·전압 검토 (파이 보호)	승인/차단
프로젝트 관리	git 커밋, 테스트 매트릭스, 완료 게이트	이력·매트릭스
블로그	증거 기반 교육용 포스트 집필	블로그 초안

그림 2. 개발 → 빌드 → 검증(실패 시 피드백) → 정리 → 집필. 새 배선 전에는 안전 게이트가 선행.

가장 중요한 설계 원칙은 두 가지입니다. 첫째, 검증은 "피드백"이 아니라 "증거 생성"입니다. 재현 가능한 로그·측정값·이미지가 그대로 블로그 재료가 됩니다. 둘째, 하드웨어는 롤백이 안 됩니다. 3.3V 핀에 5V를 넣으면 파이가 죽습니다. 그래서 새 배선 전에는 반드시 안전 게이트가 핀맵과 전압을 먼저 검토합니다.

8. 다음 편 예고

다음 편(#2)에서는 임베디드의 "Hello World"인 GPIO — 출력 → 입력 핀 루프백으로 첫 시험을 진행합니다. 외부 LED, 버튼 없이 점퍼 한 가닥으로 출력 핀(BCM 17, 물리 11)을 입력 핀(BCM 27, 물리 13)에 연결하고, 출력을 0/1로 구동하며 입력으로 되읽어 drvie==read를 소프트웨어가 자동 판정합니다. 부품이 없어도 되니 재현이 가장 쉽고, 개발-검증-집필 자동화 루프가 실제로 도는 모습을 처음부터 끝까지 보여드리겠습니다.

---

이 시리즈의 모든 코드와 검증 로그는 git으로 관리되며, 각 편은 실제 실행 증거를 기반으로 작성됩니다.