티스토리 뷰

interactics/ROS

RTOS 개괄

interactics 2020. 9. 14. 18:25

목차

1. RTOS? [진행중]

2. Micro-ROS? [x]

3. Micro-ROS 예제 [x]

4. Micro-ROS를 통한 모터 제어 [x]

 

 

 

임베디드

임베디드 운영체제

  • 단순한 절차적 작업 수행
  • 8비트, 16비트 마이크로 컨트롤러 및 마이크로 프로세스 사용.

임베디드 리눅스

저성능 마이크로 프로세스, 한정된 메모리 환경을 위한 리눅스

장점

  • 높은 확장성
  • 다양한 cPU지원

단점

  • RTOS에 비해 많은 메모리 요구
  • 범용 OS로서, 리얼타임 지원 X

RTOS?

Real-Time Operating System

  • 어떤 Task 정해진 시간 안에 처리해야할 때, 사용하는 운영체제로, 즉 실시간 처리를 보장해주는 OS
  • 일반적 OS와의 차이점으로 RTOS는 효율성, 시간 제약(속도), Fairness가 특징
    • 보다 시간 제약성, 신뢰성을 중시함.
  • 일반 OS는 컴퓨팅 자원의 효율적 분배에 포커스를 맞춤
  • RTOS는 처리시간의 제약 안에서 처리 중점이 맞추어져있다.
  • 임베디드 시스템에서 어떤 기능은 다른 기능에 비해 빠른 처리 프로세스를 요구

특징

RTOS는 멀티태스킹과 작업의 스케줄링에 포커스를 맞추어 진행. 실시간 운영체제는 신뢰성, 예측성, 동시성, 적시성을 제공한다.

  1. 멀티 프로세스, 멀티 스레드, 프리엠프티블
  2. 스레드의 우선순위 수준
  3. 예측 가능한 스레드 동기화
  4. 우선순위에 근거한 선점형 작업 스케쥴링
  5. 외부 이벤트에 예측 가능한 반응
    1. 하드 리얼타임 시스템은 1ms 반응시간 요구
    2. 소프트 리얼타임 시스템은 10ms 반응시간 요구
  6. 빠른 입출력
  7. 최소한의 인터럽트 중지 기간
  8. 최소한의 메모리 요구를 가진 소형 커널
  9. 독자적 운영체제 개발 가능

하드 리얼타임 vs 소프트 리얼타임

하드 리얼타임

  • 어떤 작업을 일정 시간 안에 반드시 처리해야함.
  • 정확한 값이라도 시간이 초과되면 무쓸모되는 상황에서 사용.
  • 예) 미사일, 비행기

소프트 리얼-타임

  • 한정된 시간 안에 처리하지 못하여 약간 초과하여도 처리 값을 인정
  • 예) 휴대폰, 라우터

멀티태스킹

  • 태스크는 문제를 해결하기 위해 어플리케이션을 논리적으로 나눈 개념을 말함.
  • 어떤 목적을 달성하기 위해서는 다양한 기능을 실행시켜야하나, 순차적 실행시키는 방식에는 한계점이 존재. 따라서 멀티태스킹이라는 개념이 만들어짐.

태스크

  • 각 태스크에는 우선순위가 존재하여 높은 우선도의 TASK가 CPU를 먼저 점유하여 실행함
  • 선점형 커널(preemptive kernel)
  • 태스크는 프로그램 혹은 함수들의 집합으로, 태스크마다 독립적인 스택 영역을 가지게 되어, 다른 태스크들은 각자의 태스크 영역을 서로 침범할 수 없다.

