기록

RTOS의 특징
Hard Realtime
Scalability
Preemptive
Multitasking
Deterministic (예측가능)
Portability
Robustness

[질문]
이미 RTOS 없이도 실시간으로 잘 작동하고 있는 시스템을
RTOS 시스템으로 변경할 필요가 있을까요?

실시간성을 잘 유지하고 있는 소프트웨어인데

RTOS를 새로 도입하면서 실시간을 하는 것은 맞지 않습니다.

기본적으로 RTOS 를 쓸 때는

멀티태스킹이라고 하는 것을 전제하고 있는 것입니다.

멀티태스킹을 하면서도 실시간을 원할 때 쓰는 것입니다.

그렇기 때문에 우리가 RTOS 사용하는 이유는 크게 두 가지가 있는데

하드 리얼타임을 필요로 하는 애플리케이션과 

하드 리얼 타임은 필요하지 않는 애플리케이션 두가지로 분류됩니다.

실시간 OS 라고 하는 이 단어 때문에 오해가 많습니다.

모든 임베디드 시스템은 실시간 시스템이니까요.

RTOS 의 주요 특징 중에 하나가

바로 하드 리얼 타임 입니다.

항공기 사진입니다.

항공기는 특성상 탈출구가 없죠.
그러다 보니까 재난적인 상황이 굉장히 취약합니다.

그래서 하드 리얼 타임의 목표는

예측한 시간, 약속된 시간에 정확하게 작동하도록 하는 것입니다.

그냥 지킬 때도 있고 안 지킬 때도 있고 있다면

하드 리얼타임이라고 부를 수 없습니다.

***
스케일러블리티(scalability) 라고 하는게 

또 하나의 RTOS의 특징입니다.

RTOS 자체가 그 바이너리 파일 기준으로

수십 킬로바이트에서 수백 킬로바이트입니다.

RTOS 하나의 프로그램의 크기가

통상 수십 킬로바이트에서 수백 킬로바이트에 달하는데

이렇게 사이즈가 정해져 있지 않은 이유는

기능을 많이 추가하면 사이즈는 커지고

기능을 최적화 시키면 작게 만들 수가 있습니다. 

이것이 스케일러빌리티(scalability)입니다.

세번째는 선정 가능하다는 것입니다.

네번째는 멀티태스킹이 된다는 것이고,

그 다음 특징이 예측 가능한 시스템이라는 것입니다.

예측 가능하다 .

이게 아마도 가장 중요한 특징이 아닐까 합니다.

많은 개발자들이 자기가 만든 S/W가

로버스트니스(robustness)하기를 원합니다.
어쩔 땐 동작하고 어쩔 땐 동작하지 않고

혹은 전혀 동작하지 않고 하는 것을 싫어합니다.

***
RTOS와 항상 비교되는 OS가 있습니다.
Linux 와 Windows입니다.

RTOS는 임베디드 시스템용 운영체제 입니다.
그래서 Linux하고 윈도우즈와는 다릅니다.

그 중 Linux는 RTOS 의 가장 큰 경쟁자입니다.

예전 1900년대에는 임베디드 운영체제의 선택지가

RTOS밖에는 없었습니다.

그런데 지금이 와서는

리눅스라고 하는 이 훌륭한 운영체제로 많이 대체됐습니다.

RTOS가 차지할 자리를 리눅스가 많이 가져갔죠.

그래서 지금도 임베디드 시스템에서

가장 많이 쓰는 운영체제가 어떤 거냐고 조사해보면 

항상 리눅스가 거의 20여 년 가까이 항상 상위 랭크입니다.

기존 1900년대의 임베디드 시스템에는

무조건 RTOS밖에 없었거든요.

그런데 지금 와서는 많은 부분

리눅스 운영체제가 그 자리를 차지하고 있습니다.

대표적인 예로, 스마트폰 이전에 피처폰이라고 해서 폴더폰입니다.

그때의 스마트폰 이전 세대의 전화기를 보면

전부 다 RTOS가 들어가 있었지만

지금와서 보면 전부 다 안드로이드나 iOS 입니다.

그만큼 대체가 많이 된 것이죠.

또한 드론 같은 것도 보면 

드론도 예전에 RTOS에 썼습니다만 

