에러블로그

• 말 많은 비서
  • win, web, msnp, sms ...
  • 비서학 책이라도 하나 사다봐야겠다.
• avr usb-hid
  • ggum controller - full size
  • ggum controller - handy
  • scratch (turn table)
  • 동시키입력 (지금 HID 버전으론 6키까지 밖에 안되나? 다음 버전이..)
  • key mapper (hid keyboard spec에서 report output 말고 input 도 가능한건가? 바꿔야 하나?)
  • http://ggums.ohpy.com
  • 팝픈, 아스토레인져, ez2on 그리고?
• wince kernel, driver, application
  • ...job
• etc
  • 운전면허 (WIS 끝나면 바로 하자. 야간반 좋드만?)
  • 이모네 팬션 홈페이지 -_-;;

io control 은 장치를 file처럼 다루는 read, write, seek 등으로는 부족함을 느낄 때 사용하는 부분.

귀찮으면 그냥 read/write에 첫바이트는 기능 구분.. 나머지는 데이터... 뭐 이런 무식한 꽁수를 써도 문제는 없을 듯.

대략 초보용.

리눅스의 ioctl과 같은 기능임.

---

디바이스 드라이버

XXX_IOControl() 함수 머리

BOOL XXX_IOControl(
  DWORD dwInst, // 써본 적 없음. ISR handler 의 인스턴스라는데 -_-a
  DWORD dwIoControlCode, // IO Control 코드. 기능들로 분기 시키기 위한 코드.
  LPVOID lpInBuf, // 어플리케이션에서 넘겨주는 데이터 버퍼
  DWORD nInBufSize, // 그 크기
  LPVOID lpOutBuf, // 드라이버가 어플리케이션에게 건네줄 데이터 버퍼
  DWORD nOutBufSize, // 그 크기
  LPDWORD lpBytesReturned // 써본 적 없음. 오류 처리용인가보다 -_-;
)

일단 머리가 저렇게 생겼고 각 파라미터들의 용도는 저렇다. 아직 모르는건? 우짜나 -_-;

XXX_IOControl 함수 내용

 switch(dwIoControlCode)
 {
 case IOCTL_XXX_CMD_A :
  memcpy(myTemp, lpInBuf, nInBufSize);

  break;
 case IOCTL_XXX_CMD_B :
  memcpy(lpOutBuf, myTemp, nOutBufSize);
  break;

 case IOCTL_XXX_CMD_C :
  myFunc();
  break;

 default:
  RETAILMSG(1,(TEXT("XXX : unknown io control code! \n\r")));
  break;

}

보다시피 IOCTL_XXX_CMD_A, IOCTL_XXX_CMD_B, IOCTL_XXX_CMD_C 를 사용했다.

각각
IOCTL_XXX_CMD_A 는 어플리케이션이 주는 데이터를 myTemp 라는 임시공간에 저장하고,
IOCTL_XXX_CMD_B 는 myTemp에 있는 데이터를 어플리케이션에게 건네주는 기능이며,
IOCTL_XXX_CMD_C 는 다 필요없고 그냥 myFunc()라는 함수를 호출한다..

물론 실제 구현은 단순히 메모리를 복사하는 내용으로 끝나진 않겠지만 나머지 부분은 사용자의 목적에 맞게 구현하면 된다.

그럼 대체 이 switch case분기용 IOCTL_XXX_CMD_X 는 어떻게 만든 걸까?
여기서는 CTL_CODE라는 매크로가 사용된다.

CTL_CODE 는
#define CTL_CODE(DeviceType, Function, Method, Access) (
  ((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)
)

이렇게 생겨먹었는데..
이건 각 기능에 대한 고유 ioctl번호를 생성하기 위한 매크로다.
[DeviceType][Access][Function][Method] 형태로 unsigned 4byte 짜리 숫자를 생성한다.
결과물이 어떤 값인지 알아도 좋지만 별로 알 필요는 없다. 매크로는 바뀌거나 바꿀 수도 있으므로 그냥 쓰면 된다.

