RTOS research

RTOS(Real Time Operating System)

• 실시간 응용프로그램을 지원 → 효율보다 시간 중시
• 주어진 시간 내에 우선순위대로 어떤 작업을 반드시 처리해야 하는 시스템
• 지연없이 예측 가능한 시간 내에 작업 처리
• 특별한 설계와 스케줄링 알고리즘 사용하여 효율적으로 관리

 

주요 특징

• Scheduling
• 작업들 우선순위 관리, 언제 어떤 task를 실행할지 알고리즘 제공
• 인터럽트 관리(Interrupt Latency: 인터럽트 발생 후, 인터럽트 핸들러까지 도착하는 시간)
• hw, sw 인터럽트 관리하여 작업 간 전환 가능, 신속한 응답과 짧은 Interrupt Latency를 가짐
• 동기화 및 통신
• 공유자원에 접근 동기화, 세마포어/뮤텍스/메시지 큐 등 동기화 및 통신 메커니즘 제공
• 타이머 및 디바이스 관리
• 하드웨어 리소스 효율적으로 사용하기 위해
• 작은 커널 사이즈

https://smallrich.tistory.com/78

https://rangvest.tistory.com/entry/실시간-운영체제RTOS-임베디드-시스템의-핵심-기술-Part1기본-개념-및-특징-형태-용어-정리

 

Zephyr (제퍼)

• 2016.2에 Linux Foundation에서 release
• resource constrained device 즉, 리소스 제한적인 장치 및 IoT를 target으로 함
• Linux Foundation과 Intel/NXP/Linaro/Synopsys/Nordic 등이 주도하는 Linux에 매우 가까운 OS
• kernel 자체는 Linux하고는 전혀 무관하게, Intel Wind River(VxWorks -> Viper -> Zephyr)의 것을 채용하고 있어, 출시한지 얼마 되지 않았음에도 불구하고 안정성에 자신이 있는 모습

https://docs.zephyrproject.org/latest/introduction/index.html

https://m.blog.naver.com/chcbaram/222755342935

https://slowbootkernelhacks.blogspot.com/2017/03/zephyr-project.html

 

 

툴체인

• 역할: PC에 있는 소스코드를 MCU가 이해할 기계어로 바꾸고, 보드에 올리는 전체 과정
  • 구성: 크로스 컴파일러(호스트→타깃 바이너리), 링커(객체파일 결합), 플래셔·디버거(USB/JTAG 업로드)
  • 익히기: 간단한 “Hello, World!” 프로젝트로 빌드→플래시→디버그까지 해보기

개발자가 쓴 소스 코드를 목표 기기(ESP32-S3 같은 MCU)에서 돌아가는 실행 파일로 만들어 주고, 그 결과물을 기기에 올려 디버깅·플래싱까지 돕는 도구 모음을 의미

• 주요 구성 요소
  • 크로스 컴파일러: 호스트 PC에서 MCU용 바이너리(.bin)를 생성
  • 링커·라이브러리: 여러 객체 파일을 하나의 실행 파일로 결합
  • 플래셔: 컴파일된 펌웨어를 실제 보드에 업로드하고 디버그

이렇게 한데 묶여 있어야 FreeRTOS 애플리케이션을 MCU에 빌드·올릴 수 있음

 

MCU

“Microcontroller Unit”의 줄임말 CPU 코어, 플래시·RAM, 입출력 주변장치(ADC·UART·GPIO 등)를 하나의 칩에 전부 담은 작은 컴퓨터 배터리나 전력·메모리가 제한된 임베디드 기기에서 주로 쓰임

– 8비트 계열: Atmel AVR(예: ATmega328), Microchip PIC

– 32비트 ARM Cortex-M: M0/M0+, M3, M4, M7 코어(예: STM32, NXP LPC)

– 32비트 RISC-V: SiFive, Kendryte 같은 오픈소스 ISA 기반 칩

– 고집적 SoC(약간 큰 MCU): Espressif ESP32, Nordic nRF52(블루투스 내장)

 

• Arduino UNO (ATmega328P) – 8비트 AVR 계열, 입문자용으로 가장 흔함

 STM32 Nucleo-F401RE – ARM Cortex-M4 기반, 산업·취미용으로 널리 쓰이는 평가 보드

• Raspberry Pi Pico (RP2040) – 듀얼-코어 Cortex-M0+ 칩, 저렴한 가격대에 GPIO 풍부

• Nordic nRF52840 DK – Bluetooth LE·Zigbee 내장 Cortex-M4, 무선 IoT 디바이스용

