[FreeRTOS] FreeRTOS란?

FreeRTOS란? 이를 알기 전 RTOS(실시간 운영체제)에 대해 알아보자.

---

1. RTOS란?

1. RTOS(Real Time Operating System)는 실시간 응용 프로그램을 위해 개발된 운영체제임

2. 운영체제의 기능 중 CPU 시간 관리 부분에 초점을 맞추어 설계되었음

3. 실시간 운영체제는 프로그래머가 프로세스 우선 순위에 더 많은 제어를 할 수 있게 함

4. 응용 프로그램의 우선 순위가 시스템 프로그램의 우선 순위를 넘어설 수도 있음

5. 시스템 코드의 임계 구역을 최소화하였으며, 이를 통하여 응용 프로그램의 처리 요청을 정해진 시간 안에 처리해 줄 수 있음

 

- 실시간 운영체제의 핵심은 응용 프로그램 Task처리에 걸리는 시간을 일관되게 유지할 수 있는 정도에 있음

- 처리 시간의 변동폭은 지터(jitter: 실제 신호와 기준점과의 시간 편차)라 부름

- 경성(hard) 실시간 운영체제와 연성(soft) 실시간 운영체제로 구분할 수 있으며, 전자가 후자에 비해 지터가 적음

- RTOS의 주된 설계 목표는 높은 처리율(throughput)이 아니라, 실시간 성능 보장에 있음

 

---

2. RTOS의 특징

1. Realtime

  - Soft realtime: Task를 가능한 빠르게 수행하지만, 반드시 지켜질 필요는 없음

    ex) RC카에서 리모컨을 인식할 때 500ms나 550ms나 사람이 인식하기엔 차이가 없어 문제가 발생하지 않음

  - Hard realtime: Task마다 반드시 지켜져야 하는 수행시간

    ex) 자동차의 제동 혹은 로켓에서의 계산같은 경우 500ms 내에 수행해야 한다는 조건이 있을 시 500ms보다 오래 걸릴 시 제동시 사고가 발생하거나 로켓 발사 공식에 큰 차질이 생길 수 있어 무조건 지켜져야 함

2. Scalability: 환경설정을 통해 사용자가 원하는 기능을 추가 및 제거하여 크기를 조절할 수 있음

3. Preemptive: Task가 동작할 때 선점을 허용할 수 있음

4. Multitasking: 여러 Task를 마치 동시에 실행하듯이 동작할 수 있음

5. Tobustness: RTOS는 CPU의 uilization을 극대화할 수 있음

 

---

3. RTOS 설계 방식

두 가지 기본적인 설계 방식이 존재

1. 이벤트 구동(event-driven) 방식

 - 우선 순위 기반 스케줄링 또는 선점형 스케줄링 이라고 부름

 - Task(task) 전환이 현재 수행중인 Task보다 높은 우선 순위를 갖는 이벤트가 서비스를 요청할 경우에 일어남

 

2. 시분할(time-sharing) 스케줄링 방식

 - 시간 인터럽트나 라운드 로빈과 같은 주기적인 이벤트가 발생할 때 Task의 전환이 일어남

 - 엄밀히 말해, 시분할 스케줄링 방식은 실제 필요한 것보다 더 자주 Task 전환이 일어남

 - 이러한점 덕분에 좀 더 자연스럽고, 예측하기 쉬운 멀티태스킹을 제공하며, 하나의 프로세스나 한명의 사용자가 장치를 독점적으로 사용하는 것과 같은 효과를 제공함

    - 이 방식이 좀 더 나은 멀티태스킹 방식처럼 보일 수 있음

    - 하지만 Task 전환이 발생하며 문맥교환(Context Switch)가 발생하며 자원을 더 소모함

    - 따라서 내가 설계하는 방향에 따른 적절한 스케줄링 방식을 적용해야 함

---

4. Task간 통신과 자원 공유

1. 멀티태스킹 시스템은 여러 개의 Task 사이에 공유되는 데이터와 하드웨어 자원을 관리해 주어야 함

2. 대부분의 경우 두 개 이상의 Task가 동시에 같은 데이터나 하드웨어 자원에 접근하는 것은 위험함

 - "위험"하다는 것은 한 Task가 복수의 데이터를 갱신하는 중일 경우, 결과가 일관성이 없고 예측 불가능하다는 뜻, 다른 Task가 이 데이터들에 접근해도 되는 시점은 갱신이 시작하기 전이나 완전히 종료된 후, ex) 생산자-소비자 문제

