반응형

전체 글 804

S/W 개발자를 위한 회로도(Schematic) 독해법 A to Z: 전원 트리(Power Tree), LDO/Buck Converter, Pull-up과 Open-Drain

펌웨어 엔지니어에게 회로도(Schematic) 독해 능력이 필요한 이유임베디드 소프트웨어 엔지니어가 다루는 모든 레지스터 설정은 결국 PCB 위의 구리 배선과 부품으로 귀결됩니다. GPIO 하나를 출력으로 설정하는 코드도, 그 핀이 어떤 전압 도메인에 속하는지, 외부에 풀업(Pull-up) 저항이 실장되어 있는지, 반대편에 어떤 IC의 어떤 입력이 연결되어 있는지를 알지 못하면 올바르게 작성할 수 없습니다.실무에서 발생하는 "드라이버는 맞는데 동작하지 않는" 문제의 상당수는 소프트웨어 버그가 아닙니다. 다음과 같은 하드웨어 사실을 소프트웨어 개발자가 회로도에서 확인하지 않았기 때문에 발생합니다.I2C 센서가 NACK을 반환하는데, 회로도상 SDA/SCL 풀업 저항이 DNP(Do Not Populate)로..

Schematic reading 2026.10.31

Embedded Rust 드라이버 크레이트 실전: embedded-hal 1.0 기반 플랫폼 독립 TMP117 센서 드라이버 설계부터 crates.io 배포까지

