Superstar's New World

Platform Builder에서 좌측의 카탈로그 아이템 뷰(Catalog Items View)를 보면 수많은 카탈로그 아이템들이 있는 것을 볼 수 있다. 솔직히 너무 많이 뭐가 뭔지 잘 모르고 사용하고 있다.
대충 보고 이거다 싶으면 추가시키는 형식이다... ㅡㅡㅋ


이제는 이녀석들이 어떤 녀석들인지 조금이라도 알고 사용하고자 한다. 아는게 힘이니깐... ㅋ
것보다 사용하지도 않는 것들을 추가시켜 용량을 이미지의 용량을 늘리는 쓸데없는 짓을 방지하기 위한 차원이랄까?? 뭐 대충 그런거다.

MSDN을 보면 Catalog Items에 대한 간략한 설명이 있는 곳이 있어 링크한다.

위의 링크를 클릭하면 아래와 같은 페이지를 볼 수 있으며, Catalog Items에 대한 정보를 얻을 수가 있다.


이 웹페이지를 참고해서 필요한 녀석들을 추가하도록 하자!!

Windows Embedded CE 6.0에 'Network Projector' 라는 녀석이 있다.

네트웍을 통해 회의장과 같은 곳에서 RDP를 이용하여 원격으로 프리젠테이션을 할 수 있는 기능을 가지고 있다. 쉽게말해 Network Projector 기능을 장착하고 있는 기계에 PC가 접속하여 현재 PC 화면의 내용을 네트웍을 통해 그기계의 출력을 할 수있는 디바이스(모니터, LCD패널, 빔프로젝터 등)로 출력을 하는 것이다.

이녀석은 특이하게 Windows Vista기반의 PC하고만 연동하여 사용된다. 다른 운영체제(XP)에서는 사용을 할 수 없다.

단순한 프리젠테이션 용도로만 사용되는 듯하다.
VMWare에 Vista를 설치했고, 무선인터넷을 사용한 테스트 환경이라 그럴 수도 있지만... 테스트를 해본 결과 성능이 그리 좋지는 않았다.
프리젠테이션 파일이나, 도큐먼트 파일의 경우 별 무리없이 출력을 해내지만, 동영상과 같은 많은 움직임을 갖는 데이터의 경우 상당히 버벅거린다는..ㅡㅡ;

그냥 처음보는 기능이라 테스트를 해보았을 뿐.. 잘만 이용하면 쓸만한 제품이 나올것 같기도 하다.

Windows Embedded CE의 update사이트를 소개하려 한다.

기본적으로 Platform Build를 설치하고 나서 꼭 해주어야 하는 작업이기에...
CE로 이미지를 제작하다 보면 여러 에러를 볼 수 가 있는데.. 여기 저기 서칭하다보면 자주 듣게되는 말이 QFE를 설치하라는 말이 있다.
이 QFE를 통해서 Windows CE관련 업데이트를 하게 되는 것이다.

Windows Embedded CE Update Site


오늘 날짜로 들어가 보니 Windows Embedded CE 6.0의 경우는 2007년 9월까지 릴리즈된 update 현황을 볼 수 있었다.
왜 더는 없는 거지?? 이녀석들도 상당히 게으른 건가?? ㅡㅡ;

참고 : 자신의 Platform Builder에서 현재 QFE 업데이트 상황이 어떻게 되는지 확인을 하고 싶다면..
         '여기'를 통해 알 수 있다.

OSDesing이란 CE OS를 만들 때 필요한 기능을 추가할 것인지 말것인지를 정하고 실제 추가 삭제를 하는 작업을 말한다.

Windows Embedded CE 6.0의 OSDesign 작업을 할 때에 주의할 점이있다.
Platform manager이라는 컴포넌트를 OSDesign에 추가하지 말라는 것이다.

만일 이를 추가할 시에는 빌드를 하여 이미지를 생성하려 하면 다음과 같은 에러를 발생시킨다.

아래는 본인경우에서의 에러메시지이다.

Error: Could not find file 'C:\WINCE600\OSDesigns\emdk4000_cam_6\
emdk4000_cam_6\RelDir\EMDK4000_ARMV4I_Release\cemgrc.exe'
on disk cemgrc.exe C:\WINCE600\OSDesigns\emdk4000_cam_6\emdk4000_cam_6\RelDir\
EMDK4000_ARMV4I_Release\cemgrc.exe NK

C:\WINCE600\PUBLIC\COMMON\CESYSGEN\makefile 파일의 1187라인을 살펴보면, Platman Stuff라는 녀석을 타겟쪽으로 복사를 하는 작업을 하게 되는데... 이 'Platman Stuff'라는 녀석은 CE 6.0을 인스톨할 때부터 존재하지 않는 녀석이라고 한다. 그래서 이 파일은 복사될 수도 없고, 빌드 시 에러를 발생시킨다고 한다.