요즘은 리눅스 쓴 것도 찾아볼 수 있습니다. 

RTOS도 중요한 임베디드 시스템용 OS가 될 수 있지만

상당부분을 리눅스가 가져가고 있습니다.

RTOS라는 용어는 실시간 운영체제라는 뜻을 가지고 있습니다.

RTOS를 바라보는 시각은 크게 두가지가 있습니다.

첫번째, RTOS는 

임베디드 시스템 전용 운영체제다.

두번째, RTOS는 

실시간 지원을 위한 운영체제다. 

둘 다 맞는 표현입니다.

전자의 경우는 RTOS를

단순 멀티태스킹 기능이 필요해서 쓰는 경우인 것이죠.

후자의 경우는 멀티태스킹 하면서 

또한 실시간 처리가 필요해서인 거죠.

여러분은 이 RTOS를 사용하시려는 목적 

혹은 가치를 어느 쪽에 두고 계십니까? 

두 가지가 서로 다르지 않은 것 같지만 

사실 큰 차이가 있습니다. 

***
실시간이라는 말의 뜻을 우리가 정확히 이해하기 위해선 

기본적으로 전제하고 들어가야 할 사실이 있습니다.

그것은 임베디드 시스템은 모두 다 리얼타임 시스템이다 라는 것입니다. 

레이더 시스템, 드론, 미사일 관제 시스템, 자동차, 스마트폰, 

심지어 커피 머신도 또한 실시간 시스템입니다.

왜냐하면 실시간 시스템이라고 하는 것은 

그 어디에도 정확한 기준이 없어요. 

위키피디아 설명을 인용해 보면 

실시간 컴퓨팅 시스템이란 

사용할 수 있는 자원이 한정되어 있는 상황에서

작업 수행이 요청되었을 때

이를 제한된 시간 안에 처리해 결과를 내주는 것을 말한다. 

이 문장에서 가장 모호한 표현이라고 짐작되는 단어가 어떤 것일까요? 

제한된 시간이라는 구절이라고 생각합니다.

임베디드 시스템들은 저마다 다른 목적과 동작 방식을 가진 것처럼 

서로 다른 제한 시간을 가지고 있을 겁니다.

어떤 시스템은 1초 안에 동작을 완료하면 

성공으로 인정되는 시스템이 있는가 하면, 

어떤 시스템은 0.001초 안에 동작을 완료하여야만 

성공으로 인정됩니다.

이 중 어떤 시스템을 실시간이라고 부를 수 있을까요?

위키피디아 설명에 따르면 

둘 다 실시간 시스템이라고 부를 수밖에 없는 겁니다. 

커피 자판기에 동전을 넣고 버튼을 조작한 후 

최대 1초 안에 나오는 컵이 

그날따라 컵이 나오는데 2초가 걸린 거예요.

그렇다고 커피자판기를 이용하는 사람이 

이것을 의식하거나 큰 문제로 생각하지 는 않습니다.
대개의 사람은 그냥 그럴 수도 있다고 생각할 겁니다.

자동차를 생각해 보죠.
시속 120km로 주행 중인 자동차에서 브레이크를 밟았을 때 

전방 100미터 내

그리고 3초 안에 차량이 서야 한다고 가정해 보죠.

하지만 그날따라 100미터 이내에 서지도 못했고

심지어 3초 안에 서지도 못했어요.

대부분의 사람들은 앞서 커피 머신 사례와 달리 

이 사안만큼은 심각하게 받아들입니다.

왜 그럴까요? 

앞서 커피 머신 컵 사례의 경우는 

커피를 조금 빠르게 먹거나 늦게 먹거나 정도의 차이로만 받아들이지만 

자동차 브레이크 사례의 경우는 

탑승자의 안전문제와 직결되기 때문입니다.

***
이러한 상황을 고려하여 실시간 시스템은 

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

이렇게 두 가지 용어로 구분하고 있습니다.

소프트 리얼타임은 기준시간이 있고

기준시간 안에 시스템이 응답을 못하더라도

실패가 excuse, 즉 용서가 되는 시스템을 얘기하는 겁니다.

앞서 예로 들었던 커피 머신 컵 사례가

바로 소프트 리얼타임의 케이스입니다.

