Charizard/Doc

4장

이벤트와 리퀘스트

 허브는 주기적으로 하향 포트에 연결된 디바이스의 장착과 탈착을 감지. 주기적으로 폴링을 하거나 인핸스드 슈퍼스피드 패킷을 수신하여 디바이스의 장/탈착을 감지한다.

 과정
 1. 호스트는 새 디바이스에 대한 정보를 얻기 위해 디바이스 허브로 리퀘스트
 2. 허브는 디바이스와 호스트 간에 통신 경로를 설정
 3. 호스트는 통신 경로에 제어 전송(표준 USB 리퀘스트 포함)을 보내어 디바이스 열거 시도
 4. 디바이스는 각 리퀘스트에 해당하는 정보로 응답하거나 요청된 기타 동작 수행
* 모든 USB 디바이스는 제어 전송, 표준 리퀘스트, 엔드포인트 0을 지원해야 함

설정 상태 얻기

디바이스의 상태 (USB 2.0 기준)

• 전원 공급됨 (Powered)
• 기본 (Default)
• 주소 (Address)
• 설정됨 (Configured)
• 장착됨 (Attached)
  : 허브가 디바이스의 VBUS 선에 전원을 공급하지 않은 상태. VBUS에 전원이 없으면 호스트와 디바이스가 통신을 할 수 없기 때문에 디바이스가 연결되지 않은 것과 마찬가지.
• 서스펜드 (Suspend)
  : 최소 3ms 동안 SOF 마커를 포함한 버스 활동이 없는 상태

일반적인 USB 2.0 순서

1. 시스템이 새 디바이스를 갖는다.
   : 사용자가 USB 포트에 디바이스를 장착하거나 디바이스를 장착한 상태에서 시스템 전원을 넣음.
    허브가 포트에 전원을 공급하면 디바이스는 Powerd 상태가 됨 (디바이스는 버르소부터 100mA까지 전류를 얻을 수 있음)
2. 허브가 디바이스를 감지한다.
   : 허브는 각 포트의 신호선(D+와 D-) 전압을 감시한다. 허브의 각 신호선은 14.25~24.8kΩ의 풀다운 저항이 있다. 디바이스는 풀스프드 디바이스에서는 D+에, 로우스피드 디바이스에서는 D-에 900~1575 Ω 의 풀업 저항이 있다. 디바이스는 VBUS가 0.8V 이상인 것을 검출한 이후 1초 내에 연결돼야 하는데, 전력이 약하거나 모두 소모된 배터리를 상요하는 디바이스는 제외
3. 호스트가 새 디바이스 정보를 얻는다.
   : 각 허브는 인터럽트 엔드포인트를 이용해 발생한 이벤트가 허브인지 포트인지 보고.
    호스트는 발생한 이벤트에 대해 자세히 알아내기 위해 Get Port Status 리퀘스트를 허브로 전송
    허브는 호스트로부터 반환된 정보를 통해 새 디바이스를 호스트에 장착했음을 감지
4. 허브는 디바이스가 풀스피드인지 로우스피드인지 감지
   : 신호선 전압을 검사해 디바이스가 로우스피드인지 풀스피드인지 판단
5. 허브가 디바이스를 리셋
   : 호스트가 새 디바이스 장착을 알아채면 Set Port Feature 리퀘스트를 허브로 보내 포트 리셋을 요청
6. 호스트는 풀스피드 디바이스가 하이스피드도 지원하는지 확인
7. 허브는 디바이스와 버스 사이의 신호 경로를 설정
8. 호스트는 Get Descriptor 리퀘스트를 보내 기본 파이프의 최대 패킷 크기를 알아낸다.
9. 호스트가 주소를 할당한다.
   : Set Address 리퀘스트
10. 호스트는 디바이스 기능에 관한 정보를 읽어온다.
    : Get Descriptor 리퀘스트
11. 호스트가 디바이스에 추가 정보를 요청
12. 호스트가 디바이스 드라이버를 할당하고 메모리로 가져온다.
    : 윈도우 호스트는 INF 파일을 이용해 최적의 드라이버를 식별. INF 파일은 USB 클래스용 시스템 파일 또는 제조자 제공 파일이다. 이 안에는 디바이스 Vendor ID, Product ID가 들어있다.
13. 호스트 디바이스 드라이버가 컨피규레이션을 선정
    : Set Configuration 리퀘스트 전송. 디바이스가 요청 받은 Configuration을 수신하면 요청받은 컨피규레이션을 활성화. 디바이스는 설정됨 (Configured) 상태로 전환되고 인터페이스 활성화

*OS나 OS 버전에 달라질 수 있음

디바이스 제거

