필자는 윈도우CE에 관련된 커뮤니티 활동을 많이 하는 편이다. 필자가 처음 윈도우CE를 시작 했을 때는 개발에 관련된 정보들이 지금처럼 많지 않았다. 윈도우CE에 관한 커뮤니티에서 비슷한 문제점에 대해 검색을 해 보거나 해외 뉴스그룹에서 정보를 찾아야 했다.

지금은 윈도우CE 개발자들도 많고 정보도 예전에 비해 많아져 개발하는데 어려움을 조금이나마 덜 수 있다. 하지만 아직까지도 PC에서의 프로그래밍이나 인터넷 프로그래밍같이 많은 정보가 있는 것은 아니다.

최근에 필자가 놀란 점은 생각보다 적은 인원이 한 프로젝트에 투입되어 개발이 진행되고 있다는 것이다. 1~2명의 엔지니어가 윈도우CE운영체제를 포팅하고, 5~6명의 인원이 응용프로그램을 만들고, 하드웨어 엔지니어 몇 몇이 네비게이션 시스템을 개발하고 있는 것을　봤다. 국내　엔지니어의　능력이 월등히 뛰어나다는 것은 감안한다　해도　정말　대단한　일이다．

하지만 다른 한편으로 생각해 보면 걱정이 되기도 한다. 필자가 속한 팀의 구성은 보통 10~15명의OS관련 엔지니어가 있고, 하드웨어 팀, 테스트 및 검증을 위한 SQA팀 등 3개 부서가 기본적으로 존재 한다. 여기에 생산을 생산 팀, 생산 시 테스트를 위한 생산 관리 팀 등 다양한 부서가 존재한다. 물론 프로젝트의 규모가 차이가 있지만 필자가 평소에 생각하고 있던 팀의 최소 구성인원과 커뮤니티를 통해 안 내용은 동떨어진 구성이었다.

중소기업의 어려운 환경상 많은 엔지니어를 투입하여 개발하지 못하는 것은 당연하다. 여기에 대해서는 뭐라 할 말이 없다. 이런 어려운 환경에서도 좋은 제품을 만들어 많은 수출을 하고 해외에서도 선전을 하고 있다는 사실에 찬사를 보내고 싶다.

문제는 임베디드 시스템의 특성상 프로세서의 안정성을 확보하는 데는 시간과 노력이 필요하다는 사실은 변함이 없다는　것이다. PC와 같이 오랜 시간에 걸쳐 축적된 하드웨어 및 소프트웨어 설계 기술을 바탕으로 표준화된 규격으로 제품을 만들 때는 문제가 못된다.

하지만 임베디드 시스템의 하드웨어나 소프트웨어 모두 표준화된 개발 방법론이 없기 때문에 개발하고 안정화 하는데 시간이 많이 걸린다. 따라서 제대로 시간과 리소스를 투자하지　못하면　　좋은 제품이 될 수 없고, 이러한 제품을 만드는 환경은 제품 개발에 제대로 투자할 수 없는 악순환을 하게 되는 것이다.

항상 나쁜 점만 있다고는 생각지 않는다. 열악한 환경에서도 좋은 제품을 만들어내 국내뿐만 아니라 해외에서도 좋은 결과를 거두고 있기를 바라겠다.

이제는 윈도우CE의 개발의 기본이 되는 BSP에 관하여 알아보도록 하겠다.

1. BSP는 무엇인가?
BSP에 관해서는 워낙 많이 소개 되었기 때문에 윈도우CE를 개발하는 개발자뿐만 아니라 많은 사람들이 알고 있을 것으로 생각한다. 한번 더 정리해 보자면, BSP는 Board Support Package라고 해서 윈도우CE 운영체제 중에서 프로세서 부분(또는 하드웨어와 직접적인 연관이 있는)을 따로 만들어 놓은 부분을 이야기 한다.　

MS에서 제공하는 윈도우CE 운영체제는 하드웨어와 관계가 없는 OS 부분만 제공한다. 즉, 운영체제로써 동작하는데 필요한 스케줄링, 메모리 관리, 프로세서 관리 등 OS 영역의 부분만 들어있는 것.