CTL_CODE(DeviceType, Function, Method, Access) 이다.

DeviceType :
리눅스에서도 비슷한게 있다. 장치에 대한 번호다.
MSDN - CTL_CODE 페이지나 {winceroot}\public\common\oak\inc\windev.h 를 열어보면 명세들이 있다.
FILE_DEVICE_XXX 시리즈가 사용된다.
근데... MSDN을 잘보면 0~0x7FFF 까지는 지네거란다 ㅡ.ㅡ
우리같은 OEM들은 MS규격 장치의 드라이버를 만드는게 아니라면
0x8000 ~ 0xFFFF 를 쓰면 된단다.
저 중에 하나 정하자.

Function :
장치의 기능들에 대한 부분이다. 여기서도 0~0x7FF 는 MS에서 쓸거라니까
0x800 ~ 0xFFF 중에 구현할 장치의 기능 만큼 골라 쓰자 -_-;

Method :
이거 이제 안쓴단다. 무조건 METHOD_BUFFERED 만 쓰란다.
데스크탑용 Windows에서는 좀 다르니까 주의하란다.

Access :
읽기를 할까? FILE_READ_ACCESS
쓰기를 할까? FILE_WRITE_ACCESS
둘다할까? FILE_ANY_ACCESS
복잡하고 별로 무의미하니 걍 FILE_ANY_ACCESS 쓰면 될 것 같다.

그래서 내가 선언한 선언부는 이렇다. (드라이버 소스 시작단에 넣었다.)

#define MYDEVICE 0x8001
#define MYDEVICE_FUNC 0x800
#define IOCTL_XXX_CMD_A  CTL_CODE(MYDEVICE, MYDEVICE_FUNC+1, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_XXX_CMD_B  CTL_CODE(MYDEVICE, MYDEVICE_FUNC+2, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_XXX_CMD_C  CTL_CODE(MYDEVICE, MYDEVICE_FUNC+3, METHOD_BUFFERED, FILE_ANY_ACCESS)

첫번째 DeviceType은 OEM용 장치타입 코드 영역인 0x8000~0xFFFF 중에 0x8001 을 골라썼고 (이건 장치마다)
두번째 Function 역시 OEM용 기능구분 코드 영역 0x800 ~ 0xFFF 에서 순서대로 0x801~0x803를 썼다. (이건 기능마다 달라야한다.)

그럼 이제 CTL_CODE도 만들었고, 드라이버 소스도 작성했으니 어플리케이션으로...

---

어플리케이션

어플리케이션에서도 CTL_CODE를 알아야한다. (저 매크로의 결과값을 옮겨도 되겠지만)
그러니 코드를 생성하는 매크로 부분을 어플리케이션 소스에도 복사한다. (혹은 같은 헤더파일로 공유한다.)

#define MYDEVICE 0x8001
#define MYDEVICE_FUNC 0x800
#define IOCTL_XXX_CMD_A  CTL_CODE(MYDEVICE, MYDEVICE_FUNC+1, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_XXX_CMD_B  CTL_CODE(MYDEVICE, MYDEVICE_FUNC+2, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_XXX_CMD_C  CTL_CODE(MYDEVICE, MYDEVICE_FUNC+3, METHOD_BUFFERED, FILE_ANY_ACCESS)

어플리케이션의 헤더에 붙여넣고 자신만만하게 컴파일 시키면
CTL_CODE, METHOD_BUFFERED, FILE_ANY_ACCESS 가 정의된 적 없다고 컴파일러가 외친다.
여기서 나는 PB에서 제공하는 windev.h의 내용을 복사해다 붙여버릴까... 하는 충동을 느꼈지만 (실제로 그렇게 해보기도 했다.)
무식하게 하지 말자고 충동을 억누르고 어플리케이션에서 참조하는 SDK의 헤더를 뒤져봤다. (라고 쓰고 'editplus의 여러파일찾기'라고 읽는다.)