하지만 하드 리얼타임은 

약속한 완료 시간을 반드시 지켜야 되는 시스템을 말합니 다.

대부분의 RTOS는

소프트 리얼타임 뿐만 아니라 하드 리얼타임도 지원합니다.

자 그럼 잘 이해하셨는지 다음 질문에 답을 해보세요.
스마트폰은 하드 리얼타임 시스템일까요?
아니면 소프트 리얼타임 시스템일까요?

스마트폰은 하드 리얼타임을 요구하는 기기가 아닙니다.
스마트폰은 소프트 리얼타임을 요구하는 기기입니다.

이 스마트폰이 잘못됐을 때 사람이 사망할 수도 있습니까?
실시간 처리가 정확하지 않아서 

스마트폰 사용자가 다치거나 사망할 수도 있습니까?
그렇다면 하드 리얼타임이 맞아요.

다음은 미사일 시스템의 사례입니다.

미사일이 리얼타임 요구사항을 만족시키지 못해서 

크게 탄착지점을 벗어나서 엉뚱한 곳에 떨어졌다.

그래서 많은 인명이 죽거나 다쳤다.
이러한 이유 때문에 미사일은 분명한 하드 리얼타임 시스템입니다.

마지막으로 또 다른 예를 들어보죠.
우주 탐사 로켓 발사되었습니다.

천문학적인 돈이 투입된 로켓을 발사했는데 

그만 발사 직후 로켓이 공중에서 폭발하였습니다.

이 경우 로켓트를 발사 후 실패했다고 해서 

사람이 죽지는 않았지만 큰 돈을 잃어 버리기 때문에 

로켓은 하드 리얼타임으로 분류되는 겁니다.

소프트웨어 리얼타임의 요구사항보다는 

하드 리얼타임의 요구사항이 더욱 엄격 해야 할 것은 

굳이 따져보지 않아도 알 수 있는 것입니다.

하드 리얼타임 요구사항을 맞추기 위해서는 

상대적으로 더 많은 개발 비용, 시간, 개발 인력의 수준과 인원수, 

테스트 방법이 달라집니다.

커널의 시계(TICK)

정기적(PERIODIC)으로 일어나는 인터럽트

태스크 지연 (delayed), 타임아웃(timeout)을 제공

태스크 지연의 분해능(clock resolution)은 클럭 틱(TICK) 하나

클럭틱 단위 정확도로 지연 가능한 것은 아님

선점형 커널에서 가능

커널 내부에는 스케줄러가 있습니다.

스케줄러의 디스패처가 하는 일이 

테스크들에게 시간을 할당해 주는 겁니다.

그럼 커널에게는 시계가 필요하겠죠!
터널은 시계의 수단으로 

하드웨어 타이머 장치를 이용합니다.

하드웨어 타이머 장치를 올바르게 설정을 해서 

타이머 장치가 주기적으로 인터럽트를 발생하게끔 해줍니다. 

하드웨어 타이머 인터럽트가 발생될 때마다 
타이머 인터럽트 핸들러가 실행되겠죠.

보통 타이머 ISR 내부에는 

Static Unsigned Long Tick 이라는 변수를 증분하는 코드가 들어갑니다.
Tick++ 이런식으로 코드가 들어가는 것이죠.
Tick 변수의 변화가 시간의 흐름을 나타내는 것이죠.

임의의 시간을 확인하는 Tick 변수의 값은 현재의 시간을 나타냅니다.
한편 우리는 주파수를 헤르츠로 표시하는데

헤르츠가 1000이다라는 뜻은 
초당 인터럽트가 1000번 발생한다는 뜻입니다.


예를 들어 특정 변수 값이 2만 1000일 경우 
현재 시간이 21초임을 알려주고 있다고 할 수 있겠네요. 

그림에 따르면 하드웨어 타이머가 

인터럽트를 1초당 1000개씩 발생합니다.
커널은 이를 통해 밀리세컨드 단위 해상도를 갖는 

스케줄을 보유하게 된 셈입니다.
오차의 범위도 1000분의 1초가 된다는 점도 알아두면 좋겠죠.

만약에 인터럽트가 1,000개가 아니고 100개씩 발생된다면 
그만큼 스케줄러의 해상도는 낮아지겠죠.

