요즘 우리는 이동전화, PDA, 정보기기, 가전기기 등 수많은 임베디드 전자 제품들 속에 둘러싸여 있다. 이 모든 제품들은 결국 개발자의 노력과 땀에 의해서 만들어진 것들이다. 필자가 안타까워 하는 것은 개발자 중에 임베디드 시스템 개발자가 너무나도 부족하다는 사실이다.
필자의 바람이 있다면 능력있는 많은 개발자가 임베디드 시스템 개발에 관심을 가졌으면 하는 것이다. 앞으로 우리는 임베디드 시스템의 핵심이 되는 임베디드 OS에 대해 살펴볼 것이다. 임베디드 OS의 종류가 너무나 다양한 관계로 필자 주위의 특정 임베디드 OS별 전문가들과 함께 연재를 진행해 나가고자 한다. 먼저 이번 달에는 임베디드 OS의 기초적인 내용들을 다루며 앞으로 각각의 임베디드 OS를 개발자 입장에서 하나씩 다루고자 한다.
임베디드 OS란 무엇인가
임베디드 OS란 임베디드 시스템에서 사용되는 OS를 말한다. 그렇다면 임베디드 시스템은 무엇인가? 우리는 특정한 기능을 가진 전자제품을 만들기 위하여 하드웨어를 만들고 여기에 적당한 프로그래밍을 통해서 시스템을 완성한다. 이렇듯 미리 정해진 특정 기능을 수행하기 위해 컴퓨터의 하드웨어와 소프트웨어가 조합된 전자 제어 시스템을 말한다. 하지만 PC와 같이 다양한 기능을 수행하는 범용성을 지니는 컴퓨터 시스템은 일반적으로 임베디드 시스템에 포함시키지 않는다. 임베디드 시스템의 예를 든다면 TV, 냉장고, 이동전화 등과 같은 것들이 있다.
이러한 시스템 중에서 아주 간단한 제어기능을 수행하기 위해 8비트 MCU와 같은 프로세서로 개발되는 임베디드 시스템에는 운영체제를 사용하지 않는다. 간단한 기능을 위해 운영체제를 사용한다면 운영체제 자체에 들어 가는 비용뿐만 아니라 운영체제를 올리기 위한 저장 공간이며 운영체제가 사용하는 메모리 등의 하드웨어 비용이 추가되어 배보다 배꼽이 큰 경우가 되기 십상이기 때문이다. 하지만 근래 들어 이동전화나 셋톱박스, 네트워크 장비처럼 복잡한 기능을 수행하는 기기들이 늘어나고 자동차나 가전기기 등에도 사용자들의 요구가 많아지고 복잡해지자 임베디드 OS의 사용이 증가하게 됐다.
임베디드 OS는 어디에 사용되는가
임베디드 OS가 사용되는 곳은 너무나도 다양해 나열하기 힘들 정도이다. 위성과 같은 우주항공 분야는 물론이고 미사일, 레이더와 같은 군사용 제어장치나 자동차, 교통관리 시스템, 주차 관리 시스템, 로봇, 공장 자동화와 같은 산업용에도 사용되며 홈시큐리티, 사이버 아파트 등의 홈오토메이션에도 사용된다. 특히 우리 생활에 가장 가까이 있는 TV, 셋톱박스, 세탁기, 오디오 등의 가전제품과 이동전화기나 PDA와 같은 개인정보 단말기에 사용되고 있다. 이렇듯 우리 생활 어디에도 임베디드 OS가 사용되지 않는 곳이 없다. 하지만 우리는 임베디드 OS가 사용되고 있다는 것을 인식조차 못하고 있다.
그렇다면 왜 임베디드 OS를 사용해야 하는 것일까? 여기에는 중요한 몇몇 이유가 있다. 첫 번째 이유는 가격이다. 임베디드 시스템은 개인용 컴퓨터와 달리 프로세서의 성능이나 메모리 용량이 많아 시스템의 성능이 우수할수록 좋은 평가를 받는 것은 아니다. 단지 특정한 용도에 필요한 최소한의 기능만 적절히 수행하면 되는 것이다. 따라서 최소한의 리소스만을 사용한 시스템 구성을 통해 최저의 생산비용을 유지해야만 한다. 이것은 왜 수많은 임베디드 OS가 존재하는가 하는 의문에 대한 답이 될 수 있을 것이다. 즉 특정한 임베디드 시스템마다 가장 최적의 운영체제가 필요하기 때문이다. 하지만 특수한 의료기기나 산업용 시스템처럼 그 수요가 아주 적은 경우에는 제품 판매를 통해서 얻을 수 있는 수익보다 임베디드 OS를 이용해서 개발하는 비용이 큰 경우가 있다. 이러한 경우에는 일반적으로 많이 사용되는 범용 운영체제를 이용해서 개발하기도 한다.
임베디드 OS를 사용하는 또 다른 이유는 인공위성이나 미사일 제어 등과 같이 오류에 견고한 시스템이나 실시간 시스템을 위해 최적화된 운영체제가 필요할 경우이다. 이러한 경우에는 다양한 목적의 범용적인 운영체제보다는 RTOS(Real Time Operating System)와 같은 임베디드 OS를 사용한다
임베디드 OS에는 어떤 것들이 있는가
임베디드 시스템을 개발하려면 개발하려는 시스템이 어떠한 기능을 수행하는지 그 복잡도는 어느 정도인지 실시간성을 요구하는지 개발기간은 얼마나 필요한지 등에 따라 적당한 임베디드 OS를 선택하여 적용해야 한다. 따라서 그러한 임베디드 OS에는 어떠한 것들이 있으며 각각의 특징이 무엇인지 알 필요가 있다. 현재 나온 임베디드 OS는 그 종류가 무수하게 많은 편이다. 데스크톱 시장처럼 특정 OS가 임베디드 OS 시장을 점유하는 것이 아니기 때문이다. 수많은 임베디드 OS 중에서 주류를 이루고 있는 상용 RTOS, 윈도우 CE 닷넷, 윈도우 XP 임베디드, 임베디드 리눅스에 대해서 알아보겠다.
상용 RTOS
RTOS는 그 종류만 해도 수를 헤아리기 힘들다. RTOS는 실시간 처리에 대한 강력한 지원과 통합 개발 및 디버깅 환경을 지원한다. 대표적으로 화성 착륙선인 패스파인더(PathFinder)와 혼다에서 만든 로봇인 아시모(ASIMO)의 운영체제로 쓰인 윈드리버(WindRiver)의 VxWorks, ISI에서 개발해서 지금은 윈드리버에 통합된 pSOS, Mentor Graphics의 VRTX 등이 있으며 교육용으로 만들어진 uC/OS-II가 있다. 이들 RTOS는 선점형 멀티태스킹을 지원하며 각 태스크들은 우선순위를 가지고 있어 높은 우선순위를 가지는 태스크들이 먼저 실행되는 구조를 가지고 있다. 또한 통합개발환경과 디버깅 툴을 개발하여 개발자들에게 용이한 개발환경을 지원하고 있다. 단점이라고 하면 이들 RTOS들이 대부분이 상용이라 라이선스 비가 만만치 않다.
pSOS
ISI에서 1980년대에 개발한 pSOSystem은 우리나라의 여러 업체가 채택해서 사용하고 있는 RTOS로 삼성전자가 pSOS+ 개발에 참여해 라이선스를 갖고 있어 잘 알려져 있다. 삼성전자의 휴대폰에 사용되어 왔으며, 각종 통신장비와 네트워크 장비에서 사용되고 있다. pSOSystem은 커널을 중심으로 해서 여러 개의 소프트웨어 컴포넌트들로 구성되어 있다. 이들 소프트웨어 컴포넌트들은 각각의 독립적인 모듈로 되어 있으며 통합개발환경 툴로 pRISM+을 제공하고 있다.
pSOSystem은 멀티태스킹 RTOS로 각 태스크들은 우선순위를 가지고 있어 우선순위가 높은 태스크들의 작업 수행이 먼저 이루어진다. 따라서 선점형 스케쥴링 방식을 따른다고 볼 수 있다. 만일 각 태스크들이 같은 우선순위를 가진다면 스케쥴링 방식은 라운드로빈(Round-robin) 방식으로 바뀌게 된다. 태스크의 수는 총 256개이다. 그리고 태스크 관리, 세마포어(semaphore), 메시지 큐, 시간 관리 및 타이머, 이벤트 및 비동기 시그널, 에러 처리, 동적인 메모리 저장관리, 다른 태스크들로부터의 코드나 데이터 보호 등의 서비스를 지원한다. 여러 개의 다른 실행 모드를 가지고 있는 CPU를 위해서 사용자 모드와 슈퍼바이저 모드를 제공하고 있다.
pSOSystem은 실시간 멀티태스킹 커널을 중심으로 여러 개의 소프트웨어 컴포넌트와 라이브러리를 두고 있다. 이런 컴포넌트와 라이브러리는 선택적으로 사용될 수 있다. 하부 구조에는 디바이스 드라이버와 칩과 각종 디바이스의 정보를 담고 있는 BSP(Board Support Package)가 있다. BSP를 따로 구별하는 이유는 만일 하드웨어가 변경될 경우 시스템 프로그램에 큰 변경없이 BSP만 수정하여 쉽게 처리할 수 있기 때문이다. 따라서 전체적으로 정리해 보면 BSP와 디바이스 드라이버의 바탕 위에 커널과 기타 필요한 컴포넌트들을 링크하고, 다시 그 위에 사용할 각종 태스크와 응용 프로그램을 제작하여 사용하는 것이다. pRISM+는 pSOSystem 개발자가 좀더 용이한 개발을 위해 소스 코드 분석을 위한 툴과 컴파일러, 링커, 디버깅할 수 있는 툴을 제공하는 통합개발환경이다.
VxWorks
윈드리버의 RTOS인 VxWorks는 pSOSystem과 유사한 점이 많다. pSOSystem이 통합개발환경으로 pRISM+를 제공한다면 VxWorks는 토네이도를 제공한다. VxWorks의 커널인 마이크로커널은 선점형 멀티태스킹이며 총 태스크의 단계는 256, 스케쥴링 방식도 높은 우선순위를 가지는 태스크가 먼저 실행하는 방식을 지원한다. 만일 같은 우선순위를 가진다면 라운드로빈 방식의 스케쥴링을 이용하는 것도 pSOSystem과 유사하다. 또 하나 pSOSystem이 여러 개의 컴포넌트로 되어 있다고 하면 VxWorks는 200개 가량이 모듈을 지원하는 형식으로 되어 있어 개발자는 이들 필요한 모듈만 사용해서 시스템에 맞는 운영체제를 구성할 수 있다. VxWorks는 현대의 RTOS들이 지원하는 거의 모든 서비스를 지원하고 있다. 태스크간의 통신을 위해 세마포어와 메시지 큐, 공유 메모리, 소켓, 시그널 등을 제공하고, 표준 TCP/IP 네트워킹과 ROM이나 로컬 디스크, 네트워크로 부팅이 가능하게 되어 있다.
VxWorks의 구조는 크게 하드웨어에 의존하는 BSP, 디바이스 드라이브 영역과 하드웨어에 의존하지 않는 커널과 그에 따른 모듈, 그리고 애플리케이션 프로그램으로 나뉜다. 이것은 pSOSystem과 매우 유사한 부분이다. VxWorks의 토네이도는 교차 개발환경을 지원하는 통합개발환경이다.
윈도우 CE 닷넷과 윈도우 XP 임베디드
마이크로소프트(이하 MS)는 임베디드 시장에 대한 공략을 위해 1996년 윈도우 CE를 발표했다. MS에서 제작된 기존의 윈도우 인터페이스에 모바일 네트워크 기능을 강화해 가전제품, PDA, 셋톱박스 등에 주로 사용되고 있다. 적외선 통신, 웹 브라우징 기능 이외에도 편리한 개발환경을 가지고 있으며 UI가 기존의 윈도우와 매우 유사하게 제작돼 있어 대부분의 사용자들은 별도의 학습없이도 바로 사용이 가능하다. 또한 윈도우 CE 계열의 PDA는 흑백 및 컬러 디스플레이가 가능하며 동영상, WAV, MP3 등 멀티미디어 파일의 재생이 가능하여 PDA의 엔터테인먼트 기기화를 가져왔다.
또한 PC용의 윈도우 OS나 각종 오피스 프로그램들과 완벽한 호환이 가능해 기존의 데스크톱이나 노트북에서 가능하던 각종 애플리케이션들을 PDA에서도 그대로 사용할 수 있다는 이점이 있다. 그러나 제한적인 하드웨어를 가진 임베디드 시스템에 너무 많은 기능을 구현하려 했기 때문에 느린 실행 속도와 불편한 UI를 초래했다.
이를 개선해 MS는 2000년 4월 윈도우 CE 3.0을 개발하고 기존의 윈도우 CE와는 전혀 다른 것이라는 것을 강조하기 위해 그것을 포켓PC(PocketPC)라고 명명했다. 포켓PC의 등장으로 기존 윈도우 CE에서 보여주었던 수행속도의 저하와 비효율적인 하드웨어의 활용 등의 문제점들이 보완됐다. 윈도우 PC는 사운드와 동영상 재생 및 컬러 디스플레이 구현 등 다양한 멀티미디어 기능을 기본적으로 제공하며 PC와의 호환성이 뛰어나다. 또한 포켓 인터넷 익스플로러를 기본으로 내장해 모바일 인터넷을 실현했다. 게다가 데스크톱과 거의 흡사한 UI를 갖춤으로써 윈도우에 익숙한 사용자들을 쉽게 끌어들이고 있다. 그럼에도 불구하고 PDA 업계에서 윈도우 CE의 시장점유율은 팜 OS에 미치지 못했다. 하지만 유명 PDA 업체들이 윈도우 CE 채용 제품들을 대거 출시함에 따라 점유율은 계속 증가 추세에 있다.
MS는 윈도우 CE 3.0의 소스 코드를 공개한 후 2002년 초 코드명 탈리스커(Talisker)로 알려졌던 윈도우 CE 닷넷과 윈도우 XP 임베디드를 공식 발표했다. MS는 윈도우 CE 닷넷을 Non-X86 프로세서 계열이거나 실시간이 요구되는 시스템에 대해서 권고를 하고 있으며 PC 운영체제인 윈도우 XP 프로페셔널의 컴포넌트 버전인 윈도우 XP 임베디드는 네트워킹과 서버 기능을 수행하는 시스템 개발에 권고를 하고 있다.
임베디드 리눅스
리눅스는 초기 PC나 서버급 시스템에 포팅돼 사용되기 시작하다 현재는 임베디드 시스템으로도 많이 사용된다. 리눅스는 상용 임베디드 OS보다는 실시간적 요소를 충족하지 못하고 윈도우 CE보다는 개발환경이 좋지는 않지만, 오픈소스에 라이선스 비용이 없기 때문에 커널 크기를 줄여 다양한 임베디드 시스템의 개발에 유리하다. 리눅스는 소스를 공개하는 오픈소스 정책을 따르는 관계로 관련 개발자가 세계 곳곳에 있어 현지의 응용 프로그램을 개발할 수 있는 개발자 층이 넓다는 것이 다른 OS들과 구별되는 큰 장점이다. 이에 따라 리눅스를 채용한 임베디드 시스템은 다른 제품에 비해 가격 경쟁력이 우수하고 다양한 응용 프로그램의 개발이 가능할 것으로 기대된다. 임베디드 리눅스는 소스 공개와 아울러 안정성, 신뢰성 및 성능의 확보에 따라 활용도가 급격히 증대되고 있으며, 레드햇, 몬타비스타, 리니오 등이 임베디드 리눅스 개발 및 기술 지원 사업에 주력하고 있다.
그러나 임베디드 리눅스는 열악한 개발환경에 따른 개발기간에 대한 부담과 라운드로빈 방식의 스케쥴링을 하므로 실시간 시스템에는 적합하지 않다는 문제점을 가지고 있다. New Mexico Tech에서 기존 리눅스 커널에 실시간 기능을 추가한 RT-Linux를 개발했으며 또한 오픈소스 진영에서는 임베디드 리눅스를 기반으로 한 표준화를 통해 시장 확대를 도모중인데, 2000년에 애질런트, 알카텔, HP, IBM, 윈드리버, ARM, 모토롤라 등이 참여하는 세계 최대 규모의 임베디드 리눅스 컨소시엄(ELC: Embedded Linux Consortium)이 결성되어 임베디드 리눅스 및 실시간 운영체제 API 표준인 EL/IX(Em bedded Linux based on POSIX)를 기반으로 플랫폼 표준화를 추진하고 있다.
임베디드 운영체제 시장은 전통적인 RTOS 중심에서 다기능 임베디드 OS 중심으로 발전하는 추세에 따라 VxWorks, pSOS 등의RTOS의 시장 성장율이 둔화되고 있으며, 전용 실시간 임베디드 시스템에서 높은 시장 점유율을 보였던 VxWorks, pSOS, VRTX와 같은 전통적인 RTOS는 2001년을 기점으로 시장 점유율이 하락하고 있다. <그림 1>에서와 같이 2003년에는 임베디드 리눅스, 임베디드 윈도우 CE 및 팜 OS 등의 임베디드 OS 시장이 기존의 RTOS 시장을 능가할 것으로 예측된다. 전통적인 RTOS의 시장 점유 하락으로 임베디드 OS 시장에서는 MS와 임베디드 리눅스가 시장 선점을 위해 치열한 각축을 벌일 것으로 예상된다.
[그림 1] 임베디드 OS의 전망
임베디드 시스템 개발 관련 테크&팁
보통 임베디드 시스템 개발시 전체 시스템의 가격이나 소비되는 전력을 낮추기 위해 하드웨어 및 소프트웨어의 많은 제한을 가하게 된다. 따라서 임베디드 시스템에 사용하는 OS는 일반적인 범용 OS보다는 시스템에 특화된 운영체제를 사용한다.
[그림 2] 임베디드 시스템 개발 환경
임베디드 시스템 개발 환경
임베디드 시스템을 개발하기 위해선 기본적으로 <그림 2>와 같은 요소들이 갖춰져 있어야 한다. ‘호스트’는 임베디드 시스템 개발을 위한 컴퓨터를 말하며, ‘타겟’은 실제 임베디드 시스템이 설치된 개발하고자 하는 하드웨어를 말한다. 호스트에는 개발을 위한 개발 툴, 개발된 응용 프로그램을 임시로 수행해 볼 수 있는 타겟 시뮬레이터, 타겟과 연결되어 타겟에 개발된 이미지를 업로드하거나 타겟에 반응하는 디버그 에이전트를 통해 원격 디버깅을 할 수 있게 하는 타겟 서버가 설치돼 있다. 또한 타겟에는 호스트에서 만들어져서 설치된 여러 컴포넌트가 존재하는데 타겟을 부팅하기 위한 부트 로더와 커널, 그리고 임베디드 응용 프로그램이 존재하게 된다. 호스트에 설치된 개발 툴에는 타겟에서 수행될 수 있는 바이너리를 생성하는 크로스 컴파일러가 존재하며 그 밖에 오류를 검색해 주는 디버거 등으로 이뤄져 있다.
임베디드 시스템 개발 과정
임베디드 시스템 개발 과정은 대략적으로 부트로더 개발, 커널 및 파일 시스템 개발, 응용 프로그램 개발의 세 단계로 볼 수 있다.
부트 로더 개발
부트 로더는 타겟 보드에 전원이 인가되면 부트 롬으로부터 가장 먼저 수행되는 프로그램이다. 보통 부트 로더는 OS의 커널을 로드하는 순수 로더로서의 기능뿐만이 아니라 현재 레지스터나 메모리 값, 버스 상태 등을 살펴볼 수 있는 모니터 기능, 기초적인 네트워크 모듈을 내장해 네트워크를 통한 커널을 다운받아서 커널 로드를 할 수 있는 기능을 포괄하고 있다.부트 로더는 보통 부트 롬에 내장되어 있으며 부트 로더를 새로 작성하여 타겟에 설치하려면 호스트와 JTAG 인터페이스 혹은 기타 인터페이스를 통하여 설치할 수 있으며 이외의 방법에는 롬 라이터를 이용하여 롬에 구워서 설치할 수 있다.
[그림 3] 부트 로더의 구성
대부분 상용 임베디드 OS에서는 부트 롬 부분을 앞서 잠깐 언급한 BSP라 불리는 패키지의 일부분으로 규정하고 있다. 반면 임베디드 리눅스의 경우는 규격화된 BSP가 존재하지 않으므로 하드웨어 벤더가 리눅스용 BSP를 제공하지 않을 경우 부트 롬 부분을 각 하드웨어 플랫폼에 맞게 작성해야 한다.
커널 및 디바이스 드라이버 및 파일 시스템 개발
커널 및 디바이스 드라이버의 개발은 호스트의 임베디드 시스템 개발 툴에서 이뤄진다. 개발을 위해서는 개발자가 먼저 시스템에 대한 하드웨어 사양을 숙지해야 하며 이를 바탕으로 커널 및 디바이스 드라이버를 설정하게 된다. 이렇게 생성된 커널 및 디바이스 드라이버들은 부트 롬과 같이 하나의 이미지 파일 형태로 되어 부트 롬에 저장되거나 별도의 저장 장치에 파일 시스템을 통한 파일 형태로 구현된다. 만일 부트 롬의 용량이 작거나 기타 저장장치가 없는 경우 부트 로더에서 네트워크 모듈을 통해 별도의 서버로부터 커널을 다운받아 부팅이 진행될 수도 있다. 특히 부트 롬이나 저장장치의 용량이 제한적일 경우는 커널 이미지 자체를 압축해 저장되는 것이 일반적이다.
[그림 4] 커널 이미지가 저장되는 위치들
임베디드 응용 프로그램
임베디드 응용 프로그램은 앞에서 구현된 커널과 파일 시스템을 바탕으로 수행된다. 응용 프로그램의 개발은 커널과 마찬가지 방법으로 호스트에서 생성이 가능하며 호스트에 설치된 개발 툴의 크로스 컴파일러에 의해 타겟 보드에 맞는 바이너리가 생성되게 된다. 생성된 응용 프로그램의 실행은 임베디드 OS 개발 툴 내의 타겟 에뮬레이터나 실제로 타겟 보드에 옮겨서 실행이 가능하다. 또한 응용 프로그램은 네트워크를 이용한 원거리 디버깅을 이용하거나, JTAG 인터페이스를 이용한 디버깅을 통하여 에러를 확인해 볼 수 있다.
임베디드 OS의 주요 개념 및 테크&팁
임베디드 시스템의 성능이 커지면서 기존에 간단한 펌웨어 형식으로 구현되었던 임베디드 프로그램이 점차 해야 할 일이 많아지고 복잡하게 된다. 이는 순차적인 프로그램으로는 해결하기 어려운 단계로 발전하고 결국 임베디드 시스템에도 운영체제의 개념이 필요하게 된다. 임베디드 시스템의 대부분 특성상 실시간이라는 요소를 만족해야 하는 점 때문에 많은 임베디드 OS는 RTOS의 속성을 가진다. 다음에 설명하는 주요 개념들은 여러분이 임베디드 OS를 이용해 임베디드 시스템을 개발하기 위하여 반드시 알아두어야 할 여러 개념 중 중요한 개념들을 선정하여 설명한 것이다.
스케쥴러
임베디드 OS는 보통 태스크(Task)라 불리는 프로그램 수행 단위를 가지게 된다. 보통 임베디드 시스템에서는 복수 개의 태스크가 동시에 수행되는 환경을 가지게 되며 이때 OS 내부의 스케쥴러에 의해서 다음 번에 수행되어야 할 태스크를 선택하게 된다. 이때 사용되는 임베디드 OS의 스케쥴링 알고리즘으로는 다양한 알고리즘이 나와 있지만 구현상의 문제 등으로 인해 실제 대부분의 임베디드 OS에서는 우선순위에 기반을 둔 스케쥴링 알고리즘을 사용한다.
대표적인 우선순위 알고리즘으로 FIFO(First In First Out)와 라운드로빈 방식이 있다. FIFO의 알고리즘은 동일한 우선순위를 가진 태스크들이 존재시 먼저 시작한 태스크가 종료될 때까지 다음 번 수행된 태스크가 스케쥴링을 받지 못하는 스케쥴링 알고리즘이며, 라운드로빈 방식은 동일한 우선순위를 가진 태스크들이 존재할 경우 각각 미리 정해진 타임슬라이스(time-slice)만큼씩 차례로 스케쥴링이 되는 알고리즘이다.
프리엠티브 커널
프리엠티브 커널(Preemptive kernel)은 어떤 태스크가 수행되고 있을 경우 커널이 강제로 그 태스크의 수행을 중지시키고 다른 태스크의 기능을 수행시킬 수 있는 능력을 지닌 커널을 말한다. Non-pree mptive 커널에 비해 interrupt latency가 조금 길어지는 단점이 있긴 하지만 대부분의 임베디드 OS에서 프리엠티브 커널을 채택하는 이유는 우선순위가 높은 태스크가 먼저 수행될 수 있다는 점 때문이다. 이는 결국 커널의 안정성을 높게 유지시킨다는 점에서 좋은 점이 될 수 있다.
상호 배제
하나의 태스크가 한 자원을 점유하여 사용중에 또다른 태스크가 접근하여 사용중인 자원에 무단으로 접근 시도 변경을 가한다면 곧 그 자원은 예측불허의 상황으로 치달을 수밖에 없다. 이런 부분을 임계 지역(critical section)이라 명하며, 한 자원이 점유중일 경우 나머지 자원들은 점유하고 있던 태스크가 자원을 모두 사용하고 사용권을 반환하기 전까지 모두 접근이 지연돼야 하는 지역을 말한다. 따라서 임계 지역은 상호 배제(mutual exclusion)로써 보호해야 하며 임베디드 OS는 상호 배제를 위해 인터럽트 Enable/Disable이나 세마포어의 기능으로 임계 지역을 보호할 수 있다.
태스크 커뮤니케이션
임베디드 OS에서의 태스크들은 종종 서로 데이터를 교환해야 할 경우가 생기게 된다. 이럴 경우 태스크간 통신을 통하여 교환할 수 있으며 이 기능은 OS에서 지원하는 여러 도구들에 의해 수행이 된다. 대표적인 방법으로는 시스템 전역의 변수를 선언하여 사용방법이 있으나 이 경우에는 변수 자체가 임계 지역이 되므로 인터럽트 Enable/ Disable이나 세마포어 등으로 상호 배제를 해야 한다. 그 밖의 방법으로는 큐, 파이프, 메일박스, 공유 메모리 등이 있으며 이들은 커널에 의해 자동으로 상호 배제가 이루어짐으로 임계 지역이 보호된다.
다양한 임베디드 OS의 이해
지금까지 임베디드 OS의 개념부터 기본적인 개발방법과 주요 개념들에 대해 살펴봤다. 임베디드 시스템의 개발은 쉬운 일은 아니다. 하드웨어에서 운영체제 그리고 응용 프로그램까지 시스템의 바닥부터 끝까지 알아야만 하기 때문이다. 비록 모든 것을 혼자 개발하지는 않더라도 전체 시스템에 대한 개념을 가지지 못하고 있다면 어디서든 문제가 발생하고 있는 것이다. 다음 번에는 이슈가 되고 있는 임베디드 OS 하나 하나에 대해 좀더 구체적으로 살펴볼 것이다.@