사용자가 버스에서 디바이스를 제거하면 허브는 디바이스를 장착했던 포트를 비활성화한다. 그 후 허브가 호스트에게 이벤트가 발생했음을 알리고, 호스트가 디바이스 제거를 알아챈 후 Get Port Status 리퀘스트를 보내 어떤 이벤트가 발생했는지 확인. 이제 디바이스가 장치 관리자에서 사라진다.

성공적인 열거를 위한 팁

열거를 성공하지 못하면 디바이스와 호스트는 통신 작업을 수행할 수 없다. 칩 제조사는 대부분 예제 코드를 제공한다. 

• 이벤트는 정해진 순서로 발생하지 않을 수 도 있다.
• 제어 전송은 재빠르게 이루어져야 하며 유사시에는 신속하게 포기해야한다.
• 호스트가 요청한 데이터보다 많이 보내면 안된다.
• 필요하면 ZLP(zero-length data packet)를 보낸다.
• 지원하지 않는 리퀘스트는 STALL로 응답
• 주소를 너무 빨리 지정하면 안된다.
• 서스펜드 상태에 대한 준비를 해야한다.
• 다른 호스트 컨트롤러 환경에서도 테스트해야 한다.

2 디스크립터

2-1 디스크립터 유형

2-2 디바이스

2-3 디바이스 한정자

2-4 컨피규레이션

2-5 다른 속도 컨피규레이션

2-6 인터페이스 연관 디스크립터

2-7 인터페이스 디스크립터

2-8 엔드포인트

2-9 슈퍼스피드 엔드포인트 짝

2-10 슈퍼스피드 플러스 등시성 엔드포인트 짝

2-11 문자열

2-12 바이너리 오브젝트 스토어와 디바이스 기능

2-13 OTG 디스크립터

2-14 마이크로소프트 OS 디스크립터

2-15 USB 2.0용 디스크립터로 업데이트

2-16 USB 3.1용 디스크립터로 업데이트

USB는 여러 종류의 장치를 지원한다. 이 다양한 장치를 기능별로 분류하여 class라고 부르고, class 별로 표준 protocol을 정의하여 놓았는데 각 장치는 이 protocol를 준수하여 동작하여야 한다.

USB Software stack은 다음과 같다.

 HID (Human Interface Device) - mouse, keyboard과 같은 저속 시리얼을 위한 Class
 CDC (Communication Device Class) - 시리얼 통신에 주로 이용
 MSC (Mass-Storage Class) - 대용량 저장 장치를 위한 것으로 USB Flash 같은 곳에 사용
 ACM (Abstract Control Model Class) - V-port와 같은 추상화된 구성에 주로 사용

이렇게 준비된 Class Driver를 사용하지 않고 사용자 정의 방식으로 동작이 가능하다.

의료 쪽의 PHCD (Personal Healthcare Device Class) 는 운동용 시계, 혈압 측정기, 체온계, 체중계, 혈당 측정기 등과 같은 의료 기기가 호스트에 접속하여 개인과 피트니스 코치 또는 환자와 의사 사이의 의사소통을 간편하게 하도록 지원한다.

USB는 master/slave라는 표현 대신 Host/Device라는 용어를 사용한다. Host가 Master에 해당되고, Device가 slave이다.
PC가 Host이고 Embedded Device가 Device로 동작할 때, 아래처럼 구성된다.

CDC (Communication Device Class)
 USB to Serial, USB to ethernet 등 USB 포트에 연결하여 통신하는 디바이스들이 CDC를 주로 사용한다. CDC는 통신 방법에 따라 ACM, ECM, EEM, NCM, OBEX 등등 다양한 subclass 들이 있다.

ACM (Abstract Control Model Class)
 USB to Serial 에 주로 사용되는 subclass 이다.

ECM (Ethernet Networking Control Model)
 USB to ethernet의 subclass 이다. ECM이 발표된 이후, ECM의 비효율적인 부분을 개선하여 발표되고 있다. EEM (Ethernet Emulation Model), NCM(Network Control Model), MBIM(Mobile Broadband Interface Model) 등은 모두 ethernet packet을 전송하기 위한 class 이다.

USB Host를 개발하려면 당연하게 USB Host Controller Driver가 있어야 한다. Host Controller는 OHCI, UHCI, EHCI and xHCI Controller가 있고, 이중 EHCI가 USB 2.0 high speed 까지 지원되는 것으로, 가장 널리 사용된다. 하지만, 대부분은 USB Device 개발이고, 이 경우엔 Host에서 돌아가는 class driver를 개발해야 하고 USB Device 에서 돌아가는 제어블럭이 필요하게 된다. 

