WDM USB 드라이버

출처 : http://muosys.egloos.com/172966

 

우리가 인터페이스로 USB를 선택한 이유는 다른 여타의 인터페이스들과 마찬가지로 디바이스가 컴퓨터와 통신할 필요가 있기 때문이다.
다만 USB가 넓은 대역폭, Plug&Play등의 장점을 가지기 때문에 다른 인터페이스들에 비해 선호될 뿐이다.

Serial(RS232)을 이용하여 우리가 만든 디바이스와 컴퓨터(Win32 Application)간의 통신이 어떻게 이루어 질까?

아마 대부분의 행자들이 알고 있겠지만, 파일 입출력을 할 때와 동일하게 ReadFile(…), WriteFile(…)을 이용하여 디바이스에 데이터를 주거나 받는다.
ReadFile이나 WriteFile을 호출하기 위해서는 파일핸들이 필요하므로 CreateFile(\\.\COM1…)을 호출해서 File Handle을 얻은 다음, 위 두 함수에 인자(Parameter)로 넘겨주어야 한다.
물론 더 이상 장치에 접근할 필요가 없을 때에는 CloseHandle(…)을 사용하여 운영체제로 파일 핸들을 반환하는 것도 잊지 말아야 한다.

디바이스와 통신하는데 사용하는 API는 ReadFile과 WriteFile 이외에도 DeviceIoControl(…)이라는 함수도 있다.
ReadFile, WriteFile이 함수의 이름 그대로 데이터를 읽거나 쓰기만을 위한 함수라면, DeviceIoControl은 디바이스에 데이터를 주고, 동시에 데이터를 받을 수 있다.
예를 들면, Default Control Endpoint을 통해 데이터를 주고 받는 연습을 했던 이전 강의에서 두 값을 디바이스에 주고, 디바이스로부터 그 값의 곱을 리턴받을 때 DeviceIoControl을 사용할 수 있다.
물론 WriteFile로 값을 주고, ReadFile로 결과를 읽을 수도 있겠으나 DeviceIoControl로 한번에 처리하는 것이 훨씬 편리할 것이다.
통상 Read/Write파일은 대량의 데이터를 이동시키는데 사용되고, DeviceIoControl은 그 이름이 의미하는대로 디바이스를 컨트롤하기 위한 소량의 데이터를 이동시키는데 사용된다.
꼭 그렇게 해야 된다는 제약은 없지만 말이다.

Serial(RS232)을 이용해 컴퓨터(Win32 Application)와 디바이스와 통신하는 것과 똑같은 방법이 USB에도 사용된다.
CreateFile로 파일 핸들(USB Handle)을 얻고, ReadFile/WriteFile/DeviceIoControl을 통해 USB 디바이스에 접근하며, CloseHandle로 핸들을 반환한다.
졸라 쉽지 않은가?
봐라. 알면 별거 없다.

이제까지 펌웨어를 테스트하면서 썻던 EZ-USB Control Panel도 그 안에서 위의 함수들을 이용해 디바이스와 통신을 한다.

근데 EZ-USB Control Panel이 ezusb.sys라는 드라이버를 사용해서 장치로 접근을 하듯이 디바이스에 접근하기 위해서는 드라이버가 필요하다.
우리는 MS의 Windows에서 장치에 접근하기를 원하기 때문에, 더 정확히 말하자면 WDM(Windows Driver Model) 드라이버가 필요하다.

머리 꼬리 다 띄고, 몸통을 덥썩 물어보자.
어디서 우리가 만든 USB 디바이스와 물릴 USB 드라이버를 구할 것이냐?
세가지 방법이 있다.
첫째, 드라이버를 만들어주는 툴을 이용한다.
둘째, 칩 제조사가 제공하는 드라이버를 사용한다.
셋째, 직접 드라이버를 작성한다.