하지만 윈도우CE는 다양한 제품, 프로세서에서 동작할 수 있다. 그것은 윈도우CE 운영체제가 BSP를 통해서 다양한 하드웨어에서 동작할 수 있기 때문이다. BSP는 윈도우CE운영체제가 하드웨어에 종류나 형태에 관계없이 동작하도록 해주는 소프트웨어 부분이라고 생각하면 된다.

BSP는 다양한 형태로 제공된다. 프로그램 형태로 설치하여 사용할 수 있도록 제공되기도 하고 압축 파일 형태로 제공되기도 한다. <그림1>은 플랫폼 빌더 내에 설치된 BSP를 보여준다.

<그림1 - BSP 디렉토리.JPG>

<그림2>는 위와 같이 설치된 BSP가 플랫폼 빌더 내에 Catalog 보기를 통해 BSP에 포함된 컴포넌트들이 어떻게 구성되는지 보여주는 화면이다.

<그림2-PB내BSP.JPG>

2. BSP는 윈도우CE에만 있는가?
물론 아니다. BSP는 윈도우CE 운영체제가 나오면서 많이 알려졌다. 하지만 다른 임베디드 시스템용 운영체제에서도 BSP라는 개념은 있었다.

이전의 임베디드 운영체제의 장점을 취해서인지 모르겠지만 윈도우CE용 BSP는 좀 더 체계화 된 형태를 보인다. 임베디드 시스템용 운영체제의 발전을 BSP도 따라 간 것이다. 운영체제 부분과 하드웨어에 직접적으로 관련 있는 부분과의 철저하게 분리하는 것이 그 첫 단계가 되겠다. 다음단계는 하드웨어에 맞추어 좀더 운영체제를 쉽게 포팅 할 수 있도록 만드는 것이다.

윈도우CE용 BSP는 이러한 점에 주안을 두어 OAL(OEM Adaptation Layer)이라는 특정한 영역을 만들었다. 여기에는 각종 함수 및 처리 부분을 두어 하드웨어에 맞추어 변경할 사항을 수정할 수 있도록 했다. 윈도우CE를 사용할 개발자들은 OAL 영역에 대한 처리 방법만 알면 손쉽게 윈도우CE 운영체제를 포팅 할 수 있게 했다.

3. 윈도우CE 개발 환경이 PC의 그것과 다른 이유
임베디드 시스템은 그 범위가 다양하다. 우리가 사용하는 리모컨에서부터 PC에 이르기까지 다 임베디드 시스템이라 부를 수 있겠다. 하지만 윈도우CE를 사용하는 임베디드 시스템은 몇 가지 제한적인 요구조건이 있다. 이러한 사항들은 동일하게 윈도우CE를 사용하는 임베디드 시스템에서도 적용된다.

-임베디드 시스템은 표준화된 개발 방법이 없다. 원도우CE 운영체제도 마찬가지다. 이는 임베디드 시스템 운영체제 보다는 임베디드 시스템의 하드웨어에 관련된 문제다.

-임베디드 시스템 하드웨어의 장치들은 구성하기에 따라 너무나 다양하다. 물론 PC도 마찬가지로 주변장치가 많다. 하지만, IDE, PCI, USB와 같은 표준 인터페이스를 바탕으로 주변장치를 개발하기 때문에 PC의 환경에 따라서 문제가 되는 경우는 없다.

-PC 주변장치 메이커는 디바이스 드라이버를 주변장치와 함께 제공하지만 임베디드 시스템의 경우에는 제공하지 않는 경우가 있다. 제공하더라도 그냥 쓸 수는 없고 임베디드 시스템의 하드웨어 구성에 따라 수정해야 한다.

-임베디드 시스템은 제한된 리소스를 바탕으로 개발된다. PC 운영체제는 용량, 크기 등에 관한 제한으로부터 비교적 자유롭다. 하지만 임베디드 시스템은 메모리의 크기가 어떠한지? 어떠한 프로세서를 사용하는지? 플래시 메모리의 크기는 어떠한지? 세부적인 조건에 따라 동작할 수 있도록 만들어져야 한다. 이러한 제한된 점이 PC와 임베디드 시스템의 가장 큰 차이점이라고 볼 수 있다.