타이머 해상도가 RTOS 커널의 동작에 미치는 영향에 대해서 앞으로 알아봅시다.

OS에서의 타이머는 시계로서의 활용 목적 외에 
태스크 지연, 각종 커널 이벤트의 타임아웃 등을 

처리하는 용도로도 사용됩니다.

비-블로킹 I/O 동작은 

태스크가 시스템콜을 호출했으나

점유하고자 하는 데이터를 즉시 가용하지 않을 경우 

즉각 리턴을 하는 것을 특징으로 합니다.

non-blocking IO는 뭘까요?

kbheat 함수는 getch 함수와 기능적으로 다른 점이 두 가지가 있습니다.

첫째, kbheat 함수는 getch 함수와 달리

키가 눌렸는지 안 눌렸는지만 확인해주는 함수입니다. 

즉, 키가 눌렸어도 어떤 키가 눌렸는지 까지는 알 수 없습니다.

둘째, kbheat 함수는 getch 함수와 달리 

non-blocking I/O 함수입니다. 

키의 상태를 가지고 즉각 리턴하는 특징을 가지고 있죠.

위와 같은 특징 때문에 

논블로킹 방식으로 키를 처리하고 싶다면

먼저 kbheat 함수를 이용해 키의 상태를 확인 후

키가 눌렸다고 판단되면 getch 함수를 다시 호출 해주어야 합니다.

논블럭이라고 하는 것은 무엇일까요?
이 함수 kbheat를 호출해도 

애플리케이션이나 태스크가 휴면 상태로 들어가지 않는 겁니다.

프로세스가 휴면 상태로 가지는 않고 

사용자가 키를 안 눌렀을 경우는 

그냥 함수 리턴을 하게 되는 겁니다.

이 방법을 사용할 경우, 그림처럼

kbheat 함수의 지속적인 호출이 필요합니다.

왜냐하면 non-blocking 방식이기 때문에 

태스크가 휴면 상태로 가지는 않거든요.

kbheat 함수의 호출은 즉각적인 반응을 보이게 돼서 

키가 눌렸니? 안 눌렸는데.

키가 눌렸니? 아니 안 눌렸어.

키가 눌렸니? 눌렸어.

이런 식으로 처리됩니다.

이런 처리 방식 때문에 

논블럭 모드에서는 태스크는 휴면하지 않습니다.

애플리케이션이 휴면하지 않고 

부정적인 답변을 계속 받다가 

언젠가는 긍정적인 답변, 즉 키가 눌렸음을 받죠. 

이 방식의 장단점을 이해해 봅시다.

다음 예시를 보시겠습니다.

non-blocking 함수 예시

여기서 main 함수는 휴면 가능한 함수입니다.
getch 함수 자체는 블록킹 함수입니다.
하지만 main 함수는 논블록킹 함수입니다.

kbheat는 어떤 키가 늘렸는지는 알려주지 않습니다.

키가 눌렸다, 안눌렸다만 알려줍니다.
어떤 키가 늘었는지는 결국 이 getch 함수를 불러야만 알 수 있습니다.

그러면 이것을 왜 이런 방법으로 구현했을까요?
non-blocking 만의 장점을 가지고 있기 때문이죠.

이것이 무슨 장점이 있는지 이해하시려면 

블록킹 방식의 코드가 어떤 불편한 점이 있는지를
먼저 이해하셔야 합니다.

이 함수는 어떻게 되나요?

Blocking I/O 함수의 예

이 함수는 블록됩니다.
이 함수로 인해 태스크는 휴면 상태로 가게 됩니다.


getch 함수를 실행해 버리면 

여기 밑에 부분에 있는 코드가 실행이 안됩니다.

루프 모드로 되어 있지만

루프는 태스크가 휴면에서 깨어나기 전까지는

실행이 안될 겁니다.

이게 블록킹의 장점이자 단점이죠.

장점은 뭘까요?
태스크가 이벤트를 기다릴 때 휴면하면서 기다릴 수 있다고 하는 것은 장점이에요.
CPU 시간을 사용하지 않으면서 기다릴 수 있기 때문에 장점이에요.

단점은 휴면 상태 있는 동안 아무 코드도 실행할 수 없어요.
이게 단점인 것입니다.