아싸. winioctl.h 에 다~~포함되어있다.
#include <winioctl.h> 을 CTL_CODE 정의부 위에 추가한다.

이제 DeviceIoControl 함수를 사용할 때 가 되었다.

BOOL DeviceIoControl(
  HANDLE hDevice, // 열어놓은 XXX 장치의 핸들
  DWORD dwIoControlCode, // 호출할 CTL_CODE
  LPVOID lpInBuffer, // 드라이버에게 넘겨줄 데이터 버퍼
  DWORD nInBufferSize,  // 그 크기
  LPVOID lpOutBuffer,  // 드라이버에게서 넘겨 받을 데이터 버퍼
  DWORD nOutBufferSize, // 그 크기
  LPDWORD lpBytesReturned, // XXX_IOControl에서의 lpBytesReturned 와 연결되는 놈이다. 난 몰라~~ -_-;
  LPOVERLAPPED lpOverlapped // 무시된다. NULL로 세팅할 것.
);

모양새는 저렇게 생겨먹었고,
사용해보자. (아래의 내용은 위 드라이버의 소스와 맞춰가며 보면 좋다.)

// lpBytesReturned 용이다. 난 안쓰는데 필요로 하길래 지정해줬다. 쳇 -_-;
DWORD bytes;

// IOCTL_XXX_CMD_A 를 호출한다.
// pWritrBuf 의 내용을 pWriteBuf의 크기만큼 드라이버에게 넘겨준다.
// 이 내용은 디바이스 드라이버의 XXX_IOControl 이 받아서,
// IOCTL_XXX_CMD_A 분기로 들어가고,
// myTemp에 여기서 건네주는 pWriteBuf의 데이터를 pWriteBuf의 크기만큼 memcpy하게 된다.
DeviceIoControl(hDev, IOCTL_XXX_CMD_A, pWriteBuf, sizeof(pWriteBuf), NULL, 0, &bytes, NULL);

// IOCTL_XXX_CMD_B 를 호출한다.
// pReadBuf 의 내용을 pReadBuf의 크기만큼 드라이버에게 넘겨준다.
// 이 내용은 디바이스 드라이버의 XXX_IOControl 이 받아서,
// IOCTL_XXX_CMD_B 분기로 들어가고,
// 디바이스 드라이버가 갖고 있던 myTemp의 내용을 pReadBuf에 pReadBuf의 크기만큼 memcpy 해준다.
// 그럼 드라이버에서 값을 가져왔으니 맘대로 쓰면 된다.
DeviceIoControl(hDev, IOCTL_XXX_CMD_B, NULL, 0, pReadBuf, sizeof(pReadBuf), &bytes, NULL);

// IOCTL_XXX_CMD_C 를 호출한다.
// 디바이스드라이버에  데이터 주고 받는 것 없이 명령을 내리는 거다.
// XXX_IOControl의 IOCTL_XXX_CMD_C 분기로 들어가서 myFunc(); 함수를 호출한다.
DeviceIoControl(hDev, IOCTL_XXX_CMD_C, NULL, 0, NULL, 0, &bytes, NULL);

---

이후의 의문

CTL_CODE 매크로 없이 IOControl Code를 0x01, 0x02 뭐 이런식으로 쓰면 안될까?
-> 되더라 -_-a 별 문제 없던데...
그럼 Function Code는?
-> 되더라 -_-a 이것도 별 문제 없던데... 귀찮게 스리 뭘 그리 정의 해놓고 그런건지.. ㅠㅠ
그럼 Method나 Access도 NULL 로 줘버리면?
-> 되더라 -_-a

위 내용으로 미루어봤을 때, CTL_CODE는 정말 단순히 충돌예방을 위해 각기능에 대한 고유번호를 매기는 매크로일 뿐이다.
사실 각 장치를 열어서 호출하는 것이니 만큼 충돌 날 일도 없을 걸로 예상되는데,
디버깅용으로 필요할 것 같다.

그래도 저렇게 하라고 msdn에 적어놨으니 귀찮지만 맞춰서 써주자.

