플래시 메모리를 저장 장치로
글: 라영호 / ratharn@naver.com
플래시 메모리!
"8기가 바이트 플래시 메모리 탑재!", "아이팟 16G, 아이팟 32G" 과 같이 요즘 나오는 제품들의 주요 특징을 요약하기 위해서 저장할 수 있는 플래시 메모리의 크기를 강조하는 추세다. 하드 디스크와 SD/MMC 메모리 카드, 컴팩트 플래시 메모리 카드와 같은 저장 매체가 임베디드 시스템의 저장 장치였다면 이제는 플래시 메모리가 주로 사용되고 있다. PMP와 같은 장치에서는 하드 디스크가 사용되기는 하지만, 가격 및 안정성, 소형화를 이유로 점차 플래시 메모리가 임베디드 시스템의 주 저장 장치로 사용되고 있다. 플래시 메모리의 용량에 따른 가격이 점차 낮아지고 있고, 개선된 플래시 메모리 구조 및 생산 방법에 따라 점차 대용량의 플래시 메모리를 탑재하게 되었다.
하지만, NAND 플래시와 같은 메모리는 NOR 플래시 메모리와 달리 파일 시스템을 구성하고 이용하는데 있어 장애 요소를 가지고 있다. 배드 블록, 지우기 횟수 제한, 기록 및 삭제 시 에러 발생 가능성, 읽기 작업 시 에러 발생 가능성 등이 있다. 이러한 신뢰성 문제점 때문에 초기에는 사용에 어려움을 겪다가 현재는 다양한 솔루션을 통해 중요한 저장장치로 사용되고 있다.
윈도 임베디드 CE 시스템과 플래시 메모리
윈도 임베디드 CE 운영체제에서는 이전부터 플래시 메모리에 대한 지원을 했었다. NOR로부터 시작해서, NAND 및 기타 플래시 메모리에 지원할 수 있도록 구성 요소를 포함하고 있으며 특히 FMD(Flash Media Driver)라는 형태로 플래시를 다루기 위한 드라이버 구조를 제공하고 있다.
또한 윈도 임베디드 CE 6.0 R2 버전에서는 기존의 디바이스 드라이버처럼 MDD(Model Device Driver)와 PDD (platform-dependent driver) 형태의 드라이버 구조를 제공하고 있다.
플래시 드라이버
플래시 파일 시스템, 혹은 플래시 메모리 드라이버라는 형태로 윈도 임베디드 CE 운영체제에는 존재한다. 윈도 임베디드 CE에서 플래시 메모리를 하나의 저장 장치로 인식해서 사용하기 위해서는 FMD(Flash Media Driver)라는 드라이버가 윈도 임베디드 CE의 운영체제와 플래시 메모리 사이에서 중간 역할을 하여 플래시 메모리를 파일 시스템에서 관리할 수 있는 형태로 만들어 준다. 하지만 이 FMD는 통상적으로 윈도 임베디드 CE 운영체제에 포함이 되어 있지만 경우에 따라서는 다른 형태의 제품으로 대처가 가능하다.
다시 말하자면, 마이크로 소프트사에서 기본적으로 제공하는 FMD 보다 빠른 속도나 안정성 및 다양한 제품 지원을 위해 다른 회사에서 개발된 FMD를 채용하는 경우가 적지 않았다. 물론 이러한 것들은 현재 나와있는 윈도 임베디드 CE 6.0 R3 버전 이전의 문제들이다.
윈도 임베디드 CE 운영체제에 사용되었던 대표적인 플래시 미디어 드라이버 및 파일 시스템에 관해 살펴 보도록 하자.
NOR 플래시 메모리의 기록 속도 향상과 데이터 안정성을 위해 많이 사용되었었다. 하지만 플래시 메모리의 주류가 NOR 플래시 메모리에서 NAND 플래시 메모리로 바뀌면서 지금은 많이 사용되지 않고 있다.삼성의 PocketStoreII - 삼성에서 만든 NAND 플래시용 플래시 드라이버, NAND 플래시 메모리, 특히 MLC (Multi-Level Cell) Nand 및 OneNand 계열을 위해 제공되고 있다. 삼성 NAND 플래시 메모리에 최적화 되었고 MLC에서의 배드 블록(Bad Block), 웨어 레벨링(Wear Leveling)등 플래시 메모리 사용을 최적화 하기 위한 기능들이 들어 있다. 여러 제약조건 때문에 일부 업체에서 사용되고 있다.
Datalight의 FlashFX, Reliance - Datalight사의 플래시 메모리 드라이버 및 파일 시스템이다. 속도 및 성능이 검증된 제품이지만 라이선스 비용 때문에 신뢰도가 높게 요구되는 일부 시스템에서만 사용되고 있다. FlashFX의 경우 플래시 메모리와 MS의 파일 시스템간의 FMD 역할을 하게 되며, Reliance의 경우 윈도 임베디드 CE 운영체제에 기본적으로 사용되는 파일 시스템인 FAT 파일 시스템을 대치하는 파일 시스템으로 사용할 수 있도록 만들어 졌다.
윈도 임베디드 CE R2 버전의 플래시 드라이버 모델
R2에서 새롭게 소개된 MDD 및 PDD 모델의 플래시 드라이버는 기존의 드라이버 구조를 유지하면서 MLC와 같은 플래시 메모리의 기술을 사용할 수 있게 하는 구조로 만들어 졌다. <그림 1>은 MDD/PDD 형태의 플래시 드라이버 모델에 대해서 설명하는 그림이다.
플래시 MDD/PDD 형태 모델의 주요 함수
LIBRARY NANDFLSH
EXPORTS
DSK_Init=FlashPdd_Init
DSK_Deinit=FlashPdd_Deinit
DSK_Open=FlashPdd_Open
DSK_Close=FlashPdd_Close
DSK_Read=FlashPdd_Read
DSK_Write=FlashPdd_Write
DSK_Seek=FlashPdd_Seek
DSK_IOControl=FlashPdd_IoControl
DSK_PowerDown=FlashPdd_PowerDown
DSK_PowerUp=FlashPdd_PowerUp
MDD/PDD 형태의 플래시 드라이버에 대한 DEF 파일
[HKEY_LOCAL_MACHINEDriversBlockDeviceNAND]
"Dll"="flashmdd.dll"
"FlashPddDll"="fmdwrapperpdd.dll"
"Profile"="NAND"
"Prefix"="DSK"
"IClass"=multi_sz:"{A4E7EDDA-E575-4252-9D6B-4195D48BB865}"
[HKEY_LOCAL_MACHINESystemStorageManagerAutoLoadNAND]
"DriverPath"="DriversBlockDeviceNAND"
"LoadFlags"=dword:1 ; 동기화 되도록 한다.
"Order"=dword:0
"BootPhase"=dword:2
; NAND 플래시 메모리에 대한 설정 항목들
[HKEY_LOCAL_MACHINESystemStorageManagerProfilesNAND]
"Name"="MSFLASH for NANDFLASH"
"Folder"="NAND Flash"
"AutoMount"=dword:1
"AutoPart"=dword:1
"AutoFormat"=dword:1
"PartitionDriver"="flashpart.dll"
"Util"="fatutil.dll"
[HKEY_LOCAL_MACHINESystemStorageManagerProfilesNANDFATFS]
"ForceWritethrough"=dword: 1
플래시 MDD & PDD 모델 레지스터리 설정 항목
TARGETNAME=mddpdd_nandflsh
TARGETTYPE=DYNLINK
RELEAYPE=PLATFORM
SYNCHRONIZE_DRAIN=1
TARGETDEFNAME=$(TARGETNAME)
DEFFILE=$(TARGETDEFNAME).def
DLLENTRY=DllMain
TARGETLIBS=
$(_PROJECTROOT)cesysgensdklib$(_CPUINDPATH)coredll.lib
$(_PROJECTROOT)cesysgenoaklib$(_CPUINDPATH)ceddk.lib
SOURCELIBS=
$(_COMMONOAKROOT)lib$(_CPUINDPATH)fal.lib
$(_COMMONOAKROOT)lib$(_CPUINDPATH)fmdhooklib.lib
$(_COMMONOAKROOT)lib$(_CPUINDPATH)flashmdd.lib
$(_COMMONOAKROOT)lib$(_CPUINDPATH)fmdwrapperpdd.LIB
MDD/PDD 플래시 드라이버의 sources 파일
LRESULT FmdWrapperPdd::Init(DWORD Context)
{
LRESULT Result = ERROR_SUCCESS;
m_FmdHandle = FMD_Init ((LPCTSTR)Context, NULL, NULL);
if (m_FmdHandle == NULL)
{
Result = ERROR_GEN_FAILURE;
goto exit;
}
GetFmdInterface();
Result = GetRegionInfoTable (1, &m_RegionInfo);
exit:
return Result;
}
FMDWrapperPDD.CPP의 소스 일부분
MDD와 PDD 모델의 플래시 드라이버를 사용하던, FAL(Flash Abstraction Layer)와 FMD(Flash Media Driver) 형태의 플래시 드라이버를 사용하던, 두 메모리 모델에서 호출되는 플래시 메모리에 관련된 함수들은 크게 대동소이하다. 따라서 기본적은 플래시 메모리 드라이버의 구조만 파악하고 있다면 MDD/PDD 형태의 플래시 메모리 드라이버로 이전하는 것에 크게 문제는 없을 것이다. <표 1>은 플래시 메모리 드라이버에서 사용되는 기본 함수들을 정리한 것이다.
MDD/PDD 형태의 플래시 드라이버는 기존의 FMD 드라이버내의 함수를 사용하여 구성할 수 있도록 함수들을 추가하였다. 이 함수들은 "fmdwrapperpdd.dll"이라는 DLL로 존재하며 기존의 플래시 드라이버에서 크게 변경 없이 구성할 수 있도록 해준다.
OS 설정 항목
MDD/PDD 형태의 플래시 드라이버 모델은 SYSGEN_FLASHMDD라는 시스템 생성 변수를 통해 윈도 임베디드 CE 운영체제에 해당 컴포넌트가 포함이 된다. 모듈은 플래시 MDD/PDD 형태의 기본 골격을 담당하는 flashmdd.dll과 파티션을 관리하기 위한 flashpart.dll로 구성되어진다.
윈도 임베디드 시스템에서 전원 관리
윈도 임베디드 시스템에서 전원 관리는 문제는 중요한 문제이다. 또한 윈도 임베디드 CE 운영체제를 처음 접하는 개발자들에게는 다소 어려운 부분이 될 수 있다. 하지만 다음과 같은 내용을 머리에 기억하고 접근한다면 좀더 쉬운 접근 방법이 되지 않을까 생각한다.
(1) 윈도 임베디드 시스템에서는 배터리를 기본 전원으로 사용하는 시스템을 가정한다(물론 윈도 임베디드 CE 시스템에 따라 일반전원을 사용한 시스템도 많다. 일반전원을 사용한 시스템은 전원 관리에 대한 큰 고려가 필요 없기 때문에 고려할 대상이 아니다). 따라서 한번 충전해서 많은 시간 동안 사용할 수 있어야 한다.
(2) 사용하지 않을 땐 끌 수 있어야 한다. 끈다는 의미는 전원을 완전하게 차단하는 것뿐만 아니라 저전력 상태로 유지하는 것도 포함된다.
(3) 저장된 데이터는 특별한 일이 있지 않는 한 오랫동안 저장되어 있어야 한다.
(4) 사용 중 배터리 잔량이 부족하면 경고해 주고 사용자는 충전하는 등의 작업을 취할 수 있도록 해야 한다.
위와 같은 모든 작업 내용이 윈도 임베디드 CE 운영체제에서 해주어야 할 것들이다.
물론 많은 일을 해야 할 것이라는 생각이 들것이다. 하지만 윈도 임베디드 CE 운영체제에서는 이러한 모든 것을 고려해 두었고 몇 가지 중요한 점들만 머리에 두고 작업을 하면 된다.
PM.DLL
모든 전원 관리는 PM.DLL을 통해 이루어지며 이 동작 방식을 이해해야만 제대로 된 윈도 임베디드 시스템을 만들 수 있다. PM.DLL은 윈도 임베디드 CE를 설치하면 소스 형태로 제공된다. 그대로 변경 없이 사용하거나 또는 사용자의 시스템에 따라 변경하여 구성할 수 있다. <그림 2>은 PM.DLL의 대략적인 역할에 대한 그림이다. PM.DLL은 WINCE600 PUBLICCOMMONOAKDRIVERSPM 이라는 디렉토리안에 소스형태로 존재한다.
디바이스 드라이버와 전원 관리
PM.DLL이 전원 관리의 중요한 역할을 하고 있다. 하지만 윈도 임베디드 CE 운영체제의 커널 역시 전원 관리의 핵심적인 부분이다. 사실상 커널이 PM.DLL의 도움을 받아 전원 관리를 한다고 생각하면 되겠다. 윈도 임베디드 CE 운영체제 커널의 가장 큰 역할을 간단히 정리해 본다면 다음과 같다.
(1) 사용자의 입력이나 사용 방법에 따라 전원 관리를 주관한다.
(2) 응용 프로그램의 요청을 받아드려 응용 프로그램에서 필요한 장치를 사용할 수 있게 한다.
(3) 디바이스 드라이버의 전원을 관리한다.
(4) 시스템의 유휴 상태를 감지하고 유휴 상태에서 보다 적은 전원을 사용하도록 프로세서의 모드를 변환한다. 윈도 임베디드 CE 운영체제는 다양한 프로세스를 관리하고 스케줄링한다. 시스템의 유휴 상태(idle) 상태를 감지하고 유휴 상태에서 프로세서가 가지고 있는 고유 동작 모드를 변환시켜 좀 더 적은 전원을 사용하도록 유도 한다.
(5) 원도우 임베디드 CE 운영체제를 탑재한 시스템의 파워키를 눌러 전원을 켤 때나 끌 때 시스템이나 각 디바이스 드라이버가 정상적으로 동작하도록 조절한다.
커널은 운영체제의 핵심이다. 또한 전원 관리의 핵심이다. 하지만 윈도 임베디드 시스템에서는 좀 더 주의해야 할 점이 있다. 그것은 "운영체제 커널은 전원 관리에 대한 기본적인 사항만 제공하고 세부적인 제어, 동작, 전략 등은 윈도 임베디드 CE 운영체제를 탑재하여 개발하는 회사의 몫으로 남겨 둔다는 것이다." 어떻게 보면 무책임할 수도 있고, 어떻게 보면 개발자의 여지를 많이 남겨둔 시스템이기도 하다.
배터리
위와 같은 모든 프로세서들은 임베디드 시스템 환경을 고려하고 설계하였기 때문에 전원 관리를 위한 다양한 모드를 지원한다.
이러한 프로세서의 동작 모드를 확인하고 동작 모드에 대한 테스트를 시작하는 것이 윈도 임베디드 시스템 개발에서 전원 관리 시스템을 구현하기 위한 시작이다. 간단히 프로세서가 가지는 동작 모드를 살펴본다면 다음과 같다.
(1) 일반적인 동작 모드
(2) 동작 주파수 및 사용 전압을 낮춘 상태
(3) 최소 전원 상태
(4) 완전히 전원을 꺼서 동작을 안하는 상태
등으로 크게 구분할 수 있다. MP3 음악을 듣거나 사용자의 입력이 많아 처리 할 일들이 많을 때는
물론 프로세서 제조업체에서 제공하는 BSP에 전원 관리를 위한 기본적인 기능들은 다 포함되어 있다. 이 BSP를 바탕으로 최적의 사용 시간을 유지하도록 다양한 시나리오와 테스트를 바탕으로 전원관리 기능을 구현해야 한다.
On/Off
시스템의 전원키를 눌러 전원을 끄고, 다시 전원 버튼을 눌러 전원이 켜지게 한다. 이상하게도 윈도 임베디드 시스템을 사용한 임베디드 시스템은 빠르게 전원이 꺼지고, 다시 켜지는 시간 역시 매우 빠르다. 과연 그 이유는 뭘까? 윈도 임베디드 시스템은 시스템의 전원을 완전히 끄는 대신에 시스템의 전원을 최소화 하는 방법을 선택했기 때문이다(이 기능을 Suspend 시킨다고 한다. Suspend 상태에서 원래 상태로 복귀하는 작업을 Resume 한다고 명칭 한다)
파워 스위치의 간단한 구현 방법(왜냐하면 공급되는 전원을 공급하거나 차단하거나 둘 중 하나의 방법으로 간단히 제어 할 수 있기 때문에)을 사용해도 되는데 왜 이런 기능을 사용할까? 의문이 들 수도 있다.
이것은 윈도 임베디드 CE 운영체제의 초창기 시절로 거슬러 올라가야 한다. 윈도 임베디드 시스템 운영체제는 PDA와 같은 휴대 장치를 위해 만들어 졌다.
특히 PDA는 수시로 일정이나 메모를 할 수 있도록 파워키를 누르면 바로 화면이 켜지는 형태로 구현됐다. 이런 기능을 구현하기 위해서는 완전히 전원이 켜지고/꺼지는 형태가 아닌 프로세서의 전원을 최소화 했다가 다시 복귀할 수 있는 형태의 기능이 필요하다. 이런 기능을 이어받아 지금까지 발전해 왔고 윈도 임베디드 시스템의 중요한 기능으로써 자리잡고 있다.
물론 완전이 전원을 끄고 키는 형태로도 구현이 가능하다. 현재 출시되는 내비게이션 장치나 PMP와 같은 장치는 비록 휴대하거나 장착해서 사용하는 장비이기는 하나 사용 목적이 분명하기 때문에 On/Off 스위치로도 충분히 그 기능을 할 수 있다. 하지만 PDA장치나 스마트폰과 같은 장치들은 이와 같은 기능을 사용한다. 좀더 자세히 윈도 임베디드 시스템에서의 전원 On/Off 혹은 Suspend/Resume 작업을 살펴본다면 다음과 같다.
Suspend시
(1) 사용자가 파워키를 눌러 임베디드 시스템 장치의 전원을 Off 시킨다.
(2) 파워키를 관장하고 있는 파워키 드라이버(PowerKey Device Driver)는 사용자의 명령을 감지하고 커널에게 Suspend 상태로 진입할 것을 요청한다.
(3) 커널은 전체 전원관리자인 PM.DLL에게 Suspend 상태로 진입할 것을 요청한다. 또한 동작하고 있는 쓰레드들의 동작을 멈추게 한다.
(4) PM.DLL은 각 드라이버들에게 명령하여 각 장치가 Off되거나 최저 전류 소모 상태가 되도록 명령한다.
(5) 모든 디바이스 드라이버가 Off 되면 커널은 OEMPowerOff 함수를 호출한다.
(6) OEMPowerOff 함수는 SDRAM의 있는 내용이 보존되도록 self-refresh 상태가 되도록 하고, 각종 외부장치를 저전력 상태로 유지 시킨 후 프로세서를 정지 상태로 만든다.
사용자의 명령을 통해 프로세서가 정지 상태에서 깨어나는 Resume 상태는 위 과정의 역순이다. 복잡해 보이는 Suspend/Resume 과정은 윈도 임베디드 CE 운영체제를 개발해 가는데 있어서 중요한 부분 중에 하나이다. 이 밖에도 동작 중에 어떻게 하면 전류 소모를 줄이면서 오래 사용할 수 있을까 하는 문제 역시 중요한 문제다.
전원 관리의 또 다른 면
한정된 자원 한정된 능력을 최대로 이용할 수 있게 하는 것은 '효율적'이다는 단어로 압축해서 말할 수 있다. "이 제품은 1번 충전해서 3시간을 사용하는데 이 제품은 2시간 밖에 사용하지 못한다!"는 등의 임베디드 시스템 제품 사용기를 간혹 볼 수 있다. 이런 차이는 무엇일까?
같은 프로세서를 사용하고 비슷한 메모리에 비슷한 하드웨어 구성을 가지고 있다 하더라도 차이는 발생한다. 이런 '효율적'인 제품들은 다음과 같은 기능을 가지고 있을 것이라고 생각한다.
1) 전류 소비를 최소화 하는 하드웨어 설계 - 하드웨어 설계시에 적은 전류를 소비하는 제품을 사용하고 장치를 껐을 때 누설되는 전류가 없도록 하드웨어를 설계해야 한다. 오디오와 같은 장치는 하드웨어의 전원을 완전히 끈다기 보다는 가장 최소의 전류를 먹는 Sleep 모드 상태로 장치의 상태를 변경한다. 이때 전류를 최소한으로 소비되도록 구성해야 한다.
(2) 사용자의 사용 시나리오에 맞게 사용 운영 소프트웨어 구성 - 사용자가 음악을 들을 때는 LCD 화면을 터치하거나 키를 누르는 동작이 적어진다. 따라서 LCD 화면의 백라이트나 LCD 화면의 밝기를 조금 낮추어도 사용하는데 문제는 없다. 이런 식으로 사용자의 사용 패턴이나 사용 시나리오에 맞추어 각 장치들을 능동적으로 제어함으로써 전류 소비를 최적화 할 수 있는 시스템을 구현할 수 있다. 물론 잘못된 시나리오는 더 안 좋은 효과를 가져올 수 있다. 최적의 시나리오는 물론 하루아침에 나오는 것은 아니다. 반복적인 테스트를 통해야지만 만들어 낼 수 있다.
(3) 유휴상태나 대기 상태에서 전류 소모를 최소화 하게 함 - PC에 대한 사용기를 보면 오버클락(OverClock)에 대한 내용이 종종 나온다. 시스템에서 사용되는 주파수를 어떻게 했더니 더 빨라지고 성능이 향상되었다는 내용이다. 물론 윈도 임베디드 시스템에서도 그와 같은 일을 할 수 있다. 물론 반대지만 말이다. 시스템의 성능과 전류 소모는 불가분의 관계이다. 시스템의 동작 속도가 빨라질수록 전류 소모도 그만큼 많아진다. 이러한 점에 착안하여 유휴 상태에서는 사용자는 프로세서의 속도를 낮추어 전류의 소모를 줄이는 방법을 사용한다. 이러한 유휴 상태가 더 지속이 되면 더욱더 속도를 낮추는 방법을 취한다. 이 방법의 장점은 사용자의 사용 형태에 따라 혹은 유휴 상태에서 일반적인 동작 상태보다 전류를 덜 소비하기 때문에 더욱더 많은 사용시간을 보장하는데 있다.
Actvity Timer
윈도 임베디드 시스템에서 사용자의 입력을 감지하고 사용자가 사용중임을 알 수 있을까? 물론 키를 누르거나 터치스크린을 터치 하거나 하는 등의 직접적인 입력 작업을 통해 사용자가 사용하고 있음을 알릴 수 있다. 하지만 디바이스 드라이버와 같이 사용자의 입력과 관계없는 부분에 있어서는 어떻게 처리를 해야 하는 가에 대해 의문을 가질 수 있다.
윈도 임베디드 CE 운영체제에서는 이를 위한 여러 가지 방법 중 'Activity Timer'라는 기능을 통해 커널에 현재 동작중임을 알리는 기능을 제공하고 있다. Activity Timer는 일종의 타이머다. 윈도 임베디드 CE 운영체제 커널에서 관리하는 타이머로 이 타이머에 설정된 시간 전에 이벤트를 호출하면 타이머가 자동적으로 리셋이 되면서 현재 활동 중이라는 것을 커널에게 알리는 방법이다. 다시 말하면 현재 동작중임을 주기적으로 알려 운영체제가 저전력 모드로 진입하지 못하도록 하는 기능이다. 인터넷을 통하여 파일을 다운로드 받을 때 비록 LCD 화면으로 진행 상태를 나타낼 필요는 없지만 네트워크와 관련된 드라이버들은 활발하게 동작하고 있다. 사용자의 입력이 없다고 유휴 상태로 빠지거나 동작 속도를 낮추는 방법은 바람직하지 않기 때문에 네트워크 드라이버는 이러한 Active Timer를 이용하여 커널에 주기적인 신호를 보내는 방법을 사용하게 된다.
배터리
모든 휴대용 장치는 배터리를 사용하고 있다. 윈도 임베디드 CE 운영 체제를 탐재하고 있는 대부분의 임베디드 시스템 장치 역시 배터리를 사용하고 있다. 전원 코드로 부터 자유롭게 해주는 배터리는 사용하기도 간편하고 안전하지만 개발자에게는 고민해야 할 또 하나의 숙제다. 전원 관리와 배터리와는 직접적인 관련은 없다. 하지만 사용자에게 정확한 사용 가능 시간을 알려주는 것은 중요한 일이다. 노트북의 경우 스마트 배터리라고 해서 배터리의 잔량을 정확히 알려준다. 하지만 일반적인 임베디드 시스템의 경우 스마트 배터리와 같은 가격이 비싼 배터리를 사용하지 못하기 때문에 보호회로가 내장된 단순한 형태의 충전지를 사용하고 있다.
또한 배터리의 잔량을 측정하는 방법으로 배터리의 전압을 측정하여 사용 시간을 예측하는 방법을 사용하고 있다. 이 방법의 단점은 임베디드 시스템의 사용 방법이나 주변 온도에 따라 전압이 변하기 때문에 정확한 값을 측정하는 것이 어렵다는데 있다. 이러한 점을 보완하기 위해 여러 가지 측정 알고리즘을 도입해야 한다. 측정한 데이터를 보관하고 있다가 급격히 변할 때는 앞의 측정한 값을 가지고 보정을 해 주는 등의 보완 방법이 필요하다. 전원 관리를 하는 것도 중요하지만 정확한 배터리의 사용시간 사용자에게 알려 사용하게끔 하는 것도 중요하다는 것을 명심하기 바란다.
디바이스 드라이버와 전원 관리
윈도 임베디드 CE 운영체제에서 커널과 전원 관리자인 PM.DLL은 시스템의 전체적인 전원을 관리한다.
각 디바이스 드라이버도 이러한 구조를 따라야 한다. 디바이스 드라이버는 전원 관리자와 긴밀한 관계를 가지며 동작하게 된다. 디바이스 드라이버와 전원 관리자와의 관계는 매우 밀접하며 주기적으로 상태를 알려주어야 한다. 그럼 디바이스 드라이버는 어떻게 전원 관리자와의 관계를 설정하며 주기적으로 디바이스 드라이버 자체의 상태를 보고 하는가?
우선 다음 정의와 같이 디바이스 드라이버에 따라 시스템에 디바이스 드라이버가 어떠한 전원 관리 기능을 제공하는지 전원 관리자에게 통보 하게 된다.
#define PMCLASS_GENERIC_DEVICE TEXT("{A32942B7-920C-486b-B0E6-92A702A99B35}")
#define PMCLASS_NDIS_MINIPORT TEXT("{98C5250D-C29A-4985-AE5F-AFE5367E5006}")
#define PMCLASS_BLOCK_DEVICE TEXT("{8DD679CE-8AB4-43c8-A14A-EA4963FAA715}")
#define PMCLASS_DISPLAY TEXT("{EB91C7C9-8BF6-4a2d-9AB8-69724EED97D1}")
통보하는 방법은 다음과 같이 디바이스 드라이버를 시스템에 등록할 때 사용하는 레지스터리 정보에 Iclass라는 항목을 통해 디바이스 드라이버의 전원 관리 기능을 지정한다.
[HKEY_LOCAL_MACHINEDriversBuiltInMyDriver]
"Prefix" = "XXX"
"Dll" = "MyDriver.DLL"
"Index" = DWORD:1
"Order" = DWORD:1
"IClass"="{A4E7EDDA-E575-4252-9D6B-4195D48BB865}"
표 3. 플래시 드라이버 관련 기본 함수들
디바이스 드라이버 내에서는 <표3>과 같은 IOCTL을 구현하여 디바이스 드라이버와 전원 관리자와의 통신 방법을 구현한다. PM.DLL과 각 디바이스 드라이버는 IOCTL을 통하여 현재 상태 보고 및 디바이스 드라이버 전원 관리를 하게 되는 것이다.
XXX_PowerDown, XXX_PowerUp
윈도 임베디드 CE 운영체제의 디바이스 드라이버는 이전에 설명한 것처럼 XXX_Open(), XXX_Close()
마찬가지로 장치가 제대로 동작하게 하기 위해서 전원을 On시키는 드라이버내의 함수로 XXX_PowerUp(), Off 시킬 때는 XXX_PowerDown()는 함수가 호출된다. 드라이버를 개발 시 드라이버 내에서 관리할 장치들의 실질적인 전원 관리 함수로 XXX_PowerDown(), XXX_PowerUp() 함수를 사용한다는 것을 잘 알아두기 바란다.
응용 프로그램에서 전원 관리
응용 프로그램은 운영체제 위에서 돌아가는 프로그램이다. 따라서 운영체제가 관리하는 전원관리와는 별도로 돌아가야 한다. 하지만 윈도 미디어 플래이어 같은 프로그램을 실행시켜보면 좀 다른 점을 발견할 것이다. 동영상을 재생하고 있을 때는 LCD의 백라이트 및 화면이 꺼지지 않고 유지되고 있다. 심지여 설정에서 자동 꺼지는 것을 지정했더라도 말이다. 이러한 기능은 응용 프로그램에서 운영체제의 설정을 변경하지는 않지만 응용 프로그램이 동작하기 위해 필요한 전원관리 요소들을 운영체제에 통보하고 운영체제는 그 요구를 들어줘 전원 관리 상태를 유지하는 동작이다.
응용 프로그램 혹은 디바이스 드라이버는 전원 관리 함수를 사용하여 응용 프로그램에서 필요한 디바이스 드라이버의 전원 상태를 제어할 수 있다. 다음 프로그램은 응용 프로그램에서 오디오 드라이버 장치가 전원이 켜져 있도록 전원 관리자에게 요청하는 코드이다.
SetPowerRequirement(TEXT("WAV1:"), D0, POWER_NAME, NULL, 0);
응용 프로그램에서 필요한 장치의 사용을 마쳤을 때는 ReleasePowerRequirement() 함수를 이용하여 전원 관리자에게 통보해 준다. 이와 같이 응용 프로그램에서도 윈도 임베디드 운영체제의 전원 관리에 관한 정책을 조정하여 운영할 수 있는 것이다.
끝으로
지금까지 윈도 임베디드 CE 6.0의 그래픽 처리에 대해 살펴봤다. 너무 방대한 내용을 짧게 정리하다 보니 심도 있게 다루지 못한 것 같아 아쉬움을 남긴다. 부족한 부분에 대해서는 아직 남은 연재 기간 동안 내용을 보충할 것을 약속 드리며 12월호의 내용을 마친다.
회원가입 후 이용바랍니다.
개의 댓글
댓글 정렬
BEST댓글
BEST 댓글
답글과 추천수를 합산하여 자동으로 노출됩니다.
댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
그래도 삭제하시겠습니까?
댓글수정
댓글 수정은 작성 후 1분내에만 가능합니다.
내 댓글 모음