자세한 내용은 여기를 참조하면 될 듯 하다.

주저리 주저리 내용은 많지만 중요한 점은 그냥 OSDesign시에 체크를 하지 말라는 내용이다.

그것은...

디버깅 할려는 파일(.cpp, .c)에 아래의 것을 선언해주면 된다.

#undef DEBUGMSG
#define DEBUGMSG(1, b) RETAILMSG(1, b)

릴리즈 모드에서는 'RETAILMSG()'라는 녀석을 메시지를 출력하는 용도로 사용하게 되는데.. DEBUGMSG()라는 녀석을 RETAILMSG()로 출력하게 define하는 것이다.

PS : 헤더파일에는 선언하지 말라는 말이 있다... 여러 파일에서 같은 헤더파일을 부를 경우 이놈, 저놈.. 다 디버깅 메시지를 출력할 수 있으므로.... 흠.. 난리겠구만.. ^^;

platform builder에서 'Platform\XXX\Files'에 있는 파일들.. 즉 *.reg, *.bib.. 등의 파일을 수정한 후 다시 전체 빌드를 해야할지를 가지고 고민을 하는 경우가 있다.

일반적으로 '디바이스 드라이버'라든지 개발자가 직접만든 '프로젝트 프로그램'의 경우는 수정을 가한 해당 파일만 '빌드'해주고, Copy Files to Release Directory, Make run-time Image를 해주면, NK바이너리에 추가가 된다.

하지만, 이것들은 'Platform\XXX\Src'에 있는 녀석들의 경우이다.

'Platform\XXX\Files'의 경우는 두가지 경우로 나눌 수 있다.

첫 번째, release디렉토리의 *.reg, *.bib등의 파일을 수정하는 경우이다.
*.reg나 *.bib를 수정해야 할 경우이고, 어차피 NK를 만들기 위함이면, release디렉토리의 이 녀석들만 수정하면 된다. 그리고 make image를 하면 수정한 녀석들이 적용된 NK 바이너리를 사용할 수 있다.

두 번째, Files디렉토리의 *.reg, *.bib등의 파일을 수정하는 경우이다.
이경우는 수정한 파일을 release디렉토리로 복사해 make image해주어도 되고(첫 번째와 동일한 작업이 될 수 있음), Sysgen 후에 make image를 해주어도 된다.

문제는 얼마나 많은 시간이 걸리느냐 이지만, 첫번째의 경우 1분정도(?), 두 번째(sysgen)의 경우 10분 이상이 걸린다는 것이다.

release 디렉토리의 것들을 수정할 경우, sysgen을 해주게 되면, 수정했던 것들이 Files의 것들로 바뀌게 된다.
Sysgen 시에, Files의 파일들을 Release 디렉토리로 복사하는 과정이 있기 때문이다.
이점만 주의하면, 자주 *.bib, *.reg등의 파일을 수정하는 작업의 경우, 유용하게 사용할 수 있을 것이다.

Windows CE용 이미지를 생성하는데 사용되는 몇가지의 구성 파일(Configuration file)들이 있다.
이미지를 만들기 위해 반드시 필요하고, 또 설정을 잘 못할 시 만든 OS image가 제대로 동작을 안하는 경우도 종종 있다.

BIB, REG, DAT, DB 4개의 파일이 바로 그것이다.

1. BIB(Binary Image Builder)
   BIB파일은 NK.bin으로 압축할 파일들에 대한 정보, 압축이미지의 속성을 결정하는 파일이다.
   쉽게 말해서 만들 OS image안에 포함되는 모듈이나 컴포넌트들을 정의하는 파일이다.
   BIB파일은 4개(FILES, MODULES, MEMORY, CONFIG)의 세션으로 구성된다.

  

- FILES
      : 실행가능한 파일들, 그렇지 않은 파일들 모두 정의될수 있고, 이것들이 메모리 영역안에 저장된다.
        ex) aaa.avi   $(_FLATRELEASEDIR)\aaa.avi     NK     SHU

        NK라는 이름을 가지는 이미지 파일안으로, aaa.avi 파일이 압축된다.
        폰트, 단축아이콘, 멀티미디어 파일등이 포함될 수 있다.
        참고 : S : System
                 H : Hidden
                 U : Uncompressed

   - MODULE
      : FILES 와 비슷하지만, 실행가능한 파일(OCX, DLL, EXE)들을 정의한다.  
       ex) config.bib 의 예
         MODULES
              nk.exe         $(_FLATRELEASEDIR)\kernkitl.exe       NK      SHXL
              kd.dll           $(_FLATRELEASEDIR)\kd.dll               NK      SHK

         NK라는 이름을 갖는 이미지파일 안으로 nk.exe, kd.dll파일이 압축된다.
         참고 : X : 이미지 속에 압축될 때 서명된 정보를 보관하도록 지시
                  L : 가상메모리 상에서 해당하는 파일이 분리되어 보관되지 않게 지시
                       (코드, 데이터 영역이 연속적인 공간상에 존재하도록 하기 위함)
                  K : Kernel 모드

   - MEMORY
      : 대상 Target system의 Memory정보를 정의한다.
        ex) config.bib 의 예
          MEMORY
               NK                          80240000          009C0000            RAMIMAGE
               RAM                       80C00000         03400000             RAM
                 ....
      NK라는 이름을 갖는 이미지가 0x80240000 ~ 0x009C0000만큼의 메모리를 사용하며, 이것은 RAMIMAGE(ROM)의 속성을 갖는다는 의미를 갖는다.

   - CONFIG
      : 압축 혹은 ROM size와 같은 속성들을 설정하기 위해 사용한다.