하지만, 위에서 언급된 임베디드 시스템과 PC와의 차이는 어디까지나 차이점으로 인식되던 몇 가지를 나열한 것뿐이다. 이제는 임베디드 시스템의 성능도 날로 발전되어 가고 있기 때문에 조만간 PC와 임베디드 시스템의 차이점이 모호해지는 시대가 올 것이다.

4. BSP와 임베디드 시스템과의 관계
BSP는 '정책과 조례'이다. 프로세서 업체는 프로세서의 성능을 최대한 잘 이용하기 위한 정책과 같은 방법을 BSP를 통해 제공해 주고, 개발자는 이 정책에 따라 잘 동작하도록 세부적인 조례를 만들어야 하는 것이다. BSP에 포함된 내용을 살펴 본다면 다음과 같다.

-개발보드를 초기 동작시키기 위한 부트로더
-LCD나 터치 패널을 동작 시키기 위한 디바이스 드라이버 소스
-오디오, LED, USB 등을 동작시키기 위한 디바이스 드라이버 소스
-전원 사용을 최소화하기 위한 전원관리 루틴
-개발보드에 따라 변경해야 할 OAL 영역 소스
-프로세서 제어를 보다 효과적으로 하기 위한 소스
-윈도우CE 운영체제를 만들기 위한 각종 설정파일
-메모리의 크기, 종류, 영역을 지정하기 위한 지정 파일

이 밖에도 BSP는 많은 내용이 있다. 이 내용 또한 프로세서에 따라, BSP 제작 업체에 따라 다르다. 윈도우CE 5.0 버전 이후부터는 PQOAL(Production-Quality OEM Adaptation Layer) 형태의 BSP로 구조를 바꾸었다.

이것은 좀 더 안정적인 BSP를 제공하여 제품에 바로 적용하여 사용할 수 있는 BSP 구조로 만들고자 새롭게 등장한 방식이다. 윈도우CE 5.0부터 제공된 BSP들은 이전 BSP와 달리 일정한 디렉토리 구조, OAL 형태 등을 가지게 된다.

5. BSP만 가지고 제품을 만들 수 있는가?
대부분의 업체는 프로세서 업체로부터 개발보드와 BSP를 입수하고 개발을 시작한다. 그럼 과연 프로세서 업체에서 제공해준 BSP와 개발보드만 가지고 개발을 하고 제품을 만들 수 있는가? 여기에 대한 대답은 가능할 수도 있고, 아닐 수도 있다는 애매한 형태로만 나올 수 있다. 윈도우CE를 여러 번 다루어본 업체나 개발자의 경우에는 가능할 것이지만 초보자의 경우에는 불가능하기 때문이다.

필자도 처음 윈도우CE를 이용한 제품을 개발할 때 프로세서 업체에서 제공해준 BSP를 가지고 개발을 시작했다. BSP를 플랫폼 빌더에 설치한 후에 OS 이미지를 만들어 보고 동작시키는 과정을 통하여 개발을 시작했다. BSP에 하드웨어 관련된 OAL 부분을 수정하고, 부트로더를 BSP에 맞게 수정하고, 인터럽트 처리 루틴을 추가하고, 제공되지 않는 디바이스 드라이버를 추가하는 식으로 개발을 시작했다. BSP에 없는 새로운 드라이버를 개발해야 하고, OAL이나 부트로더를 하드웨어에 맞게 수정하려면 어느 정도 하드웨어 및 소프트웨어 지식이 필요하기 때문이다.

이런 연유로 BSP만 가지고는 제품을 개발하기 힘들지 않을까 하는 생각이다. 최근에는 프로세서 업체들의 적극적인 정책으로 제품으로 바로 만들 수 있는 상태의 BSP를 제공하고 있다고 한다. BSP는 어디까지나 제품 개발을 위한 초석이다. 이 초석을 잘 다지고 가꾸는 것은 각 회사며 개발자의 일일 것이다.

