RTOS(Real Time Operating System)의 프로그래밍 기법

Embeded System

 

임베디드 시스템이란 프로세서들이 들어가서 동작하는 제어 시스템을 일컫는다. 보통 마이크로프로세서의 크기나 성능에 관계없이 마이크로프로세서가 삽입된(embeded) 시스템을 총칭하긴 하지만, 일반적으로 32bit이하의 마이크로프로세서를 사용한 시스템으로 그 범위를 한정한다. 보통 임베디드 시스템의 경우 전체 시스템 가격이나 소비전력을 낮추기 위해 시스템에 많은 제한을 가하는 특성이 있다. 그리고 범용 운영체제를 사용하기 보다는 특화된 실시간 운영체제를 사용하거나 혹은 운영체제없이 모니터 프로그램에 의해 로드돼 필요한 기능만을 수행하는 단일 프로그램으로 소프트웨어가 구성된다.

일반적으로 임베디드 시스템은 대량으로 양산되는 가전제품류와 소량 제작되는 제어 보드군으로 크게 나눌 수 있다. 양산되는 시스템 프로그램은 제품 제작에 들어가기 전 많은 테스트를 거치게 된다. 즉 제품 출시후에 문제가 발생해 회수하는 일이 없도록 안정적인 동작에 중점을 둔다. 또한 많은 시스템이 복잡한 사용자 인터페이스 보다는 간단하게 LED몇 개와 액정 디스플레이로 상태를 표시한다. 이러한 것들은 주로 시스템이 컨트롤 하는 것, 가령 통신 라인이나 제어 포트등의 오동작시 처리 여부와 장시간 동작시 안정성을 보장하는데 중점을 두고 개발된다.

 

RTOS

 

글 정병수 / 삼성소프트웨어 멤버쉽 bsjung@alpha.secsm.org

임베디드 프로그래밍을 하기 위한 기반 이론을 학습하기로 한다. 특히 임베디드 시스템 중, 리얼타임 OS(RTOS)를 중심으로 설명하며, RTOS 프로그래밍에 들어가기 앞서 기본 개념부터 리얼타임 임베디드 시스템의 설계까지 살펴본다.

최근 임베디드 시스템 분야에서 리얼타임 OS를 채택한 제품들이 점차 늘어가고 있다. 특히 네트워크나 멀티미디어가 시스템에 기본 사양으로 자리잡으면서 이제는 많은 시스템에서 채용하고 있는 실정이다.

이 글에서는 임베디드 시스템의 기본 구성 요소로 자리잡고 있는 RTOS의 프로그래밍 기법을 중심으로 설명할 것이다. RTOS 프로그래밍을 시작하기 앞서 기본적인 개념부터 살펴보도록 하자.

태스크와 멀티태스킹

UNIX를 써본 적이 있는 사람은 여러 사람이 한꺼번에 login을 해서 동시에 자신의 프로그램들을 수행할 수 있음을 알 것이다. 굳이 UNIX를 예로 들지 않더라도 Windows 시스템인 경우만 해도 사운드카드를 통해서 음악을 들으며 C compiler로는 compile을 수행하고 프린터로 문서를 출력할 수 있음을 알고 있다. 이때 음악 연주 프로그램, compiler program, 프린터 spooler 등이 태스크(Task)에 해당한다. 그리고 이처럼 여러 개의 태스크를 동시에(여기에서 말하는 의미는 어떤 기간을 말하는 것으로 어느 한 시점으로 보면 아님, multi processor system과 비교) 실행할 수 있는 것을 멀티태스킹이라 한다.