2. REG 
    시스템 레지스트리 파일을 만드는데 사용되는 파일이다.
    Make Image과정 중 모든 *.reg파일을 통합하여 REGINIT.ini파일을 만든다.
    나중에 부팅 과정에서 형성될 초기 시스템 레지스트리 환경을 구축한다.

3. DAT
    단축아이콘 등을 원하는 위치에 생성하도록 지시하는 파일이다.

4. DB
    데이터베이스 테이블을 생성하도록 지시하는 파일이다.

Windows Embedded CE 6.0에서 QFE라고 거의 매월마다 새로이 업데이트(패치)되는 시스템이 있다. 버그라든지, 새로이 추가되는 기능들을 QFE라는 파일로 업데이트 하는 것이다.

현재 사용하고 있는 Platform builder에서 어디까지 업데이트가 되어있는지 확인하는 방법이 있다.

먼저 Visual studio 2005를 실행시키고, CE 6.0의 프로젝트를 하나 열자. 그리고 메뉴에서 Tools를 선택한다.

Tools의 하위 메뉴중 Platform Builder for CE 6.0 -> CE Update Check를 선택한다.


다음과 같이 CEUpateCheck라는 윈도우가 뜬다. 확인하고자 하는 플랫폼에 체크를 하고, Verify Updates를 클릭한다.


아래 그림과 같이 Windows Embedded CE 6.0의 업데이트 상황을 알 수가 있다. 녹색의 체크된 부분은 이미 업데이트가 된 부분이고, 그렇지 않은 부분은 새로이 업데이트를 해주어야 하는 부분이다.



업데이트는 다음 사이트를 통해서 다운로드 받을 수 있다.
Windows Embedded CE QFE Update 사이트

다음은 'zdnet'에 올라와 있는 라영호님의 글을 스크랩한 것이다.

라영호님은 Windows Embedded 분야 Microsoft MVP로 현제 인벤텍 상하이 연구소에서 Windows Embedded CE 기반의 단말기 및 스마트폰을 개발하고 있으며, Windows Embedded 운영체제에 대한 블로그를 운영하고 있다.


윈도우 임베디드 CE(Windows Embedded CE) 개발 과정을 크게 4가지로 구분해 본다면, 하드웨어에 관련된 부트 로더 개발 부분, 디바이스 드라이버 관련 개발 부분, OS를 포팅하고 최적화 하는 부분, 개발한 장비에서 동작할 애플리케이션을 개발하는 것으로 분류해 볼 수 있다. 각 개발 단계 중 본 칼럼에서는 윈도우 임베디드 CE 상의 애플리케이션 개발이라는 주제, 그 중에서도 애플리케이션 개발 과정 중의 디버깅 방법에 대한 내용에 대해 알아보고자 한다.

윈도우 임베디드 CE용 애플리케이션 개발은 <그림 1>과 같이 윈도우 임베디드 CE 운영체제의 포팅, SDK 생성과 같이 PC 애플리케이션에서는 고려하지 않았던 단계들이 추가되고 개발하는 하드웨어의 LCD나 장치를 고려하고 개발해야 한다는 제한 사항이 있다.

다른 어려움은 PC와 같이 어느 정도 안정화된 운영체제 환경에서 개발을 하는 것이 아니라, 개발 중인 운영체제에서 애플리케이션을 개발해야 한다는 것이다. 문제점이 애플리케이션에서 발생하는 것인지 포팅이 완전히 안 끝난 시스템의 문제인지 확인하기가 난해하다는 것이다.

일례로 필자가 이전 개발 프로젝트 개발 중에 생겼던 문제를 꼽을 수 있다. 필자는 LCD 디바이스 드라이버 개발을 담당하고 있었고, 카메라 프로그램을 위한 API를 제공하여 애플리케이션을 개발하도록 돕고 있었다. 카메라 애플리케이션에서 일정 작업을 하다 보면 Memory Leak가 생기는 경우가 있었다.