6. BSP구조는 어떻게 되어 있는가?
제공되는 BSP는 앞에서 언급한 것처럼 크게 4개의 부분으로 구성되어 있다. 부트로더는 NAND와 같은 플래시 메모리에 저장되어 있는 윈도우CE 운영체제 이미지를 RAM으로 복사해서 동작 시키는 역할을 한다.

OAL 영역은 윈도우CE 운영체제와 하드웨어를 연결하는 함수들을 모아둔 곳이다. 각종 장치들을 동작시키기 위한 디바이스 드라이버 영역, OS의 크기 설정 등을 관리하는 OS 설정 영역 등으로 분류한다.



7. BSP에서 먼저 해야 할 것들
필자가 초기에 BSP를 내용을 간략히 정리한다면 다음과 같다.

-BSP 구조를 파악한다.
-플랫폼 빌더에서 OS 이미지를 만들어 보고 문제점이 없는지 확인한다.
-BSP의 부트로더와 OAL부분을 하드웨어에 맞추어 수정한다.
-BSP에 포함되지 않은 드라이버를 추가시킨다.
-OS 구성 및 설정을 개발 환경에 맞추어 변경한다.

개발자마다 프로그래밍 스타일이 다르듯이 제공된 BSP도 업체마다 다르다. 프로세서의 차이도 있지만 BSP를 개발한 업체가 지향하는 방향에 따라 많이 달라지기 때문에 BSP의 내용을 파악하는 것은 가장 중요한 일이다.

BSP의 내용을 가장 먼저 파악하기 위해서 해야 할 일은 BSP에 첨부된 문서를 읽는 일이다. 어떻게 BSP를 설치하는지, 어떠한 기능이 되고, 어떤 기능이 안 되는지 먼저 확인하는 것이다. 필자 역시 가장 많이 하는 실수 중 하나가 제품 설명서를 안 보고 시작하는 것이다.

BSP는 프로세서 업체에서 제공해준 하나의 제품이다. 제품을 어떻게 사용할지 자세히 설명된 매뉴얼을 읽지 않고 BSP를 다루는 것은 문제가 있는 것이다. BSP에 첨부된 문서를 통해 BSP에 관한 기본적인 내용을 파악하기를 바란다. 필자도 하루 종일 해결 못하던 문제가 BSP에 간략히 설명된 것을 본 일이 있다. 매뉴얼만 잘 읽었어도 하루라는 시간을 낭비하지 않았을 것이다. BSP 매뉴얼을 먼저 읽어라! 그것이 윈도우CE 개발의 시작이다!

BSP에 포함된 문서의 내용 중 중요한 또 하나는 구현된 기능이 무엇이고 아직 안 되는 기능이 무엇인지 설명한 부분이다. BSP를 완벽한 상태에 모든 기능이 제공되는 형태로 생각할 수 있다. 하지만 새로 나온 프로세서의 초기 버전의 BSP에는 일부 기능이 안 될 수 있다.

또한 매뉴얼에 언급되지 않은 문제들이 있을 수 있다. 제공된 BSP는 프로세서 업체의 한정된 개발 인원으로 개발한 것이기 때문에 문제가 발생할 여지가 충분히 있다. 이러한 점을 충분히 인식하고 개발을 시작해야 한다. BSP를 이용하여 윈도우CE 운영체제 이미지를 만들어 개발보드에 장착하고 동작시키면서 테스트를 해 봐야 한다. 그러면서 문제점을 확인해야 하는 것이다.

BSP는 완벽하지 않다. 보완해야 한다. 이런 점을 먼저 알고 시작해야 한다.

8. BSP에서 하지 말아야 할 것들
BSP로 하지 말아야 할 가장 중요한 것은 프로세서 업체에서 만든 정책을 파괴하는 일이다. BSP는 프로세서를 가장 잘 아는 프로세서 업체에서 만들었다. 따라서 BSP에는 프로세서를 가장 잘 이용하기 위한 방법으로 작성되었다. 프로세서의 최적 성능을 얻기 위한 방법, 프로세서의 가장 안정적인 하드웨어 설정, 프로세서 동작 시 가장 저 전력으로 동작하기 위한 설정 방법들이 기록되어 있다.