임베디드 시스템에서도 처리할 작업이 많아지면서 멀티태스킹을 적용하게 되었으나 앞에서 말한 것과는 차이가 있다. 일반적인 컴퓨터에서는 각 태스크들이 대부분 무관한 프로그램들이지만 임베디드 시스템에서의 태스크들은 하나의 큰 응용 프로그램을 논리적으로 나눈 것이다. 즉, 어떤 응용 프로그램이 수행되기 위해서는 여러 기능들이 동시에 수행되어야 할 필요가 있고 이를 순차적으로 프로그래밍 하기 어렵기 때문에 사용자가 프로그램을 쉽게 하기 위해서 도입한 개념이 바로 멀티태스킹이다. 하나의 응용 프로그램을 논리적으로 나누었기 때문에 기능상 매우 밀접한 관계가 있어 태스크 사이에 이루어지는 작업들이 매우 많다.

이처럼 일반 시스템과 임베디드 시스템에서의 멀티태스킹이 다른 의미를 갖지만 아래에서 설명하는 것은 OS에서 논의되는 일반적인 개념으로 어떤 시스템에도 적용할 수 있는 것이다.

context switching

우선, task1에서 하던 작업이 중단되고 task2가 수행되려 한다고 가정하자. task1이 완전히 종료가 된 상태라면 별 문제 없겠지만 중단된 것이기에 task2가 수행을 마치거나 중단되는 경우에 다시 task1을 수행하게 된다면 이전에 수행되던 상태를 알아야 할 것이다(이는 함수에서 함수를 다시 호출하는 경우와 비슷하다).

따라서 task2가 수행되기 이전에 task1의 상태를 저장해 둘 필요가 있다. 시스템에서 상태라는 것은 레지스터, 메모리, 하드 디스크 등에 저장된다. 이때 메모리 같은 자원은 태스크마다 나누어 쓰면 별 문제가 없을 수 있지만 CPU의 레지스터는 공유하는 자원이므로 구역을 나누어 쓸 수 없다. 따라서 상태를 저장해야 하는 가장 중요한 자원은 레지스터이다.

따라서 task1이 중단되기 전에 레지스터 값들을 task1의 stack에 보관을 하고 task2가 수행되고 다시 task1이 수행될 시점이 오면 stack에 저장되었던 값들을 레지스터로 옮겨와서 task1을 다시 수행하게 된다. 이를 context switching이라 한다.

Context switching이 이루어지는 동안은 실제 응용 프로그램에서 원하는 작업은 이루어지지 않기 때문에 overhead라고 볼 수 있다. 이것은 저장할 레지스터의 개수에 따라, 쓰는 프로세서 등에 따라 달라진다. Context switching에 걸리는 시간이 짧으면 짧을수록 좀 더 효율적인 OS라고 볼 수 있기 때문에 예전에 리얼타임 OS를 비교할 때는(현재도 그러하지만) 이 시간이 얼마나 짧은가가 매우 중요한 척도였지만 프로세서의 성능이 점점 좋아지면서 OS간에 차이가 줄어들고 있다.

커널

OS는 앞에서도 언급했지만 시스템 자원을 효율적이고 쉽게 쓰도록 하기 위한 소프트웨어이다. 이러한 OS의 기능 중에서도 핵심이 되는 부분을 커널이라고 한다. 이 커널에서는 앞에서 설명한 context switching, task scheduling, memory management 등의 작업이 수행된다.

스케줄러

멀티태스킹 환경에서 다음에 어떤 태스크가 수행될 것인지를 결정한다. 커널이라고 부르는 부분에서도 핵심적인 부분이라고 할 수 있는 것이 바로 스케줄러로 dispatcher라고도 한다.

일반 멀티태스킹 OS에는 여러 가지 스케줄링 기법이 있고 리얼타임 OS에도 이와 유사한 스케줄링 기법이 제안되었다. 그러나 구현상의 문제 등으로 실제 대부분의 리얼타임 OS에서 사용되는 스케줄링 기법은 우선순위 기반의 스케줄링이다. 이 중 FIFO(First In First Out)나 round-robin 방법이 주로 사용된다.

비선점형 커널