출처: m.blog.naver.com/PostView.nhn?blogId=msnayana&logNo=220148672836&proxyReferer=https:%2F%2Fwww.google.com%2F

 USB 디바이스는 firmware 레벨에서 descriptor에 정보를 보관한다. 운영체제는 USB 디바이스와의 통신 채널인 control endpoint를 통해서 디바이스에 descriptor 제공을 요청하고, 요청을 받은 디바이스는 descriptor를 제공한다.

 USB Specification 2.0을 지원하려면 디바이스, 인터페이스, 엔드포인터에 대한 정보를 담고 있는 standard descriptor를 지원해야 한다. 디바이스는 제조사 별 class descriptor와 vendor-specific descriptor가 있다.

MS의 descriptor는 standard USB string descriptor (OS string descriptor), OS feature descriptor가 있다. OS string Descriptor는 OS feature descriptor를 얻기 위해 필요한 Descriptor이다.

디바이스의 OS feature descriptor를 얻기 위해서 Windows는
 1. 디바이스의 OS string descriptor를 조회하기 위한 제어 요청을 디바이스에게 보낸다.
 2. 수신한 디바이스 OS string descriptor가 Microsoft가 정의한 포맷을 준수하는지 확인한다.
 3. 디바이스의 OS feature descriptor를 조회하기 위해서 OS string descriptor의 bMS_VendorCode 필드에 있는 데이터를 사용한다.

MS의 OS featrue descriptor 종류로는 Extened Compat ID, Extended Properties, Genre가 있다.
 - Extened Compat ID
 Windows에는 USB 디바이스의 기본 드라이버를 결정하기 위해서 calss 와 subclass 코드를 사용한다. 새로운 타입의 USB 디바이스는 이 class 와 subclass 코드를 가지고 있지 않다. 이런 경우에 USB 디바이스 제조사는 extended compat ID라는 OS featrue descriptor 정보를 디바이스 firmware에 저장한다. Windows는 디바이스가 연결될 때 이 정보를 조회하여 디바이스에 대한 기본 드라이버를 결정하고 load한다.
 - Extended Properties
 USB 디바이스의 class level 또는 devnod level를 선언할 수 있다. USB 디바이스 제조사는 이 Extended Properties OS feature descriptor를 이용해서 도움 페이지, URL, 아이콘 같은 추가 특성 정보를 펌웨어에 저장할 수 있다.
 - Genre
 이 디스크립터는 게임 컨드롤러 같은 HID 디바이스들이 상세한 configuration data를 제공하기 위해 사용한다. 예를 들어서 전형적인 게임 컨트롤러는 컨트롤에 대한 기본 정보를 포함하는 report descriptor를 가지고 있다. 하지만 이 데이터는 게임 컨트롤러가 사용될 수 있는 여러가지 다른 상황에서 컨트롤과 액션 간의 최적의 mapping을 하기에는 부족하다. USB 디바이스 제조사는 디바이스 펌웨어에 상세한 매핑 정보를 저장하게 위해 이 descriptor를 사용할 수 있다.

MS의 OS String Descriptor
USB 디바이스는 스트링 인덱스 0xEE에 저장된 OS String Descriptor를 갖고 있어야 한다.
 - 이 디스크립터를 사용한다는 것은 디바이스가 하나 이상의 OS feature descriptor를 갖고 있음을 의미
 - OS featrue descriptor 조회에 필요한 데이터들을 포함
 - USB 디바이스 제조사가 0xEE에 저장할 수 있는 스트링들로부터 OS String Descriptor를 구분할 수 있게 하는 signature를 포함
 - 버전 정보 포함

MS의 OS Feature Descriptor
버전 1.00 에서 MS는 3개의 OS feature descriptor에 대한 표준 포맷을 정의했다. OS feature descriptor는 다음 사항을 만족해야 한다.
 - 다비이스는 최대 255개까지 descriptor를 저장할 수 있다.
 - descriptor는 디바이스 또는 특정 인터페이스 기능과 연관된 것일 수 있다.
 - 각 타입 당 한개의 OS Feature Descriptor가 허용된다. 여러 OS Feature Descriptor들이 특정 인터페이스나 function에 연관될 수 있다. 이 경우에 디바이스는 자신이 갖고 있는 인터페이스들이나 function들 만큼의 디스크립터들을 가질 수 있다. 
 - descriptor는 크기와 버전정보를 포함해야 한다.
 - descriptor 최대 크기는 특정 OS featrue descriptor에 따라 다르다. 프로토콜은 feature descriptors 크기를 16MB까지 허용하지만, 그 크기는 펌웨어 비용 때문에 제한된다.

출처: blog.naver.com/jskimadd/10171305013