각기 나름대로의 장단점이 있다.
첫 번째 방법은, 대표적으로 Jungo社의 WinDriver같은 툴을 사용해서 (그들이 주장하는 바로는 초보자도 클릭 몇방으로) WDM 드라이버를 만들 수 있다.
본좌도 예전에 그 광고문구에 혹하여 몇 번 시도를 해 보았으나 번번히 OTL하고 말았다.
분명히 그때 본좌는 쌩초보는 아니었고, 디바이스 드라이버에 대한 개념은 가지고 있다고 자부 했었는데, 고것만 갖고는 부족했었나 보다.
클릭으로 드라이버가 만들어진 것 까지는 좋은데, 어플리케이션이랑 인터페이스 시키는게 졸라 복잡했었다는 기억이 난다.
그래서 결론적으로는 내 클릭으로 드라이버가 제대로 만들어 졌는지 확인도 못해봤다. -.-;
그 이후로 드라이버 공부에 더 용맹정진하여 스스로 드라이버를 짜는 오늘에 이르게 되었으니, 완전히 헛짓은 아니었구나 위안 삼는다.
뭐 정품 사서, 기술지원 받으면서 해보면 안 될 것도 없겠지만, 가격도 만만치 않다.
제일 큰 문제는 드라이버 소스도 감추어져 있어서 드라이버 레벨에서 문제가 생기면 디버깅 할 방법이 없다는 것이다.
( 물론 자동으로 생성되는 드라이버가 잘 검증된 것이기는 하겠지만, 운영체제도 가끔씩 삑사리를 내는 마당에 그 누구를 믿을 수 있으리요.)

두 번째 칩 제조사가 제공하는 드라이버를 이용하는 방법의 장점은 공짜라는 것이다.
우리가 이제까지 써 왔던 ezusb.sys처럼 대부분의 usb칩 vender들이 자기들 칩에 붙는 드라이버를 제공한다.
CYPRESS는 고맙게도 USB 드라이버의 소스코드까지도 제공한다.
(C:\Cypress\USB\Drivers\ezusbdrv에 가보면 구경할 수 있다. 뭐 WDM 드라이버에 대한 지식이 없다면 있으나마나 하지만.)
C:\Cypress\USB\Doc\EZ-USB GeneralEZ-USB General Purpose Driver Spec.pdf 같이 제공하는 드라이버를 쓸 수 있도록 인터페이스에 관한 문서를 제공하므로 이것을 잘 읽어보면 드라이버에 관한 지식 없이도 USB 장치와 인터페이스 하는데 별 문제 없겠다.
단점이라면 위 첫 번째의 경우도 마찬가지 이겠지만, 범용적인 코드이다 보니 오버헤드가 있어서 최적화가 된 드라이버 보다는 느리다는 것이다.

세 번째 누군가 직접 직접 드라이버를 작성하는 방법은 디바이스를 (운영체제가 정한 범위 안에서) 원하는 대로 제어할 수 있다.
그리고 튜닝을 잘하면 극한의 성능까지 끌어올릴 수 있다.
단점은 WDM 드라이버 프로그래밍을 배우려면 오래 걸린다는 것이다.
물론 그럴 땐 본좌 같은 드라이버 프로그래머를 불러다 쓰면 되지만 말이다.
이 방법의 가장 큰 장점은 디바이스 개발자의 부담이 덜어지고, 개발기간이 절약된다는 것이다.( 드라이버 프로그래머를 갖다 쓸 경우에. )
우리들의 보스들은 항상 토막만한 개발기간을 주고는 쪼아대면서, 눈은 이만치 높다.
하드웨어 만들고 펌웨어 짜기도 바쁜데, 어느 시간에 드라이버를 신경 쓰며, 언제 어플리케이션이랑 아웅다웅 하리요?

요럴 때, USB 드라이버 개발자가 중간에 끼어서 정리를 해주면 개발의 방향이 잡히면서 스트레스 지수가 확 떨어진다.

드라이버를 만드는 방법 중 어느 것이 최선이라 말할 수는 없고, 행자들이 처한 상황에 따라 적절한 방법을 선택하는 것만이 최선이다.

본좌는 앞으로 본좌가 작성한 USB WDM드라이버(unihigh.sys)를 가지고 어플리케이션과 펌웨어간의 인터페이스를 설명할 것이다.
(드라이버 작성법을 강의 한다는 말은 아니다. -.-; 언감생심. 드라이버가 본좌가 재미삼아 강의 할 만큼 만만한 분량과 실력이 아니라서…)

Ezusb.sys를 설명하자니 EZ-USB General Purpose Driver Spec.pdf를 번역하는 것 밖에 안 되겠고, 결정적으로 꽁수스러운 그 코드가 본좌 맘에 안 들기 때문이다.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중