LCD 디바이스 드라이버나 카메라 드라이버 역시 충분히 테스트를 했기 때문에 그럴 일이 없다고 장담을 하고 있는 상황이었고, CETK나 테스트 절차를 통해 대부분의 테스트가 Pass를 했기 때문에 안정화가 되었다고 생각하고 애플리케이션만의 문제라고 손 놓고 있었다.

하지만 애플리케이션 개발자의 집요한 분석 리포트와 테스트 방법론을 보고 할 수 없이 드라이버를 디버깅해야 했다. 결국 필자의 잘못으로 결론이 나왔고 많은 사람들의 원망(?)속에서 수정을 해야 했다. 이렇듯 윈도우 임베디드 CE 상의 애플리케이션 개발은 단순히 애플리케이션 개발뿐 아니라 시스템의 문제까지도 고려해야 하는 어려운 개발 작업이다.

따라서 개발을 하다 보면 비주얼 스튜디오 2005의 막강한 디버깅 기능만 가지고 디버깅을 하여 문제점을 찾아내기 어려울 때가 있다. 이러한 문제를 디버깅하기 위해 마이크로소프트는 다양한 디버깅 툴을 제공하고, 필자는 이 툴을 사용하여 어떻게 디버깅을 해 나가야 하는지 알려드리고자 한다.

<그림 1 - AppDev.bmp>

윈도우 임베디드 CE용 애플리케이션 개발에 있어 버그가 없고 안정적인 프로그램을 만들기 위한 좋은 방법은 무엇일까? 이 질문에 대한 필자의 대답은 ‘개발 경험’+’좋은 설계’+’좋은 툴’+’테스트’+’@’ 이 5가지를 꼽을 수 있겠다. 개발 경험이야 개발하면서 얻어져야 하는 것이고, 좋은 설계 방법이나 방법론적인 방법은 S/W Engineering 책에 수없이 다루어졌기 때문에 본 칼럼에서 다루지는 않겠다.

플랫폼 빌더(Platform Builder), 비주얼 스튜디오라는 개발 환경은 사실상 널리 확인이 된 좋은 개발 환경이다. 여기에 반복적인 테스트를 통해 생겨날 수 있는 모든 문제점을 확인하는 것이야말로 윈도우 임베디드 CE용 애플리케이션 개발의 최적의 조건이라고 할 수 있겠다.

@는 어떤 요소일까? 윈도우 임베디드 CE용 애플리케이션은 임베디드 시스템이라는 것과 윈도우 임베디드 CE라는 운영체제라는 것을 염두에 두어야 한다는 것이다. 임베디드 시스템의 제한 사항을 머리에 항상 염두에 두고 적은 메모리를 차지하고 빠르게 동작할 수 있는 애플리케이션을 만들 수 있도록 노력을 해야 한다.

그러기 위해서는 윈도우 임베디드 CE라는 운영체제가 어떻게 동작하는지에 대한 지식을 가지고 있어야 한다. 6.0으로 오면서 메모리, 슬롯(Slot) 개념, 스레드(Thread)에 대한 제한이 많이 없어 졌지만 윈도우 CE 5.0 버전의 경우 이러한 시스템 제한 요소 때문에 애플리케이션 개발 시에도 문제가 되는 경우가 많았다.

슬롯의 한계 때문에 개별 프로그램으로써 개발 할 때는 잘 되다가도 정작 운영체제에 포함시키고 동작시킬 때는 갑자기 프로세스가 종료 되거나 시스템과 충돌하는 문제가 생기기도 했었다.

이러한 이유로 애플리케이션 개발을 할지라도 시스템에 대한 깊은 이해는 좋은 프로그램을 만들기 위한 밑받침이 되는 것이다. 따라서 윈도우 임베디드 CE에 대한 시스템적인 지식이 좋은 프로그램을 만들기 위한 @가 되는 것이다.

개발한 애플리케이션의 알고리즘적인 버그를 디버깅 하기 위해서는 구현한 세부 코드를 잘 살피고 변수의 변경을 추적하면서 어떠한 부분이 잘못되었는지 추적해 나가야 한다.

하지만 윈도우 임베디드 CE용 애플리케이션은 시스템과의 관계 및 구조를 잘 이해하면서 문제에 대해 집중하여 디버깅을 해야 한다. 이때 도움을 줄 수 있는 것들이 비주얼 스튜디오와 플랫폼 빌더, 그리고 각종 Remote Tool들이다.

이제부터 윈도우 임베디드 CE에서의 애플리케이션 디버깅에 관한 내용에 대해 살펴보도록 하겠다.

비주얼 스튜디오 2005 디버깅
일반적으로 윈도우 임베디드 CE 6.0용 애플리케이션의 개발과 디버깅은 비주얼 스튜디오 2005에서 이루어진다. 이전에 임베디드 비주얼 C++이 있어 플랫폼과 응용프로그램 개발도구 각각 존재하였지만 이제는 비주얼 스튜디오 2005라는 통합 환경으로 운영체제, 애플리케이션의 개발 및 디버깅을 같이 할 수 있게 되었다.