태스크의 상태

  • Dormant

    • 태스크가 메모리 존재하나 실행할 수 없음.
    • Task 생성 시에는 Dormant 상태.
    • 일부 RTOS는 Dormant없이 바로 Ready로 변하는 것이 있음.
  • Running

    • 태스크가 CPU를 사용 중
    • 태스크 코드가 동작 중임
    • TASK Running, TASK가 CPU 점유 중, Task가 CPU 레지스터 사용 중 ←이라고도 표현함. 같은 의미이다.
  • Ready

    • 태스크의 우선순위가 낮아 CPU의 사용을 기다리는 중
  • Waiting

    • 이벤트를 기다리는 중
    • 이벤트가 발생하게 되면 CPU의 사용을 기다리는 Ready로 변환.
  • ISR

    • ISR은 CPU의 점유를 태스크 자신의 힘이 아닌 외부의 힘에 의해 가져오게 하는 방식
  • 태스크 다이어그램

     

스케쥴러(Dispatcher)

  • Ready 상태의 태스크들 중 어느 태스크를 수행할 것인지 결정

    • 다음 태스크를 결정. 따라서 스케쥴을 짜주는 역할.
  • Priority-based scheduling 방식을 사용.

    • 우선순위가 높은 태스크를 수행함

     

Context Switch (Task Switch)

  • Context - Task가 점유 중인 CPU의 레지스터 값을 의미.
  • Context Switch - 스케쥴러에 의해 새로운 태스크가 수행이 되면, 이전의 Running 태스크의 컨택스트를 메모리의 특정 영역(TCB 혹은 스택)에 저장. Ready의 새 태스크의 컨택스트는 CPU의 레지스터 영역으로 복사 후 새 태스크 코드 수행.

 

선점형 & 비선점형 커널

Non-preemeptive Kernel(비선점형 커널)

  • cooperative multitasking이라고도 부름
  • 어느 태스크가 수행되고 있다면, 해당 커널은 태스크의 강제 중지 능력이 없다.
  • 해당 구조에서는 우선 순위가 낮은 태스크는 높은 우선도를 가진 태스크의 완수를 계속 기다려야하는 상황이 발생.
  • RTOS에서는 사용 불가.

비선점형 커널의 처리 순서

  1. 낮은 우선도 태스크 수행 중
  2. 인터럽트 발생
  3. ISR에서 인터럽트 처리 후 스케쥴러 호출하여, 현 태스크보다 높은 우선도를 가진 태스크를 READY 상태로 변환
  4. ISR 종료 후 ISR 처리 이전에 수행하던 태스크로 돌아감.
  5. 다시 코드 수행.
  6. 이전 Task는 system call을 호출하여 CPU 사용 권한을 포기.
  7. 커널에 의해 새로운 태스크 수행.

preemeptive Kernel(선점형 커널)

  • 비선점형 커널과 달리 수행 중인 태스크의 수행 중지 능력을 가짐.
  • 우선도가 높은 Task가 CPU를 항상 점유할 수 있도록 할 수 있음.
  • Deterministic한 특성을 가짐.
    • 따라서 RTOS가 사용 중인 구조

선점형 커널의 처리 순서

  1. 낮은 우선도 태스크 수행 중
  2. 인터럽트 발생
  3. ISR에서 인터럽트 처리 후 스케쥴러 호출하여, 현 태스크보다 높은 우선도를 가진 태스크를 READY 상태로 변환
  4. ISR 종료 후 ISR 처리 이전에 수행하던 태스크로 돌아가지 않고 새 태스크가 CPU 제어 권한을 가짐.
  5. 새 태스크 수행
  6. 새 태스크가 수행을 완료하면 Kernel system call을 호출해 CPU 제어 권한을 포기 후 과거 태스크가 선택됨.
  7. 이전의 태스크의 인터럽트 발생 전부터 코드를 다시 수행.

Critical Section

이 코드 블록은 타 Task에 의해 중단되면 안되는 영역.

Reentrancy 재진입성

재진입성 함수

  • 해당 코드 블록(함수)는 어느 시점에 발생하게 되어도 문제가 없음.
  • 대부분 로컬 변수로 작성됨.

Critical Section 임계영역