• Microchip Curiosity PIC32 – 32비트 MIPS 코어, 다양한 주변장치 예제 제공

 

슬립 모드 진입·복귀 시점 테스트

MCU가 대기 상태(절전 모드)로 넘어갈 때, 다시 깨어날 때 각각 정확히 언제 작동하는지 확인하라는 뜻 • 전류계로 소비 전류가 뚝 떨어지는 순간을 잡고, 인터럽트나 타이머로 깨어나는 타이밍을 측정 • 예제 코드에서 idle hook이나 wake-up ISR(인터럽트 서비스 루틴)에 로그 찍어서 타임스탬프 확인해 보면 됨.

• 목적: MCU가 대기 상태로 들어갈 때·깨어날 때 전력과 지연을 측정해 보는 것
  • 방식: 딥슬립 진입 시점과 ISR로 깨어난 시점을 전류계·로그로 잡아 간극을 확인
  • 익히기: 10초 딥슬립→Wakeup ISR에서 시리얼 타임스탬프 찍어 비교

 

(이상탐지) 오토인코더·문턱값 방식 비교 실험

두 가지 이상 탐지 방법을 실제 데이터로 시험해 보고, 어떤 쪽이 더 잘 작동하는지 비교해 보는 단계

• 문턱값 방식: 센서값이 미리 정한 선 넘으면 이상으로 판단
  • 오토인코더 방식: 정상 데이터만 복원하도록 학습시켜, 재구성 오차가 크면 이상으로 간주
  • 평가: 같은 데이터로 두 방법 돌려보고 정확도·오탐·응답속도를 표·그래프로 비교

문턱값 방식

– 예를 들어 온도가 50℃를 넘거나 가속도 값이 특정 g 이상일 때 경보 띄우기.

– 센서 신호가 미리 정한 기준(문턱값)을 넘으면 ‘이상’으로 판단하는 간단한 규칙 기반.

오토인코더 방식

– 재구성 오차가 높으면 ‘이상’으로 판단하는 머신러닝 모델.

– 정상 상태 데이터를 학습해 조금이라도 다르게 재구성하면 오차가 커지는 성질을 이용.

 

비교 실험 절차

• 같은 센서 데이터를 두 방법에 동시에 적용
• 오탐·미탐 횟수, 탐지 시점(얼마나 빠른지), 계산 부하(CPU 사용량) 등을 측정
• 결과를 표나 그래프(정확도, 응답 시간)로 정리해
• “문턱값은 단순하지만 오탐이 많았다” / “오토인코더는 정밀했지만 연산량이 컸다” 같은 결론을 내는 거

 

센서 드라이버

센서랑 통신해서 실제 값을 뽑아오는 소프트웨어 모듈 보통 I²C나 SPI 같은 규약을 쓰면서 • 센서 초기화(측정 모드 설정) • 설정한 주기에 맞춰 데이터 읽기 • 레지스터 값 해석·보정 같은 일을 대신함 그래서 애플리케이션 쪽에서는 “센서에서 이렇게 값이 나왔구나”만 알면 되지, 복잡한 통신 구현을 일일이 신경 안 써도 됨

• MPU-6050 드라이버: 3축 가속도·자이로 데이터를 I²C로 읽어 와서 물리값(㎨, °/s)으로 변환
• BMP280 드라이버: 압력·온도 센서, SPI/I²C 통신으로 기압(㎩)·온도(℃) 측정
• MQ-2 드라이버: 가스 센서 아날로그 출력 읽고 가스 종류별 농도로 매핑

 

센서 로거 구축

• 센서 드라이버로부터 주기적으로 값 읽기 → 타임스탬프 붙여 메모리나 SD카드에 저장
• 예제: 10 ms마다 MPU-6050 데이터 읽어서 CSV 파일로 기록하거나, 원형 버퍼에 쌓아 PC로 전송
• 포인트: 언제·어떤 센서 값이 들어왔는지 정확히 기록하는 시스템을 만드는 단계

 

알림 UX A/B 테스트

두 가지 알림 화면·문구 버전을 만들어 소수 사용자(혹은 팀원)에게 각각 보내 보고,

어느 쪽이 더 빠르고 정확하게 주의를 끄는지 비교하는 실험

예를 들어

• A안: “[위험] 온도 급상승 발생, 즉시 확인 요망”
• B안: “Alert! 온도 75℃ 초과, 조치 필요”
• 둘 중 반응 속도·이해도·실제 클릭률 등을 재고 ‘우승’ 버전을 최종 UX로 결정해.

 