<그림 2>는 비주얼 스튜디오 2005에서 윈도우 임베디드 CE용 애플리케이션을 디버깅 하는 화면이다. 코드상의 문제점을 추적하기 위한 중단점(Breakpoint)의 설정을 통해 프로그램 진행을 잠시 중단하도록 한 후에 ‘한 단계씩 코드 실행’, ‘프로시저 단위 실행’ 명령을 통해 애플리케이션의 진행을 Step By Step 진행시키면서 디버깅 할 수 있다.

<그림 2-VS2005 Debug.BMP>

비주얼 스튜디오에서 애플리케이션 디버깅의 중요 요소들
이제 비주얼 스튜디오 환경은 윈도우 임베디드 CE 운영체제 개발 환경일 뿐 아니라 애플리케이션 개발 환경이다. 비주얼 스튜디오를 이용한 디버깅 방법은 이제 모두 다 아는 사실이다. 그래도 디버깅에 관련된 중요 키워드를 확인해 본다면 다음과 같다.

(1)중단점(BreakPoint) – 중단점은 윈도우 임베디드 CE용 애플리케이션 디버깅을 하기 위한 기본 요소이다. 프로그램 소스 내에 디버깅을 원하는 중요한 위치에 중단점을 설치하고 거기서부터 디버깅이 이루어진다.

(2)지역, 자동 – 지역 및 자동 창에는 현재 실행중인 코드 영역에 해당하는 지역 변수가 표시되고, 자동 창에는 현재 줄과 코드의 이전 줄에 사용된 변수가 나타나게 된다.

(3)호출 스택 – 애플리케이션 디버깅 시 눈 여겨 별 중요한 부분은 호출 스택 창이다. 호출 스택 창은 디버그 메뉴/창/호출 스택에서 확인할 수 있다. 실시간 디버깅작업에서는 호출된 순서를 보여주는 기능으로 사용할 수 있다. 즉, 현재 프로그램 라인까지 어떠한 함수가 호출되었는지 과정을 보여준다.

복잡한 애플리케이션의 디버깅 시 호출된 함수를 순서대로 역추적하면서 문제점을 확인할 수 있기 때문에 중요한 기능이라고 하겠다. <그림 3>은 비주얼 스튜디오 2005에 호출 스택 화면이다.

<그림 3 - CallStack.BMP>

(4)메모리, 레지스터 – 애플리케이션 동작 중 레지스터의 값 및 메모리의 내용을 확인하기 위해 사용한다. 레지스터나 실제 메모리를 직접 바꾸면서 디버깅 용도로도 사용할 수 있다. <그림 2> 화면 참조.

윈도우 임베디드 CE 애플리케이션 개발의 첫걸음, 디버그 메시지
DEBUGZONE, DEBUGMSG, RETAILMSG 등의 디버깅 메시지 출력 매크로는 윈도우 임베디드 CE 개발을 하게 되면서 알게 된 중요한 매크로들이다. 시리얼 포트를 통하여 하이퍼 터미널이나 플랫폼 빌더의 디버그메시지 창에 출력된 메시지 정보 디버깅을 위한 중요한 실마리다.

문제에 따라 디버그 존을 설정해 어떠한 메시지를 중점적으로 볼 것인가 선택을 하고 출력된 메시지를 추적해 나가면서 문제점을 추적하는 방법은 고전적이지만 매우 유용한 디버깅 방법이다. 비주얼 스튜디오에서의 디버깅 메시지 출력뿐 아니라 OS 이미지 내에 포함되어서도 유용한 디버깅 정보를 제공하기 때문에 DEBUGMSG의 사용은 디버깅을 위한 기본 준비라고 하겠다.

DEBUGMSG 등록 및 사용 아래와 같다. DEBUGZONE을 등록하고, 등록한 DEBUGZONE에 따라 디버그 메시지를 출력할 수 있도록 DEBUGMSG를 사용하는 예이다. DEBUGMSG의 DEBUGZONE 설정은 실시간 디버깅 환경에서 디버깅 메시지 출력을 선택적으로 조절하면서 좀 더 쉽게 디버깅하고자 하기 위해서 사용한다.


플랫폼 빌더에서 모듈에 대한 DEBUGZONE의 표시와 DEBUGZONE의 선택은 <그림 4>과 같다.

<그림 4 - DEBUGZONE.BMP>