하지만 블록킹 모드가 아닌 논블록킹 모드에서는 

CPU 시간은 계속 사용하고 있죠.

휴면하지 않고 루프를 회전시킬 수가 있어요.

그래서 사용자가 키보드를 눌렀을 때 

이 안으로 진입해서 처리할 수 있게끔 하는 거죠.

이처럼 논블럭킹과 블럭킹의 차이를 이해하는 것은 

RTOS 프로그래밍에서는 필수적입니다.

블로킹 I/O 동작을 태스크가 시스템콜을 호출 했으나

점유하고자 하는 데이터가 준비가 되지 않을 경우

그 동작이 완료 될 때까지

'suspending(blocked)' 상태로 유지되는 것을 말함

운영 프로그램이 키보드 HW에 대해 알고 싶은 것은

한 가지 밖에 없을 것입니다.

사용자가 키보드가 어떤 것을 눌렀나?

애플리케이션/태스크는 함수 getch() 함수를 호출합니다.

이 함수는 애플리케이션/태스크에게 

키가 눌렸다/안눌렸다/어떤 키가 눌렸다 이러한

피드백을 줍니다.

사용자 키 처리 함수는 대개 두 가지 처리 방법이 존재합니다.

첫 번째 방법은, 사용자가 HW 버튼 키를 누를 때까지 대기한 후,

키가 눌리면 리턴하도록 구현하는 방법입니다.

두 번째 방법은, 사용자가 키를 누르든 안 누르든,

현재의 키 상태를 가지고 리턴하는 방법입니다.

전자의 경우는 블로킹 I/O 방식이라고 하며

해당 애플리케이션은 사용자가 키를 누를 때까지

휴면 상태에서 대기하게 됩니다.

이때 사용한 함수 getch()를 블로킹 함수라고 부릅니다.

후자의 경우는 논블로킹 I/O 방식이라고 하며

키가 눌리든 안눌리든 상관없이 

getch() 함수가 즉각적으로 리턴되기 때문에

애플리캐이션이 이 때문에 휴면하는 일은 없습니다.

kbhit() 함수가 그 좋은 예입니다.

[참고자료] https://blog.naver.com/sharonichoya/220875372940

어떤 상황에서 블로킹 I/O 함수를 사용하고

언제 논블로킹 I/O 함수를 사용하는지를

잘 알아야 합니다.

시스템 호출 (system call)

일반적으로 운영체제의 커널은

HW를 제어하는 SW 장치, 즉 장치 드라이버를 갖추고 있습니다.

운영체제는 애플리케이션이나 태스크가 

커널의 디바이스 드라이버를 

직접 호출할 수 없도록 막고 있습니다.

직접 호출할 수는 없지만 대신

시스템 호출 함수를 실행하는 것으로

그 목적을 달성할 수는 있습니다.

시스템 호출이 있게 되면,

커널은 내부적으로 시스템 호출 함수에 대응하는

커널 내부의 디바이스 드라이버를 동작시켜서

응용 프로그램이나 태스크의 요청에 응답해줍니다.

리눅스 운영체제는 

키보드의 어떤 키가 눌렸는지를 확인할 수 있도록 하기 위해서

이런 getch() 류의 함수들을 지원합니다.

아쉽지만 몇몇 상용 RTOS를 제외한 대부분의 RTOS에서는

시스템 호출과 디바이스 드라이버라는 개념이 없으므로

이런 것을 하려면 키보다 장치의 어떤 키가 눌렸는지 확인하는

일종의 펌웨어 코드가 필요합니다.

RTOS에는 시스템 호출과 디바이스 드라이버가 존재하지 않습니다.

인터럽트 (Interrupt)

- 비동기적 이벤트의 발생을 처리하기 위한 메커니즘

- 인터럽트 발생시 문맥을 저장하고 ISR로 점프

- 활성, 비활성화 가능

   비활성화 시간은 가능한 짧게 해야함

- 지연시간

  비활성화 최대시간 + ISR 최소 명령시간

인터럽트

HW에서 발생하는 비동기적 이벤트 발생에 대해

CPU가 대응되는 SW적인 처리를 수행하는 매커니즘


대부분 많은 인터럽트는