이러한 소프트웨어적인 구현을 무시하고 고유의 방법으로 개발하거나 새로운 방법으로 다시 하는 방식들을 하지 않을 것을 권한다. 필자가 속했던 팀에서도 전원관리에 관한 BSP의 정책을 제대로 이해하지 못한 체 개발을 진행하다가 결국 새로 작성해야 했던 경험이 있다.

윈도우CE의 동작 방식뿐만 아니라 BSP가 가지고 있는 동작 방식을 먼저 이해하고 따라야 한다는 큰 교훈을 얻은 경험이었다. 하지만 BSP 역시 완벽하지 않기 때문에 보완해야 할 부분이 분명 있을 것이다. 보완이나 수정하기 전에 BSP에 관하여 자세히 아는 것은 가장 중요한 점임을 명심하기 바란다.

9. BSP에 중요한 파일들
앞에서 말한 것과 같이 BSP는 여러 가지 윈도우CE 운영체제를 위한 다양한 파일을 가지고 있다. 각종 드라이버들도 중요한 파일이지만 윈도우CE를 구성하는 3가지의 파일에 대해 먼저 알아야 한다.

PC용 응용프로그램을 개발 할 때는 PC상에서 메모리가 어떨지, 어떠한 형태로 동작할지에 대한 관심이 없다. 하지만, 임베디드 시스템에서는 이러한 부분에 먼저 관심을 가져야 한다. BSP 디렉토리내의 \FILES 아래 존재하는 3가지 파일들은 윈도우CE 운영체제를 설정하고 관리하는 중요한 3가지 파일이다.

-config.bib : 이 파일은 생성되는 윈도우CE 운영체제 이미지가 메모리상에서 어떠한 시작 주소를 차지하고 있으며 어느 정도의 크기를 갖는지 지정하는 파일이다. 다음 그림은 'NK'라는 이름의 윈도우CE 운영체제 이미지가 메모리상에서 어떠한 시작 위치를 가지고 있으며, 크기는 어떠한지 지정하는 예제이다. 이와 같이 config.bib 파일은 운영체제 파일이 메모리상에서 어떻게 차지할지 지정하는 파일이다.



-platform.bib : 이 파일은 윈도우CE 운영체제 이미지에 포함되는 파일을 지정하는데 사용된다. 어떠한 실행 파일이 포함되고, 어떠한 DLL 파일이 포함되는지 지정할 수 있다. PC용 일반 응용 프로그램은 ‘.EXE’나 ‘.DLL’이라는 확장자를 가진다. 마찬가지로 윈도우CE용 응용 프로그램도 개개의 파일들은 동일한 확장자나 파일 형식을 가지지만 NAND와 같은 플래시 메모리에 저장되고 실행되기 위해서는 운영체제 이미지에 어떠한 파일을 포함하고 있어야 하는지 지정하여야 한다.

이러한 기능을 하는 것이 Platform.bib 파일이고, 윈도우CE를 구성하고 있는 중요한 부분이다.




-platform.reg : PC용 XP 운영체제와 같이 윈도우CE 운영체제에서도 레지스터리를 이용하여 운영체제 동작에 필요한 중요 정보를 저장해 둔다. 어떠한 드라이버를 먼저 실행시키고, 어떤 프로그램을 동작시킬 것인가를 이 레지스터리를 통하여 지정하게 된다.



10. BSP에서 해야 할 OAL 작업들
지금까지 BSP에서 해야 할 일들에 대해서 간략히 살펴 봤다. 그 밖에 OAL에서 해야 할 일들을 추가로 정리해 본다면 다음과 같다.

-이더넷 디바이스 드라이버 관련 : 앞서도도 설명했듯이 부트로더에서 이더넷을 통하여 OS를 다운로드하고 디버깅하기 위해 사용. 개발 하드웨어에 맞추어 이더넷 디바이스 드라이버 수정