Kernel Debugger를 이용한 애플리케이션 디버깅 방법
비주얼 스튜디오 2005를 이용한 임베디드 CE OS용 애플리케이션의 디버깅 방법은 PC용 애플리케이션을 디버깅하는 것과 별반 차이가 없다. 하지만 윈도우 임베디드 CE에서는 설치 가능한 독립적인 윈도우 임베디드 CE용 애플리케이션을 개발한다기 보다 NAND나 NOR같은 Flash 메모리상에 OS와 함께 탑재되어 동작되는 상황을 고려해야 한다.

UI(User Interface)와 프로그램의 기본 동작에 관련된 사항은 비주얼 스튜디오를 이용하여 디버깅을 마무리하고 OS에 탑재될 환경을 고려하여 OS이미지에 애플리케이션이 포함되어 빌드 되도록 하거나 플랫폼 빌더에서 애플리케이션을 실행시켜 OS 상에서의 애플리케이션의 동작 검증 및 디버깅을 할 수 있도록 한다.

<그림 5>는 윈도우 임베디드 CE 상에서 플랫폼 빌더를 이용해 OS 이미지에 포함된 “WavPlay.exe”라는 윈도우 임베디드 CE용 애플리케이션을 디버깅하는 그림이다. 비주얼 스튜디오에서 애플리케이션 디버깅 방법과 같이 소스 코드에 중단점을 설정한 후 디버깅을 진행하면 된다. 애플리케이션이 OS 이미지 내에 포함되어 있다는 것뿐 디버깅 방법은 차이가 없다.

<그림 5- PlatformDebug.BMP>

Remote Tools을 사용한 애플리케이션 디버깅
플랫폼 빌더에서 애플리케이션을 디버깅하는 것은 간단하게는 윈도우 임베디드 CE 운영체제가 동작하는 환경에서 애플리케이션이 제대로 동작하는지 검증하는 것도 있지만 운영체제 사이와의 동작 관계를 확인하는 목적도 있다.

이때 사용하는 것이 플랫폼 빌더의 Remote tool이다. 애플리케이션과 운영체제 간의 미묘한 동작 검증을 하기 위해 사용한다. CeLog는 <표 1>과 같이 윈도우 임베디드 CE 운영체제에 대한 Heap 생성, 인터럽트 처리등과 같은 시스템 이벤트가 발생할 때 관련 이벤트를 기록하여 분석할 수 있게 하는 기능이다.

<표 1 - CeLog Event 예>

플랫폼 빌더 Remote Tool 사용을 위한 준비
윈도우 임베디드 CE 운영체제에서의 애플리케이션 디버깅은 위와 같이 플랫폼 빌더 상에서 실행 이미지를 직접 로드하거나 OS 이미지 내에 포함시켜 디버깅을 하면 된다. 하지만 Remote Tool을 이용하면 운영체제와의 관계를 파악하거나 Profiler를 통해 좀더 OS와의 관계를 통한 내부적인 동작내용을 확인할 수 있다.

그러기 위해서는 몇 가지 운영체제의 옵션을 추가해야 한다.

<그림 6>와 같이 프로젝트/속성 명령에서 설정하거나 환경 변수에 다음과 같이 추가 하면 된다. 환경 변수를 설정한 후 OS를 다시 빌드해야 Remote Tool을 이용해 애플리케이션의 문제점을 분석할 수 있는 환경이 준비되는 것이다.

Profiler나 CeLog Enable의 경우 Ethernet이나 USB 통한 KITL뿐만 아니라 ActiveSync를 통해서도 이용할 수 있기 때문에 개발 시 Profiler, CeLog가 Enable된 이미지를 별도로 릴리스한 후 ActiveSync 연결만으로 Application 디버깅을 위한 OS 이미지로 사용할 수 있다.

set IMGCELOGENABLE=1
set IMGPROFILER=1
set IMGAUTOFLUSH=1

<그림 6-ProfilerSetting.bmp>

Kernel Tracker를 이용한 Memory Leak 디버깅
윈도우 임베디드 CE용 애플리케이션 개발 중 가장 많이 겪는 문제는 애플리케이션의 성능 문제, 잘못된 동작 혹은 시스템 호출을 통한 “Data Abort” 발생 후 시스템의 중단, Memory Leak 문제이다. Data Abort의 발생은 동작 중 잘못된 코드를 호출한 후 생기는 문제이기 때문에 Data Abort가 발생한 시점의 모듈과 관계를 추적하다 보면 쉽게 찾아낼 수 있다.