해당 인터럽트가 언제 발생하라 지 모릅니다.

타이머 인터럽트처럼

언제 발생할지 예측할 수 있는 인터럽트도 더러 있습니다.

CPU는 인터럽트가 발생하면, 현재 작업을 멈추고

인터럽트를 처리하기 위한 ISR 인터럽트 서비스 루틴을 실행합니다.

인터럽트 서비스 루틴 = 인터럽트 핸들러

필요할 경우, 인터럽트가 HW에서 발생하더라도

ISR이 실행되지 않도록 할 수 있는데

이것을 인터럽트 비활성화 라고 합니다.

그 반대말은 인터럽트 활성화 입니다.

대부분의 임베디드 시스템에서는

인터럽트를 지원하는 다수의 HW들을 사용하므로

이를 위해 별도의 인터럽트를 관리하는 장치를 필요로 하는데

그 장치를 인터럽트 컨트롤러 라고 합니다.

이 장치는 HW 주변 장치 사이에서

인터럽트 신호 전달을 중계하는 역할을 수행합니다.

인터럽트를 비활성화하는 방법에는 두 가지가 있습니다.

첫째, CPU로 입력되는 인터럽트 신호를

CPU 스스로 마스킹하는 것입니다.

이처럼 하면, 외부에서 들어오는 인터럽트 요청이

내부적으로 처리되지 않습니다.

이 경우, 인터럽트 요청에 대한 처리가

거절된 것이 아니고, 잠시 보류된 것입니다.

이후 CPU의 인터럽트 마스킹이 해제되기만 하면

보류되었던 인터럽트 처리가 즉시 시작됩니다.

이 보류라는 용어는, 전문용어로 인터럽트 펜딩 (Interrupt Pending) 이라고 합니다.

인터럽트를 비활성화하는 두 번째 방법입니다.

인터럽트 컨트롤러에 입력으로 들어오는 

개별적인 인터럽트 요청 신호를 마스킹하는 것입니다.

이 방법은 HW 주변장치를 필요할 경우, 

개별적으로 비활성화 할 수 있다는 점이

첫 번째 방법이었던 CPU 인터럽트 비활성화 방법과 비교됩니다.

인터럽트 지연 시간은 보통

인터럽트 레이턴시 (INTERRUPT LATENCY) 라고도 말하는데,

인터럽트 요청 신호가 발생한 이후부터

실제 인터럽트 핸들러가 실행을 시작하기 직전까지의

시간 길이를 말합니다.

통상 인터럽트 지연 시간은 짧을 수록

인터럽트 응답성이 좋다고 말합니다.

Priority 스케줄링

태스크를 중요도에 의해 가중치를 두어, 우선순으로 실행할 수 있도록 하는 개념

실시간 운영체제(RTOS)에서 펄스폭으로 지원하는 스케줄링 방법

선점형 스케줄링의 특성을 부여받음

우선순위가 높은 Task가 깨어나면,

현재 실행 중인 Task를 중단하고,

우선순위가 높은 Task가 선점

우선순위가 낮은 물고기가 먼저 실행된 이유?

악어가 태어나지 않았거나, 악어가 잠자고 있었거나.

악어가 선점을 하게 된 시점에는,

악어가 태어났거나, 악어가 잠에서 깨어났거나.

우선순위 스케쥴링과 선점형 스케쥴링은 

긴밀히 상호작용하는 하나의 원리.

악어가 실행되다가 어떻게 사람이 실행될 수 있었을까?

사람이 없었거나, 사람이 잠자고 있었을 것.

악어 Task가 우선순위가 낮음에도 불구하고

다시 실행할 수 있었던 이유는?

사람이 죽었거나, 사람이 잠자거나(waiting 으로 들어감).

스케쥴링 (scheduling):

처리할 일들의 진행 순서를 정하는 일

운영체제 커널이 하는 중요한 일 중 하나

각 Task들이 효율적으로 원할하게 실행되도록 하는 것

커널이 Task들에 CPU 시간을 할당해줌

프로세스, 쓰레드, 태스크

이 용어들이 엄밀한 의미에서는 

약간씩 다른 것을 표현하는 단어이긴 하지만,

동일한 의미로 이해해도 좋음