OTA·Secure Boot 적용 결과 검증

• OTA(Over-The-Air): 무선으로 펌웨어를 업데이트하는 기능이 제대로 동작하는지,
• 실제로 새 버전을 내려받고 설치·재부팅까지 문제없이 이뤄지는지 테스트.
• Secure Boot: 부팅 시 펌웨어 서명을 검사해 위변조된 코드가 실행되지 않도록 하는 보안 기능.
• 펌웨어를 임의로 바꾼 뒤에도 부팅이 거부되는지, 정상 서명 펌웨어만 실행되는지 검증하는 단계

 

펌웨어 서명이란?

업데이트되거나 부팅될 펌웨어(펌웨어 이미지)에 디지털 서명을 붙여서

1. 이 펌웨어가 제조사(또는 신뢰된 개발자)가 만든 원본인지
2. 전송 과정에서 내용이 변조되지 않았는지

를 확인할 수 있게 해 주는 절차

• 작동 방식
  • 빌드 과정에서 펌웨어 바이너리에 해시(hash)를 뽑고,
  • 제조사만 가지고 있는 “비밀키(private key)”로 그 해시를 암호화(서명)해 펌웨어에 덧붙여 둔 다음,
  • 부팅 시에는 부트로더가 미리 내장된 “공개키(public key)”로 이 서명을 풀어 보고,
  • 풀어낸 해시가 실제 바이너리 해시와 일치하면 “정상 펌웨어”로 인정하고 실행,
  • 불일치하면 부팅 자체를 중단해서 변조된(악성) 코드가 돌지 못하게 막음
• 왜 쓰는가
  • 원격 업데이트(OTA) 환경에서 네트워크 공격이나 우연한 파일 손상으로부터 기기를 보호
  • Secure Boot를 구현할 때 필수 요소로, 부트로더→OS→애플리케이션 전 단계의 무결성을 보장

이 과정을 통해 “펌웨어를 믿고 실행”할 수 있게 만드는 게 바로 펌웨어 서명

 

펌웨어란?

– MCU나 임베디드 장치에 탑재되는 ‘내장 소프트웨어’ – 하드웨어 초기화, 센서·통신 제어, 전력 관리 같은 일을 담당 – 보통 C/C++로 작성하고, 크로스 컴파일러로 빌드한 뒤 MCU에 올려서 실행

이렇게 MCU는 칩 종류별로 성능·기능이 다르고, 펌웨어는 그 칩 위에서 돌아가는 “동작 지침서” 같은 역할을 해줌

 

 

저전력 최적화

배터리나 전원 제한 환경에서 동작 시간을 최대화하기 위한 전력 절감 기법 모음.

예시:

1. 절전 모드 활용: 작업이 없을 때 MCU를 깊은 수면 상태로 보내 소비 전류를 극소화
2. 클럭 스케일링: 처리량이 덜 필요할 때 CPU 클럭을 낮춰 전력 소모 줄이기
3. 주변장치 관리: 센서·통신 모듈을 쓰지 않을 때 전원 차단하거나 슬립 모드로 전환
4. 이 세 가지만 해도 평균 전류를 수십 mA에서 수 mA 단위로 낮출 수 있음

 

메모리 관리(스택 vs 힙)

• “각 태스크가 사용할 스택 크기”와 “힙 영역을 쓸지 말지”를 결정하는 걸 의미
• 적절한 스택 용량을 정해두지 않으면 나중에 오버플로우가 나고, 힙을 무작정 쓰면 단편화로 런타임 오류가 생길 수 있어서, 초기 환경 세팅 시점에 반드시 명확히 잡아두는 게 좋음
• 스택: 함수 호출·컨텍스트 저장용으로 고정 크기 할당, 단편화 걱정 없음
• 힙: 동적 메모리 할당은 편하지만 장기 운영 시 단편화 문제 발생
• RTOS 환경에선 스태틱 풀(pool) 기반 할당으로 메모리 안정성↑
• 태스크별 스택 크기와 동적 할당 전략을 미리 잡아 두어 런타임 파편화·오버플로를 방지해야 할 때

 

메모리 단편화(Fragmentation)

• 동적 할당(heap)·해제 반복 시 메모리 조각이 흩어져 큰 블록을 연속으로 확보하지 못하는 현상
• 작은 블록·빈 공간이 남아도, 연속된 큰 메모리가 필요할 때 할당 실패로 이어짐