누적해서 발생하는 문제가 아니라면 Data Abort 발생 지점을 추적하여 Data Abort를 일으키는 모듈의 위치 및 코드까지 추적할 수 있다.(자세한 사항은 Sue Loh’s Blog, http://blogs.msdn.com/sloh/를 참조하기 바란다).

Memory Leak는 애플리케이션에서 메모리 할당과 해지를 제대로 안 할 경우에 발생한다. Memory Leak을 방지하기 위해서는 사용 메모리의 할당과 해지에 대해서 주의해서 프로그램을 해야 한다.

Memory Leak은 Kernel Tracker를 이용하여 보다 손쉽게 디버깅 할 수 있다. 메모리의 할당과 해지를 이벤트 형태로 실시간 볼 수 있기 때문에 어떠한 부분에서 메모리 해지가 일어나지 않아 문제가 생기는지 확인할 수 있는 것이다. Kernel Tracker를 이용한 Memory Leak을 디버깅하기 위한 방법은 다음과 같다.

● Kernel Tracker의 Edit 메뉴에서 Event Filter를 선택한다. Synchronization, Miscellaneous, User Defined, Extensions에 설정된 이벤트 명을 모두 클리어 시키고 Memory 탭 부분만 설정한 채로 남겨둔다. <그림 7> 참고.

<그림 7- MemoryLeak.bmp>

● Find Event를 선택하여 메모리 할당에 관련된 Allocate Heap 이벤트와 Free Heap 이벤트, Allocate Virtual Memory와 Free Virtual Memory 이벤트간의 관계 중에 빠진 것이 있는지 확인을 하면서 보다 자세하게 Memory Leak에 대해 디버깅 할 수 있는 것이다. <그림 7>은 Kernel Tracker를 이용한 Memory Leak 디버깅 화면이다. 그림과 같이 Allocate Virtual Memory에 해당하는 Free Virtual Memory가 없기 때문에 Memory Leak이 발생한다는 것을 손쉽게 디버깅할 수 있게 한다. <그림 8>은 Kernel Tracker를 이용해 Memory Leak을 찾아내는 화면이다.

<그림 8 - KernelTracker.bmp>

Call Profiler를 이용한 수행시간 최적화
Call Profiler는 프로그램내의 함수나 코드의 동작시간을 수치와 그래픽적으로 표시해주어 어떠한 루틴에서 지연 요소가 생겼는지 분석할 수 있게 해주는 Remote Tool이다.

윈도우 임베디드 애플리케이션 개발이 어느 정도 마무리가 되었다면 Call Profiler로 프로그램의 수행시간을 측정하여 동작 지연 요소가 생기는 부분을 찾아내어 개선하는 방법도 애플리케이션의 성능 개선을 위한 좋은 방법이라고 하겠다. <그림 9>은 Call Profiler를 이용하여 프로그램의 수행 시간을 분석하는 화면이다.

<그림 9 - CallProfiler.bmp>

ActiveSync 없이 Visual Studio 2005로 디버깅 하기
비주얼 스튜디오 2005로 윈도우 임베디드 CE용 애플리케이션을 개발하다 보면 귀찮은 부분 중의 하나가 ActiveSync를 통하여 단말기를 연결하고 디버깅을 해야 한다는 것이다.

만약 디버깅을 위한 Ethernet 포트가 있고, 프로세서가 ARMV4i나 X86계열이라면 "www.OpenNETCF.com"를 사용할 것을 추천한다. ActiveSync 없이 TCP/IP를 통해 Windows Embedded CE 장치와 연결하고 Application의 개발과 디버깅을 할 수 있게 하는 유틸리티이다.

테스트 자동화를 통한 Bug Free !
윈도우 임베디드CE 애플리케이션의 개발 방법론은 PC나 웹과 같은데 적용되는 개발 방법론과 결코 다르지 않다. 리펙토링(Refactoring), 페어 프로그래밍(Pair Programming)과 같이 현재 각광 받고 있는 프로그래밍 기법들 역시 윈도우 임베디드 CE 애플리케이션에서도 적용이 가능하다.

하지만 잊지 말아야 할 중요한 차이점은 애플리케이션에서 하드웨어에 대해 좀더 관여를 하고 있다는 점이다. 한 비트 잘못 설정한 프로세서의 레지스터 값이 나비 효과처럼 작용하여 전체 시스템을 불안하게 만드는 원인으로 작용할 수 있다는 것이다. 따라서 작은 문제점도 찾아낼 수 있는 테스트 방법과 기준이 필요한 것이다.

하지만 이러한 문제는 쉽게 발견되는 것이 아니기 때문에 테스트 방법에 대한 기준을 정하고 자동화할 수 있는 방법을 모색하라는 것이다. 말은 쉽지만 많은 시행착오가 있어야 좋은 방법을 찾을 수 있다.

개발 시작 초기에 어떤 테스트를 하고 어떤 테스트 결과를 기대할 것인가에 대한 기준을 정하는 것이 좋다. 완벽한 기준이 있다면 다행이지만 없다면 간단하게라도 만들라는 것이다. 제일 좋은 것은 실제 기기를 사용하는 것과 같은 기준으로 기준을 만들고 테스트 하는 것이다. 즉, "최소한 사용자가 어떻게 사용한다는 가정 하에 기준을 만들고 사용자가 사용하는 것처럼 테스트 하라" 라는 것이다.

예를 들어 내비게이션 시스템을 개발하고 있다고 가정하여 하루에 사용자가 키를 몇 번 누르는지 예측을 하여 제품의 수명만큼 계속 누르는 반복 테스트를 하라는 것이다.

실제로 핸드폰 품질을 책임지고 있는 품질 기술 연구소에서는 자동화된 기계나 로봇을 이용하여 사용자가 핸드폰을 사용하는 형태를 짧은 시간에 집중 테스트 하여 소프트웨어, 하드웨어서 생길 수 있는 문제를 검증하고 있다.

테스트를 하다 보면 개발 중에 예측하지 못하는 다양한 문제점을 이러한 테스트를 통하여 발견 할 수 있다. 실생활에서 특정 키를 연속으로 1만번 누르거나 전원 켜고 끄는 것을 1,000번 이상을 하지는 않는다. 하지만 이러한 반복적인 테스트에서 소프트웨어에서 있을지 모르는 버그를 발견할 수 있는 것이다.

일례로, 필자는 100ms 단위로 키를 반복적으로 1만번 누르는 테스트를 한 적이 있었다. 윈도우 CE의 포팅이나 응용프로그램이 어느 정도 안정화 됐다고 생각을 하고 있었다. 실제로 직접 이것저것 동작 시켜보면 제대로 동작하였다. 하지만 테스트 시작 후 3일 정도가 지난 후 모든 장치가 멈춰있는 것을 보게 되었다. 한마디로 시스템이 다운된 것이다.

나중에 알아낸 사실이지만 드라이버에서 수십 바이트의 메모리 누수가 발생하였고 이게 누적되어 3일 후에는 시스템을 다운 시키는 요소로 작용하였던 것이다. 평상시 간단히 테스트 할 때는 이러한 문제점을 찾을 수 없었다. 이러한 테스트를 하기 위해서 테스트 장치를 모든 회사에서 구비할 필요는 없다.

좀 고민을 하다 보면 몇 줄 안 되는 C 코드로 구현해서 테스트 해볼 수 있기 때문이다. 필자도 테스트 하는 장소가 필자의 회사에서 좀 멀리 떨어진 곳에 있어서 테스트 하러 가기 귀찮아서 고안해낸 방법이다.

다음 코드는 키 입력을 에뮬레이션 하는 간단한 코드이다. 필자는 이 코드를 별도 애플리케이션에서 구현하여 테스트 하는 방법을 사용하고 있다.

Sleep(KEY_PRESS_DURATION);
keybd_event((BYTE) VK_TUP, 0x0, 0, 0);
Sleep(KEY_PRESS_DURATION);
keybd_event((BYTE) VK_TUP, 0x0, KEYEVENTF_KEYUP, 0);

이 방법은 별도의 장치 없이 테스트 하는 방법이며 운영체제의 안정성뿐만 아니라 응용프로그램의 신뢰성 테스트에도 필자는 이용하고 있다. 이런 식의 간단한 루틴으로 간단하게는 키 테스트부터 Application의 반복 동작 시 문제점을 검증할 수 있는 것이다.

조금만 고민 한다면 자동으로 모든 테스트를 할 수 있고, 이러한 자동화된 테스트 방법이 여러분 시스템 및 안정성을 더욱 높여줄 것이다.

끝으로
윈도우 임베디드 CE 상의 애플리케이션 디버깅 방법을 위한 비주얼 스튜디오 2005의 디버깅 방법, 디버그 메시지 등록방법, 디버깅 테크닉 등에 대해 간략히 살펴봤다.

실제 디버깅에 사용되는 방법들은 단순한 한 가지 방법으로는 문제가 해결되지 않을 것이다. 하지만 문제에 대한 실마리는 언제나 비주얼 스튜디오의 디버깅 창에 나온 작은 단서로부터 찾아낼 수 있다.

실제 제품이 기획에서 생산이 되고 출시가 되기까지에는 무수히 반복된 테스트와 디버깅을 통해 안정성을 확보해야 한다. 그래야 비로소 상품으로써의 그 가치를 인정 받을 수 있을 것이다.

디버깅을 하기 위해 밤새 반복된 테스트와 원인 분석을 하고 마침내 그 문제가 해결 됐을 때의 기쁨은 엔지니어가 아니면 누리기 힘든 기쁨일 것이다. 비주얼 스튜디오와 플랫폼 빌더의 막강한 디버깅기능을 이용해 “Bug Free!” Application에 도전해 보기 바란다!

다음은 'zdnet'에 올라와 있는 성수현님의 글을 스크랩한 것이다.

성수현님은 DST 기술팀에서 WinCE 관련 기술지원과 MS공인 WinCE 교육강사로 활동하고 있으며, 2007년 MS 윈도우즈 임베디드 부분 MVP로 선정되었다.