비재진입성 함수

  • 크리티컬 섹션의 코드 수행이 되면 context switch에 의한 다른 태스크의 수행이 없어야한다.
  • 이를 위해 크리티컬 섹션 시작 전(입장영역)에는 인터럽트 Dissable을, 끝에는 Enable를 하여 보호.

Mutex (Mutual Exclusion)

  • 어떤 한 태스크가 한 공유자원을 사용하고 있을 때, 해당 자원을 다른 태스크가 사용하지 못하도록 막는 것을 보장하는 것.
    • 공유자원 : 여러 태스크가 공동 사용, 접근이 가능한 모든 것 ex) 전역변수따위?
  • 자원을 공유하는 과정에서 태스크 사이 경쟁, 데이터 손실을 막야함.

Mutex 보장법

Interrupt Enable/Disable

  • 공유 자원을 사용하고 있을 때에는 인터럽트를 금지
  • 간단한 방식
  • 인터럽트 장기간 금지가 되어버리면 인터럽트를 잃어버리게 됨. 응답성에 악영향
  • 가능한 빨리 인터럽트를 재가동 해야함
  • 시간이 많이 걸리는 작업에서는 회피할 것
  • 작동방식
    1. 인터럽트 비활성
    2. 공유자원 접근
    3. 인터럽트 활성화

Scheduler Lock/Unlock

  • 공유 자원을 사용하고 있을 때에는 스케쥴링 금지
  • 스케쥴링만 금지기 때문에 인터럽트 발생 가능성 존재
  • ISR에서 공유자원에 접근하게 되면 Mutex 보장 불가
  • 태스크 간의 공유 자원 보존만 가능
  • 과사용하게 되면 높은 우선도의 태스크가 CPU 사용도가 지연됨. 따라서 이로인해 deterministic 특성이 훼손될 가능성이 있음.
  • 작동방식
    1. 스케쥴러 비활성
    2. 공유자원 접근
    3. 스케쥴러 활성화

Test - And - Set (TAS)

  • 어떤 변수가 특정 숫자가 되었을 때만 해당 자원에 접근하게 하는 방식
  • 작동방식
    1. 만약 flag 변수가 1이라면
      1. flag 0으로 설정
      2. 인터럽트 비활성화
      3. 공유자원 접근
      4. 인터럽트 활성화
      5. flag 1로 설정
      6. 인터럽트 활성화
    2. 만약 flag 변수가 1이 아니라면
      1. 인터럽트 활성화 (공유자원 액세스 불가)

Semaphore

  • Semaphore 사용
    • 가장 효율적인 방법
    • 공유 자원에 대한 접근 시간이 짧을 경우에 효율적

Semaphore

  • 공유자원에 접근하기 위해서는 키가 필요함
  • RTOS에서 지원하는 방식 중 하나
  • 공유 자원에 대한 액세스 제어
  • 이벤트 발생 여부를 알려줌 (Signaling)
  • 태스크 간 동작 동기화(Synchronization/Rendezvous)

← 현재 작성중입니다.

 

 

참고문헌

FreeRTOS라이브러리(멀티 스레드) : FreeRTOS라이브러리(멀티 스레드)

자료 모음 : alfee0의 blog : 네이버 블로그

RTOS이해 : 실시간 운영체제 - RTOS의 이해

UBINOS 자료 - ARM 아키텍트 : Confluence

FreeRTOS Manual : Free RTOS Book and Reference Manual

RTOS는 언제 쓸까: 당근이의 AVR 갖구 놀기

RTOS 겉핥기: 오픈소스 소프트웨어 & 하드웨어: 로봇 기술 공유 카페 (오로카)

mbed : 오픈소스 소프트웨어 & 하드웨어: 로봇 기술 공유 카페 (오로카)

아두이노 RTOS : Arduino Uno에서 freeRTOS 올려보기

RTOS 시스템 : RTOS 의 기초 (1) - 전경/배경 시스템

Embedded System에서 Real-Time OS 구현 및 응용에 관한 연구.pdf

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31