비선점형 커널(non-Preemptive Kernel)은 쉽게 말하면 커널의 기능을 수행하지 못한다고 할 수 있다. 즉 어떤 태스크가 수행되고 있을 때 커널이 중간에서 그 태스크의 수행을 중지시키고 다른 태스크를 실행시키는 등의 기능을 하지 못한다. 다른 말로 cooperative mult itasking이라고도 한다. 반면 선점형 커널(Preemp tive Kernel)에 비해 디자인하기가 쉽다.

선점되는 경우는 오직 인터럽트 서비스 루틴(Interr upt Service Routine : ISR)에 의해서이다. 이 때도 마찬가지로 인터렙트된 태스크로 제어권을 수동으로 넘겨주어야 하다.

비선점형 커널의 장점은 인터럽트 대기시간이 비교적 짧다는 것과 re-entrant function을 쓸 수 있다는 것이다. 그러나 태스크가 제어권을 넘기지 않으면 커널이 어떤 지시도 내릴 수 없기 때문에 태스크들이 잘 계획되어야 한다는 것이다. 따라서 우선순위가 높은 태스크도 무한정 기다릴 수 있으므로 리얼타임 시스템에서는 잘 사용하지 않는다. 우리가 알고 있는 운영체제 중 윈도우 3.1이 이러한 비선점형 커널을 사용한 예이다.

선점형 커널

선점형 커널은 특정 태스크를 중단시키고 다른 태스크를 수행할 수 있는 기능을 갖고 있다. 따라서 앞의 비선점형 커널보다는 구현하기 복잡하다.

그러나 이러한 구현의 복잡성에도 불구하고 대부분의 리얼타임 OS에서 선점형 커널을 채택하고 있는 이유는 우선순위가 높은 태스크가 먼저 수행될 수 있다는 점 때문이다. 즉 가장 우선순위가 높은 태스크는 가장 먼저 수행될 수 있는 것이다.

또한 비선점형 커널에서는 ISR에서 인터럽트된 태스크로 제어권을 손수 넘겨줘야 했지만 이 경우 ISR이 인터럽트된 태스크보다 높은 우선순위 태스크를 호출한다면 ISR이 끝나고 인터럽트된 태스크로 진행되지 않고 우선순위 태스크로 진행된다. 따라서 인터럽트된 태스크는 대기 상태가 되는 것이다. 따라서 앞으로 설명할 OS도 선점형 OS가 될 것이다.

RTOS와 Embeded Programming
윈도우 98이나 NT를 사용해서 시스템 제어를 하는 경우라면 운영체제를 과신한다거나 높은 실시간성을 요구하는 시스템이 아닐 것이다. 일반적인 운영체제는 기껏해야 ms 단위의 정확성으로 제어를 하지만, 통신기기나 정밀 제어의 경우 수십 마이크로초 단위로 정확하게 시간을 측정해야 하는 경우가 많다. 또한 인터럽트가 발생했을 때 해당 프로세스나 태스크가 수십 마이크로초 이내로 동작해야 하는 경우에는 일반적인 범용 운영체제로는 이러한 조건을 만족할 수 없다. 그래서 나온 것이 RTOS(RealTime Operating System)인 것이다. 그렇다고 해서 RTOS를 범용 운영체제에 실시간성을 부가한 것이라고 생각하면 곤란하다. 운영체제라곤 하지만 기껏해야 POSIX 레벨의 함수와 gcc급의 컴파일러, 적당한 소스 레벨의 디버거가 전부이다.

현재 국내에서 많이 쓰이는 RTOS로는 마이크로텍의 VRTX, ISI의 pSOS, WindRiver의 VxWorks등이 있고, 이 밖에 QSSL의 QNX와 같은 운영체제가 쓰이고 있다. 이들 운영체제의 경우 개발자 한 명당 라이센스 가격이 비싼것은 3000만원을 호가한다. 일반 운영체제와 달라서 구매자가 소수이고 개발비용도 만만치 않으며, 지원하는 마이크로 프로세서도 다양하기 때문이다. 비싼 가격문제로 인해 아주 복잡성을 갖는 시스템을 제외하고는 RTOS가 직접 적용되지 않는다. 개발은 RTOS상에서 하고, 실제 양산에 들어갈 때는 RTOS를 제게한 채 사용되는 경우가 많다고 한다. 결국 개발용 툴로 RTOS가 적용되기는 하지만, 한 대 혹은 수십대의 제품만 만든다면 RTOS를 그대로 사용해도 무방하다.