3. 이 문제를 해결하기 위해서 보통 사용되는 아래 3가지 방식이 존재

 

 - 일시적인 인터럽트 비활성화

1. 일단 범용 운영체제에서는 사용자가 인터럽트를 마스크(비활성화)하지 못함

 - 그 이유는 사용자의 프로그램이 운영체제의 핵심 자원인 CPU를 너무 긴 시간 동안 점유하고 있을 수 있기 때문

 - 다시 말해, 현재 사용되는 대다수의 CPU들은 사용자 모드 코드가 인터럽트를 비활성화할 수 있는 권한을 부여하지 않음

2. 하지만, 많은 임베디드 시스템과 실시간 운영체제들은 응용 프로그램이 운영체제의 간섭 없이 시스템 콜을 효율적으로 사용할 수 있게 하기 위해 커널 모드에서도 동작할 수 있도록 함

3. 단일 프로세서 시스템에서, 만약 응용 프로그램이 현재 커널 모드로 동작하고, 인터럽트를 비활성화할 수 있다면, 대개 인터럽트 비활성화야말로 두 개 이상의 Task가 동시에 공유자원에 접근하는 것을 막아주는 최고의 기법

4. 인터럽트가 비활성화되어 있는 경우, 현재 돌고 있는 Task는 다른 Task나 인터럽트가 CPU를 제어할 수 없기 때문에 "배타성"을 띠며, 따라서 임계 구역은 보호 받음

5. Task가 임계 구역에서 벗어나게 되면, 대기중인 인터럽트가 있다면 실행되도록 인터럽트를 다시 활성화시켜야 함

6. 일시적으로 인터럽트를 비활성화하는 것은 임계 구역의 가장 긴 경로가 인터럽트 대기 시간보다 짧은 경우 유효한 전략

7. 그렇지 않다면 이 방법을 통하여 시스템의 최대 인터럽트 대기 시간을 증가시킬 가능성이 있음

8. 따라서 임계 구역이 단지 몇 개의 명령어로 이루어졌거나, 반복구문을 포함하지 않은 경우 유효하다고 할 수 있음

 

 -  세마포어

1. 세마포어는 잠기거나 풀려있음

2. 잠겨 있을 때 작업들의 대기는 세마포어(가 풀리기)를 기다림

3. 세마포어 디자인들이 가지는 문제점들(우선 순위 역전과 교착 상태)은 잘 알려져 있음

4. 우선 순위 역전은 높은 순위의 작업이 낮은 순위의 세마포어를 가지는 작업을 기다리는 상황임

5. 대표적인 해결법은 세마포어를 가지는 작업이 최우선 순위가 되도록 하는 것임

6. 교착에서는 두 개의 작업이 두 개의 세마포어를 역순으로 잠금

7. 이것은 대개 대기열을 구현할 때 면밀하게 설계하거나 또는 floored semaphores(정해진 상황에서 세마포어의 제어권을 높은 순위의 작업에 넘기는)를 추가함으로써 해결됌

 

 -  메시지 전달

1. 다른 해결책은 작업들이 서로 메시지를 주고 받게 하는 것임

2. 이것 또한 똑같은 문제점들을 안고 있음

3. 작업이 낮은 우선 순위 메시지를 수행하느라 in-box에 있는 더 높은 순위 메시지를 무시할 때 우선 순위 역전이 일어남

4. 두 개의 작업이 서로 상대방의 응답을 기다릴 때 교착 상태가 일어남

5. 실시간 동작은 세마포어 시스템의 경우보다는 덜 분명하지만, 메시지 기반 시스템들은 자체적으로는 고정적이지 않아 일반적으로 세마포어 시스템들보다는 더 잘 동작함

---

5. FreeRTOS란?

 -  2003년 Richard Barry가 만든 ANSI C 기반 RTOS임. 아마존 AWS IoT 서비스 확장을 위해 2017년 11월에 인수함

 -  200개 이상의 폭넓은 MCU를 지원하며 포팅을 위한 다양한 컴파일러와 예제를 제공함

 -  MIT 라이센스로 조건없는 상업 목적 사용 가능함

 -  Priority based preemptive scheduling을 사용하며, round-robin도 함께 지원함

 -  환경설정에 따라 binary image는 4KB ~ 9KB를 가질 정도로 굉장히 light-weight이며 높은 신뢰성과 안정성을 자랑함