-플래시 메모리 : OAL 함수에는 플래시를 읽고, 쓰고, 지우는 함수가 존재한다. OS는 이 함수를 이용해 운영체제나 부트로더에서 플래시에 대한 처리를 하게 된다. 개발보드에 사용한 플래시 메모리에 맞게 OAL 함수를 수정해 주어야 한다.

-인터럽트 처리 : 개발보드에 맞추어 인터럽트 처리 루틴을 수정해 주어야 한다.

-IOCTL : 시스템 기능을 이용하기 위한 OEMIoControl() 함수를 호출했을 때 처리하는 부분.

-RTC(Real Time Clock) : 내부 시간 관리 함수를 처리한다.

이밖에도 BSP에서 처리해야 할 내용은 그 종류마다 다르다. BSP내 함수들의 구현 여부를 확인하고 미진한 부분은 추가 및 구현해야 한다.

11. 전원관리 이야기
BSP에서 가장 중요한 부분의 하나는 전원 관리 부분이다. PDA나 스마트 폰의 경우 동작시간이 중요하기 때문에 전원 관리를 잘 할 수 있도록 처리해야 한다. 기본적으로 제공되는 BSP의 경우 프로세서 업체에서 제공하는 개발보드에 맞추어 전원관리를 작성하였기 때문에 실제 개발한 보드에서 동작시켜보면 제대로 동작 안 할 수 있다.

따라서 전원 관리를 위해서 어떠한 절차를 따르는지, 장치를 어떻게 끄고 켜는지에 대한 이해가 필요하다. 장치의 전원 관리는 중요한 문제지만 개발 초기에는 간과하고 진행 하는 경우가 많다. 항상 켜 있는 시스템의 경우 크게 고려하지 않아도 된다. 하지만 좀 더 전원을 절약할 수 있는 시스템을 만든다면 좋지 않을까?

12. 그 밖의 BSP 이야기
지금까지 BSP에 관하여 여러 가지 내용을 살펴봤다. 현재 출시되는 윈도우CE용 BSP는 많은 기능을 탑재하고 개발자에게 제공된다. BSP만 있으면 제품을 바로 만들 수 있는 수준까지 제공이 된다고 한다.

제품을 위해서는 BSP가 가지는 기본 기능 이외에 '안정성'이라는 항목이 하나 더 붙어야 한다. 그래야 비로써 제품으로서 인정받고, 팔릴 수 있는 것이다. 안정성을 얻기 위해서는 윈도우CE 운영체제에 대한 이해와 많은 테스트가 필요하다. 윈도우CE운영체제에 대한 제대로 된 이해를 통하여 BSP의 OAL 영역과 드라이버를 제대로 작성할 수 있는 것이며, 많은 테스트를 통해 혹시나 있을 오류를 찾아 낼 수 있는 것이다.

어려운 환경에서도 좋은 제품을 만들어내는 엔지니어들의 노력이 결실을 맺기 바라며 BSP에 관한 이야기를 줄이도록 하겠다. @

필자는? 필자 라영호는 2007, 2008 Microsoft Windows Embedded 분야 MVP이다. 윈도우 모바일 관련 스마트폰 개발과 윈도우CE 관련 장치를 개발하고 있다. 개인적으로 운영하고 있는 윈도우CE에 관한 블로그(www.embeddedce.com)를 통해 윈도우CE 개발에 대한 다양한 생각과 방법론을 함께 생각해 보고자 노력 중이다. 최근에는 윈도우CE를 이용해 어떻게 빠르고 안정적인 시스템을 만들 것인가를 고민하고 있다. 아울러 윈도우CE의 포팅 뿐만 아니라 개발에서부터 최종 제품이 나오기까지 거쳐야 할 다양한 테스트 및 신뢰성 문제에도 관심을 가지고 있다. 조만간 윈도우CE에 대한 다양한 강좌 및 테스트에 관한 내용을 알릴 예정이라고 한다.