RTOS는 서로 워낙 많은 차이가 있기 때문에 작업 성격에 따라서 선택하기보다는 개발자가 익숙한 OS를 선택하는 경향이 있다. RTOS를 선택해도 임베디드 시스템상에서 직접 개발하지 않고 다른 범용 컴퓨터상에서 에뮬레이터나 디버거로 개발하는 시스템에 프로그램을 다운로드하거나 디버깅을 하게 되며, RTOS마다 개발 환경에 차이가 있다. 예를 들면 VRTX는 유닉스 환경에서 개발해야 하지만, 다른 RTOS는 윈도우 NT에서 개발하는 환경도 제공하고 있다. 화성 착륙선인 패스파인더의 운영체제로 쓰여서 유명해진 WindRiver의 VxWorks의 경우 가장 고가이긴 하지만 다양한 개발 환경을 제공하고 있다. 미국의 경우 임베디드 시스템 개발 회사의 50% 정도는 자체적으로 개발한 RTOS나 그것에 해당하는 프로그램을 독자적으로 개발하고 있으며, 앞서 언급한 RTOS들이 5% 내외의 비율로 시장을 조금씩 나눠갖고 있다.

이와같이 주도적인 RTOS가 나타나지 않는 이유는 임베디드 시스템 개발이 많은 노하우를 필요로 하며, RTOS를 비롯한 개발도구의 안정성이 높지 않아서 새로운 것을 선택하는 경우 개발 도구를 익히는데 들어가는 시간이 많이 소요되기 때문으로 추정된다.

이러한 상용 RTOS외에 공짜 RTOS도 있다. 가장 간단하면서도 그 간단함 때문에 널리 쓰이는 uCOS나 이미 그 안정성을 확보받은 RTEMS, GNU 컴파일러나 그 밖의 도구들을 지원하며 임베디드 시스템 시장에서 널리 알려진 시그너스사의 eCos가 그것이다. 이들 RTOS는 공개된 소스를 바탕으로 그 안정성과 기능을 향상시켜 나가고 있다.

pRISM+와 pSOS
ISI는 지난 80년이래 pSOS+와 다양한 컴포넌트 모듈과 편리한 통합 개발환경인 pRISM+를 공급하고 있다. 삼성전자가 pSOS+ 개발에 참여해 라이센스를 갖고 있어 비교적 우리나라에 잘 알려진 RTOS이다. 또 컴파일러 전문업체인 Diab Data, 소스 디버거 전문 업체인 SDS를 자회사로 두고 있어 컴파일러와 디버거 측면에서 상대적으로 높은 기술력을 자랑한다. 삼성전자에서 내놓은 웹스크린폰이 바로 pSOS 운영체제를 탑재하고 있으며 유명 네트웍 업체에서 전자업체까지 수많은 고객을 확보하고 있다.

ISI의 pRISM+는 임베디드 시스템 개발 환경의 요구 조건과 Time to Market에 바탕을 두고 설계된 제품으로, 기존 소스 코드를 프로그래머가 분석해 재사용할 수 있는 툴(SNiFF+)과 컴파일러, 링커, 디버거 등을 포함하고 있는 통합 개발환경이다. pRISM+는 제품을 보다 신뢰성 있고 탄탄하게 만들기 위한 시스템 레벨의 최적화 툴(ESp, 오브젝트 브라우저, RTA 스위트)과 사용하기 편리한 GUI및 커맨드 레벨(DOS Shell, KornShell, PrismShell)의 사용자 인터페이스, 툴 최적화 기능을 제공한다.