---

- 끝 -

Microsoft의 OS는 크게 3가지로 나뉜다.

-----------------------------------------------
.Net Micro Framework

OS는 아니다. (하지만 무려 Thread도 지원한다.)
AVR등이 주로 쓰이고 있는 환경을 .NET 으로 도배할 야심찬 계획. (센서노드가 분명 계산에 들어갔을거다)

WPF, XML도 지원한다.
HTTP Client 도 들어있던가? 하지만 가장 기대했던 Web Service Client는 없었다. 쳇.

Windows Vista 탑재 노트북의 SideShow 기능, 조금 더 Smart한 기능을 지원하는 시계서비스 (SPOT)등에 도입되어있다.

현재 지원 CPU는 ARM7, 9

물론 HAL은 하드웨어 제조사에서 자신들의 보드에 맞춰 직접 개발해야 한다.

-----------------------------------------------

Windows CE 계열
수도 없이 이름을 바꾸고는 있지만 -_-;

현재는 Windows Embedded CE로 부르고 있다. (곧 또 바꾼단다.)
이 계열에는
Windows Mobile / for XXX Edition s (예전의 Pocket PC)
과 Windows CE가 있다.

Windows Mobile은 PDA나 핸드폰에 탑재된다.
ARM9, MIPS 이상의 CPU가 필요하다.
Pocket PC 2002, 2003 은 Windows CE 3.X
Windows Mobile 5(?),6 는 Windows CE 5.X 의 커널을 사용.

Windows CE는 POS(마트 계산대)나 조금 대형 사이즈 PDA (PMP, 네비) 등에 많이 들어간다.

OS 포팅 과정은 PC처럼 표준화된 환경에 단순히 설치하는 작업이 아니다.
하드웨어에 맞추어 초기화과정, 인터럽트 세팅 등이 기본적으로 필요하며,
각 장치드라이버들을 구현 해주어야 한다. (이런 것들은 리눅스도 마찬가지.)

주로 OAL이라고 부르는 영역을 개발해주어야 하며,
거기에 더해 쉘을 자기가 원하는대로 바꾸고 싶다거나 한다면
엄청난 리소스노가다가 따라온다는 것을 잊지말자.

...그래도 CE에서는 .net 이 되잖아 *-_-*


-----------------------------------------------

PC 용 Windows

x86, x86 64bit CPU를 지원한다.
Windows XP, Windows Vista 등등
알다시피.

변종으로 컴포넌트들을 맘대로 세팅할 수 있는 Windows Embedded XP 와 곧 나올 Embedded Vista 가 있다.
오락실의 pump/ez2dj, 공장, POS 등에 활용된다.

가격도 일반 OS에 비해 저렴하고 pc windows 와 거의 완벽히 호환되는 게 장점이다.
-----------------------------------------------

공통점은 .net 으로 대동단결이 되며, 개발툴은 visual studio을 이용한다는거다.

학생들에게 무료로 개발툴을 지원하는 프로그램(일종의 행사?)이다.

공부하는 학생개발자들에게 자기네 플랫폼에 완전히 물들게 하기 위한?

뭐... 일단 좋다. (난 학생이 아니라 안좋다 ㅜㅜ)


굳이 불법 CD 다운받지 않고도 쓸 수 있게 되었으니 등록해서 써보자..

이 프로그램에 등록하여 혜택을 받기 위해선 국제학생증이 필요하다.

자세한 내용은 나중에 덧붙이겠음.


...

그나저나 Microsoft는 신흥 종교라도 되고 싶은건지..-_-;;

evangelist는 뭐냐고! -_-;;

두가지 컴포넌트가 포함된 project의 sdk가 필요로 할 수 있다.
AYG Shell 과 Network..뭐더라 -_-

Standard SDK 소스와 custom sdk를 비교해 봤을 땐 거의 무조건 있어야 되는 것으로 보인다.

AYG Shell 은 라이센스가 Professional 라서 Core를 쓰고자 한다면 골치가 좀 아플 듯.