플랫폼 독립 Embedded Rust 드라이버 크레이트(embedded-hal Driver Crate)가 필요한 이유C 언어 생태계에서 센서 드라이버는 대부분 특정 MCU의 HAL에 묶여 있습니다. STM32Cube용으로 작성된 TMP117 드라이버는 HAL_I2C_Mem_Read()를 직접 호출하므로 ESP-IDF나 Zephyr로 옮길 때 버스 접근 코드를 다시 작성해야 합니다. 7편에서 살펴본 벤더 C 드라이버는 이 문제를 함수 포인터와 void *user 컨텍스트로 해결하지만, 타입 검사가 없고 콜백 등록 실수가 런타임 HardFault로 이어집니다./* Typical portable C driver: bus access through untyped callbacks */typedef int (*b..

Embedded Rust FFI 실무: bindgen과 cbindgen으로 C 레거시 펌웨어에 Rust 모듈을 점진적으로 통합하는 방법

C 레거시 펌웨어와 Embedded Rust FFI 통합이 필요한 이유1편부터 6편까지는 처음부터 Rust로 작성하는 펌웨어를 기준으로 PAC, embedded-hal, critical-section, Embassy 비동기 드라이버를 구현했습니다. 그러나 실제 양산 프로젝트에서는 수십만 라인의 C 코드가 이미 존재합니다. STM32Cube HAL, 벤더가 바이너리로만 제공하는 센서 퓨전 라이브러리, FreeRTOS 또는 Zephyr 기반 애플리케이션, 인증을 마친 통신 스택은 Rust로 즉시 재작성할 수 없습니다.전면 재작성(Big-bang Rewrite)은 검증 비용과 일정 위험이 너무 큽니다. 현실적인 전략은 FFI(Foreign Function Interface)를 사용하여 두 언어를 한 바이너리에..

Embassy DMA 비동기 드라이버 실무: STM32 RingBufferedUartRx와 Async SPI로 구현하는 무손실 고속 시리얼 통신

고속 UART/SPI 통신에서 CPU 인터럽트 오버헤드와 패킷 드롭 문제5편에서 Embassy Executor가 await 지점에서 태스크를 중단하고, 하드웨어 인터럽트가 Waker를 호출하여 태스크를 다시 깨우는 구조를 분석했습니다. 이 구조가 가장 큰 효과를 발휘하는 영역은 DMA(Direct Memory Access) 기반 시리얼 통신입니다.바이트 단위 인터럽트(RXNE Interrupt) 방식의 UART 수신은 1바이트마다 ISR이 한 번씩 실행됩니다. 8N1 프레임 기준 1 Mbps 통신에서는 초당 약 100,000개의 바이트가 도착하므로, CPU는 10 us마다 인터럽트 진입, 레지스터 스태킹, DR 레지스터 읽기, 링버퍼 저장, 예외 복귀를 반복해야 합니다./* Byte-per-interru..

Embassy 프레임워크 입문: RTOS 없이 Rust Async/Await로 구현하는 Cortex-M 협력형 멀티태스킹

RTOS 스레드 모델의 스택 낭비와 Embassy Async Executor의 등장FreeRTOS, Zephyr, ThreadX와 같은 전통적인 RTOS는 선점형 스레드(Preemptive Thread) 모델을 사용합니다. 각 태스크는 독립된 스택 메모리와 TCB(Task Control Block)를 가지며, 스케줄러는 SysTick 또는 PendSV 예외를 이용해 레지스터 컨텍스트를 저장하고 복원합니다./* FreeRTOS: every task reserves its own worst-case stack */xTaskCreate(vLedTask, "led", 512, NULL, 1, NULL); /* 512 words = 2 KB */xTaskCreate(vSensorTask, "sensor..

베어메탈 Rust 계층 구조: PAC(Peripheral Access Crate)와 embedded-hal 1.0 완벽 분석

임베디드 C 레지스터 조작의 위험성과 Rust 계층 구조의 필요성전통적인 임베디드 C 언어에서 마이크로컨트롤러(MCU)의 물리 하드웨어 레지스터를 제어하는 방식은 수십 년간 매크로와 원시 포인터 역참조에 의존해 왔습니다./* Typical C Macro for Hardware Register Access */#define RCC_AHB1ENR (*(volatile uint32_t *)(0x40023800 + 0x30))#define GPIOA_MODER (*(volatile uint32_t *)(0x40020000 + 0x00))/* Bitwise manipulation in C */RCC_AHB1ENR |= (1 이러한 C 언어 방식은 3가지 치명적인 엔지니어링 문제를 내포합니다.타입 안전성 부..

베어메탈 Rust 계층 구조: PAC(Peripheral Access Crate)와 embedded-hal 1.0 완벽 분석

임베디드 C 레지스터 조작의 위험성과 Rust 계층 구조의 필요성전통적인 임베디드 C 언어에서 마이크로컨트롤러(MCU)의 물리 하드웨어 레지스터를 제어하는 방식은 수십 년간 매크로와 원시 포인터 역참조에 의존해 왔습니다./* Typical C Macro for Hardware Register Access */#define RCC_AHB1ENR (*(volatile uint32_t *)(0x40023800 + 0x30))#define GPIOA_MODER (*(volatile uint32_t *)(0x40020000 + 0x00))/* Bitwise manipulation in C */RCC_AHB1ENR |= (1 이러한 C 언어 방식은 3가지 치명적인 엔지니어링 문제를 내포합니다.타입 안전성 부..

no_std 환경 설정과 ARM Cortex-M 크로스 컴파일 파이프라인: cortex-m-rt, probe-rs 및 defmt 완벽 가이드

베어메탈 마이크로컨트롤러와 Rust no_std 생태계의 등장 배경Rust의 표준 라이브러리(std)는 운영체제(OS)의 시스템 콜(POSIX, Windows API 등)이 제공하는 가상 메모리 할당(malloc), 멀티스레딩 스케줄러, 파일 시스템 I/O, 네트워크 소켓을 기반으로 동작합니다. 그러나 전형적인 마이크로컨트롤러(MCU)인 ARM Cortex-M 시리즈는 운영체제가 존재하지 않는 베어메탈(Bare-Metal) 환경이거나, 힙 메모리와 파일 시스템이 극도로 제한된 환경에서 동작합니다.따라서 임베디드 시스템에 Rust를 적용하기 위해서는 OS 의존성을 완전히 제거하고, 순수 CPU 명령어와 정적 메모리만을 제어할 수 있는 베어메탈 모드인 #![no_std] 환경을 구성해야 합니다.전통적인 C ..

왜 임베디드에 Rust인가? C 언어의 치명적 결함을 컴파일 타임에 잡는 원리와 소유권(Ownership)

임베디드 C/C++ 메모리 결함의 현실과 Rust의 필요성지난 40여 년간 C와 C++는 마이크로컨트롤러(MCU) 및 임베디드 시스템 펌웨어 개발의 절대적인 표준 언어였습니다. 하드웨어 메모리 맵 레지스터에 대한 직접적인 포인터 역참조, 극단적으로 작은 런타임 오버헤드, 결정론적인 실행 제어는 C 언어가 독점적 지위를 유지할 수 있었던 핵심 이유입니다.그러나 C 언어는 개발자에게 무제한의 메모리 제어 권한을 부여하는 대신, 메모리 안정성에 대한 책임을 전적으로 인간의 주의력에 전가합니다. 마이크로소프트 보안 응답 센터(MSRC), 구글 크로미움 프로젝트, 미국 CISA의 장기 조사 보고서에 따르면, 소프트웨어에서 보고되는 전체 치명적 보안 취약점(CVE)의 약 70%가 메모리 안전성(Memory Safe..

임베디드 C 코딩 규칙: MISRA-C:2012 핵심 가이드와 Cppcheck 정적 분석 도구 CI/CD 자동화

C 언어의 미정의 동작(Undefined Behavior)과 MISRA-C의 필요성C 언어는 하드웨어 레지스터에 직접 접근할 수 있는 강력한 포인터 제어 기능과 뛰어난 런타임 성능 덕분에 반세기가 넘도록 임베디드 시스템의 절대적인 표준 언어로 자리 잡고 있습니다. 그러나 ISO C 표준은 컴파일러 제조사에게 최적화의 자유를 부여하기 위해 수많은 문법적 모호성을 허용하고 있습니다.C 표준에 정의된 대표적인 비결정론적 동작은 세 가지 범주로 분류됩니다.미정의 동작 (Undefined Behavior, UB): 표준이 아무런 요구사항을 부과하지 않아 프로그램이 즉시 크래시되거나, 레지스터가 오염되거나, 완전히 예측할 수 없는 방식으로 동작함 (예: 부호 있는 정수 오버플로우, 널 포인터 역참조).미지정 동작 ..

Security & Saftey 2026.10.22
반응형