Windows Embedded CE 6.0 부터는 아예 MFC 컴포넌트가 제외되어서 직접 라이브러리를 추가해야하는 걸로 봐선...

마소에서 '이제 MFC 그만 좀 쓰셈!' 하는 것으로 보인다. (MFC 좋은데... 우쒸... 버그가 꽤 있어서 그렇지..)

그런데 확실히 .net 의 퍼포먼스가 많이 좋아졌다.(컴퓨터가 좋아진건가?) 쉽고. 편하고.

.Net Micro Framework 도 써보고픈데..

보드 안사고 회사 보드에서 써볼라믄 이거 또 내가 포팅해야될까봐서리... 시간도 없는데 귀찮아서 -_-;

Windows 에서 Wide Character 는 UNICODE 를 의미한다.

--------------------------------

매크로
_T("ABC")
TEXT("ABC")

"ABC" 대신 위에 것들을 쓰자.
UNICODE로 컴파일하면 UNICODE문자열로, ASCII로 컴파일하면 ASCII 문자열로 인식한다.

--------------------------------

windows (ce포함)용 c/c++의 string 처리에서 알아두면 좋은 거.

문자열의 길이를 재는 함수라면?
strlen() : ASCII용 문자열 길이 쟤는 함수
wcslen() : UNICODE용 문자열 길이 쟤는 함수
_tcslen() : 환경에 맞추어지는 매크로

뭐 일단 _mcslen() 도 있긴하다. (MB환경에서 strlen을 호출하면 이쪽으로 연결할걸?)

다른 함수들도 마찬가지다.

strXXXX() 함수들이 wcsXXXX()로, tcsXXXX() 로 바꾸어 쓰면 된다.

strtol : ASCII 문자열에서 long 값으로 변환 (atoi와 비슷하지만 진수 지정 가능)
wcstol : UNICODE ~~~
_tcstol : 환경 ~~~

-------------------------------

그럼 다 지원하려면 가장 깔끔한 방법은?
tcsXXXX() 시리즈를, char 대신 매크로 TCHAR 쓰는거.

물론 덕분에 골치아픈 문제도 가끔 발생한다는거..

-------------------------------

WideCharToMultiByte() : UNICODE -> ASCII

MultiByteToWideChar() : ASCII -> UNICODE

--------------------------------

char : ASCII
wchar_t : UNICODE
TCHAR : 환경 따라가는 매크로

--------------------------------

CString은 내용이 wchar일 수 도, char일 수 도 있음에 유의할 것.

--------------------------------

eVC++ 이나 SmartDevice(WinCE)용으로 사용하는 Visual Studio 시리즈는 기본설정이 UNICODE 환경으로 되어있다.
ASCII를 쓰고 싶다면 컴파일설정 (프로젝트 속성?) 을 바꾸어 주어야한다.

--------------------------------

아... Windows Embedded CE 6.0 부터는 기존 문자열 함수들에 문제가 있을 수 있다고 해서...
safe 시리즈를 선보였다. 젠장.

예를들어 strcpy 라면 strcpy_s 이런식이었던 듯...
대충 봤을 때 문자열 종료 문자 '\0'가 문제가 있다고 파악한 모양이다.

기대된다. 유후~!

오랜만에 CD나 질러볼까 (이제는 CD롬도, CD플레이어도 없으니 또 mp3나 지를까 ㅜㅜ)

김진표의 라임(이라던가?) 타는 읍조림은 어찌나 멋지던지.

타인의 사생활엔 그리 관심이 없다보니 몰랐는데 이혼 한지도 꽤 되었고,
이번에 새 장가 가면서 기념으로 앨범 내놨다보다.

이전 싱글에선 아픔,덧없음,외로움?을 외쳤지만 이번엔 행복함을 읍조릴라나...

박정현 참여 곡도 있던데 꽤나 기대됨. (4집에서 '시간이 필요해'도 꽤나 좋았음)


이러면서 사는거지 뭐...

쩝.