1 USBSPEC

1.1 목적

• 요즘 많이들 사용하는 USB는 Release Version 2.0으로 SPEC.만 650 Page가 넘는다.
• 중요하고 핵심적인 것을 추려 USB를 이해한다.
• Scorpio의 UDC를 이용해 USB Device를 구현해 본다.
  

1.2 USB 일반

• USB Speeds
  i Spec 1.1에서는 2개의 mode를 정의하고 있다.

  1. Low Speed : 1.5 Mbps
  2. Full Speed : 12 Mbps

  i Spec 2.0 에서는 High Speed를 추가하였다

  1. High Speed : 480 Mbps
• USB Control : Host controlled
  1. 모든 동작은 Host를 중심으로 일어난다.
  2. 버스당 하나의 Host (Host/Bus)이다. --> 최근 On-The-Go Specification 에서는 Host간의 통신 프로토콜을 정의 중이다.
• USB Topology : 단층의 Star Topology
  1. USB 초기 창안자는 PC뒤에 있는 케이블의 수를 줄이고자 했다.
  2. 하지만 USB는 10?BaseT Ethernet과 유사한 단층의 Star Topology를 사용하고 이것은 (비싼) 허브를 사게끔 하고 케이블을 늘이는 결과를 초래한다. (하지만 그리 나빠보이지는 않는다, 많은 시스템이 USB 허브를 내장하고 있다)
  3. USB 버스에는 127개까지 Device를 연결할 수 있다.
• USB Host Controller Spec : USB Host Controller는 그들 자신의 Spec을 가지고 있다.
  1. USB 1.1
     1. UHCI(Universal Host Controller Interface)
        • Intel
        • 소프트웨어(MS)를 많이 사용해서 h/w를 싸게함
     2. OHCI(Open host Controller Interface)
        • Compaq, MS, National Semiconductor
        • 하드웨어(Intel)를 많이 사용하여 s/w를 쉽게함
  2. USB 2.0
     1. EHCI(Enhanced Host Controller Interface)
• USB : Serial Bus
  1. 4개의 Wire로 구성(2개는 Power(+5v,GND), 나머지 2개는 Twisted Pair Differential Data Signal을 위함)되어 있다.
  2. Sync Field를 동기화 하는데 쓰며, 데이터 인코딩은 NRZI(Non Return to Zero Inver)을 사용한다.
• PNP(Plug and Play)를 지원한다.
  1. 사용자가 포트에 꽂으면 자동으로 감지하여 사용을 알리고(동시에 적절한 Driver를 Load하고), 사용이 끝나면 IRQ, Port Address등을 염려하지 않고 빼도 자동으로 인식하고 종료한다(Driver를 Unload한다)
  2. 적절한 Driver의 Loading은 PID/VID(Product ID/Vender ID) 조합을 이용한다.
     

1.3 USB Protocols

• Data를 보내는 Format이 정해지지 않은 RS-232와 유사한 Serial Interface와는 달리 USB는 몇개의 Protocol Layer를 가지고 있다.
• USB Transaction(또는 Stage라고 한다)은
  1. Token Packet(다음에 어떤것이 오는지 알 수 있게 정의하고있는)과
  2. Optional Data Packet(Payload를 가지고 있는), 그리고
  3. Status Packet(Transaction의 Acknowledge, Error 처리 등을 제공)으로 구성되어 있다.
• Host가 모든 Transaction을 초기화 한다.(앞서 말한 것 처럼, USB는 Host 중심의 시리얼 버스이다)
• 첫번째 Packet(Token Packet, 줄여서 Token이라고 한다)은 다음의 것이 무엇인지, Data Transaction을 Read/Write 할 곳이 어디인지, Device의 주소가 무엇인지, Endpoint가 어떻게 디자인 되었는지 등을 정의하기 위해 Host에 의해서 만들어진다.
• 다음 Packet은 일반적으로 Payload를 가지고 있는 Data Packet이고 그 다음은 Data나 Token이 성공적으로 받아졌는지 또는 Endpoint가 STALL상태(에러 등이 발생하여 정지해 있는 상태)인지 또는 Data를 Accept할 상태가 아닌지(이전의 데이터를 처리하고 있거나 하여) 등을 보고하기 위해) Status Packet(또는 Handshaking Packet이라 한다)이 따른다.
  

1.4 Common USB Packet Fields

• USB 는 LSBit을 제일 처음 보낸다.
• USB Packet은 다음과 같은 Field들로 구성되어 있다.
  1. Sync
     • 모든 USB Packet은 반드시 Sync Field로 시작한다.
     • Low, Full Speed에서는 8 bits, High Speed에서는 32 bits의 길이이다.
     • Receiver와 Transmitter의 동기를 제공한다.
     • 가장 마지막의 2 bits은 Sync Field가 끝나고 다음에 PID Field가 시작한다는 Marker가 된다.
  2. PID
     • 모든 USB Packet은 Sync Field 다음에 반드시 PID Field가 있다.
     • Packet ID, Packet의 종류를 결정한다.
     • PID값 테이블
       
       
     • 총 8 bits인데 PID는 4 bits이다. 하여 PID를 1's complement 를 취해 4 bits을 추가하는데 이를 자체 Error Checking으로 이용한다.
     • PID [ 0..1 ] 2 bits로 (USB는 LSB방식임을 주의하자) 4개의 그룹으로 나누었으며 이는 각각 Token, Data, Handshake, Special이다.
  3. ADDR (Address)
     • 이 Packet 어떤 Device를 위해 만들어 졌는지 알려준다.(쉽게 목적 Device의 주소가 명시된다)
     • 7 bit이므로 총 127개의 Devices까지 지원된다.
     • ADDR값 0는 일반적인 ADDR값으로 사용하지 않고 아직 특정 ADDR를 받지 못한 Device가 특정 ADDR를 할당 받기(요청하기)위해 사용한다.
  4. ENDP (Endpoint)
     • Endpoint Field는 4 bits의 길이며 따라서 총 16개의 Endpoint가 가능하다.
     • Low Speed Device는 2개의 기본 Endpoint외에 2개의 추가 Endpoint까지만 가능하다.(즉 최대 4 Endpoint를 가질 수 있음)
  5. ?CRCs
     • Cyclic Redundancy Checks
     • PID를 제외한(그것은 자체 Error Checking 방법이 있다) 다른 모든 Field는 ?CRCs를 이용해 Error Checking을 실시한다.
     • Token Packet은 5 bits의, Data Packet은 16 bits의 ?CRCs를 가진다.
       1. Token ?CRCs : G(X) = X^5 + X^2 + 1 --> binary 식은 00101, error free의 나머지 값은 01100
       2. Data ?CRCs : G(X) = X^16 + X^15 + X^2 + 1 --> binary 식은 1000000000000101, error free의 나머지 값은 1000000000001101
  6. EOP
     • End of Packet
     • 1 bit Time의 J 다음에 2 bits Time의 ?SE0(Single Ended Zero)로 Packet의 끝을 나타낸다.
       

1.5 USB Packet Type

• USB는 Token, Data, Handshake, SOF의 크게 4가지 종류의 Packet Type이 있다.

1.5.1 Token Packet

1. 다음에 오는 Transaction이 무엇인지를 가리키는 역활을 한다.
2. 3가지 종류의 Token Packet
   • In : USB Device에게 Host가 정보를 읽기를(달라고) 원한다는 것을 알려준다.
   • Out : USB Device에게 Host가 정보를 쓰기를(준다고) 원한다는 것을 알려준다.
   • Setup : Control Transfer의 시작을 알린다.
3. Format

   Sync

   PID

   ADDR

   ENDP

   ?CRC5

   EOP

1.5.2 Data Packet

1. Payload에 데이터를 운반한다.
2. 최대 1024 bytes의 데이터를 운반할 수 있는 2가지 종류의 Data Packet
   • Data0
   • Data1
   • Low-Speed Device의 최대 Data Payload 크기는 8 bytes
   • Full-Speed Device의 최대 Data Payload 크기는 1023 bytes
   • High-Speed Device의 최대 Data Payload 크기는 1024 bytes
   • Data는 반드시 Bytes의 배수로 전송되어야 한다.
3. High Speed모드에서는 ?DATA2, MDATA의 새로운 Data Packet 타입(PID)을 추가했다.
4. Format

   Sync

   PID

   Data

   ?CRC16

   EOP

1.5.3 Handshake Packet

1. Data 의 Ack나 Error Reporting을 위해 사용된다.
2. 3가지 종류가 있다
   • ACK : Packet이 성공적으로 받아졌다.
   • NACK : Device가 일지적으로 Data를 주거나 받지 못한 상태를 리포트한다. 보낼 Data가 없을 때 이를 알릴 때에도 사용한다.
   • STALL : Host의 관여(도움)가 필요하다는 것을 알았을 때. Endpoint가 Error를 내고 Halt되어 있을 때 이것을 사용한다.
3. Format

   Sync

   PID

   EOP

1.5.4 Start of Frame Packets

1. 새로운 Fream의 시작을 알린다.
2. 11 bits의 Frame-Number가 있다.
3. Host에서 Full Speed에서는 매 1ms(+-500ns) 시간마다, High Speed에서는 125ms(+-0.0625ns)마다 보낸다.
4. Format
   

   Sync

   PID

   Frame Number

   ?CRC5

   EOP

1.6 USB Functions

• USB Functions
  1. USB Device의 기능을 설명하기 위한 용어로 Function을 사용한다.
     
     

1.6.1 Example

1. Host가 Device Descriptor Request를 보낸다.
2. Function Hardware는 Setup Packet을 읽고 Packet이 자기것인지(Address Field)판단한다.
3. 자기 것이라면 Packet의 Payload를 적절한 Endpoint Buffer에(Setup Token의 Endpoint Field에 명시된) 카피한다.
4. Handshake Packet을 Host로 보낸다.
5. 내부 Interrupt를 발생시켜 적절한 Endpoint(Setup Token의 Endpoint Field에 명시된)에게 알려준다.
6. 여기까지가 (일반적으로)Hardware에서 해준다.
7. Software에서 Interrupt를 받고 Endpoint의 Buffer에서 내용을 읽고 내용을 파싱한다.
   

1.7 Endpoints

• 데이터의 수신장치 혹은 전송장치로 표현될 수 있다.
• USB는 Host 중심이기 때문에 Endpoint는 USB Function에서 통신의 끝에 위치한다.
• 예를 들면 Software Layer에서 Device Driver는 Packet을 Device EP1으로 보낼 수 있다.
• Host로부터 나온 Data는 ?EP1 OUT Buffer에 위치하게 되고 그 다음 Firmware에서 읽게 된다.
• 만약 Date를 Host쪽으로 돌려주기를 원한다면 Host에서 Control 하듯 쉽게 Bus에 쓸수없다.
• Data를 ?EP1 IN 버퍼에 쓰고 Host가 IN Packet을 보내어 Data를 요구할 때 까지 기다린다.
• Endpoint는 Function Device의 Hardware와 Function Device에서 돌아가고 있는 Firmware 사이의 Interface로 보이기도 한다.
  

1.8 Pipes

• Device가 몇개의 Endpoints로 Data를 주고 받는 동안에 Client Software는 Data를 Pipes를 이용해서 전달한다.
• Pipe(s)는 Host와 Endpoint(s)사이의 논리적인 연결이다.
• Pipe(s)는 그들과 관련된 Parameters Set을 가지고 있다.
  1. Bandwidth
  2. Transfer Type(Control, Bulk, Isochronous, Interrupt)
  3. Direction of Data Flow
  4. Maximum Packet/Buffer Size
• 2가지 종류의 Pipes
  1. Stream Pipes : USB Format으로 정해지지 않음. 어떤 종류의 Stream도 Pipe를 통해 주고 받을 수 있다.
  2. Message Pipes : 정해진 USB Format이 있음. 모두 Host에서 보낸 Request에 의해 초기화 되는 Host Controlled임. 초기화 된 후에 Data는 Request에서 요청된 방향으로 전송된다. 즉 Message Pipes는 Data를 양방향 모두 보낼 수 있지만 Control Transfer만 지원한다.
     

1.9 Endpoint(Transfer) Types

• USB는 Control, Interrupt, Isochronous, Bulk 이렇게 4가지의 Transfer/Endpoint Types을 정의한다.

1.9.1 Control Transfers

1. 일반적으로 Command와 Status Operation을 위해 사용된다.
2. USB Device를 초기화하고, 모든 Enumeration Functions들이 이 Control Transfer을 사용한다.
3. 일반적으로 Host에서 초기화되고 최고의 노력으로 전달되어 사용되지는 Bursty하고 Radom 한 Packet이다.
4. Low Speed에서는 8 Bytes, High Speed에서는 8, 16, 32, 64 Bytes, Full Speed에서는 64 Bytes의 길이이다.
5. 3개의 Stages로 구분될 수 있다.
   • Setup Stage
     1. Request가 보내지는 곳이다.
     2. Setup Token, Data Packet, Handshake Packet 이렇게 3개의 Packet으로 구성된다.
     3. Setup Token : Address와 Endpoint Number를 가지고 있으며 제일 처음 보내진다.
     4. Data Packet : Setup Token 다음으로 보내지며 Data0 의 PID Type을 가지고 있고 Request의 Type을 자세하게 설명하는 Setup Packet을 가지고 있다.
     5. Handshake Packet : 성공적으로 받았다는 Acknowledge를 보내거나 Error를 가리키기 위함. Function이 성공적으로 Setup Data를 받았다면(CRC ok, PID self-Check Ok등) ACK를 보낸다. 그렇지 않으면 Data를 무시하고 Handshake Packet을 보내지 않는다.
     6. Setup Stage에서는 STALL 이나 NAK은 Issue되지 않는다.
     7. Setup Stage
        
   • Data Stage
     1. 선택적이다.
     2. 하나 이상의 IN 또는 OUT Transfer로 구성된다.
     3. 앞의 Setup Stage에서 이 Stage에서 전동될 Data의 양을 결정한다.
     4. 만약 결정된 양이 Maximum Packet Size보다 크다면 Data는 여러개의 Transfer로 나뉘어 전달된다. (마지막 Packet을 제외하고는 모두 Maximum Packet Size로)
     5. Data Transfer의 방향에 따라 2개의 시나라오가 가능하다.
     6. IN
        • Host가 Control Data를 받을 준비가 되었다면 IN Token을 보낸다.
        • Function이 IN Token을 받았으나 그것이 Error라면(PID가 일치하지 않는다 등의) 해당 Packet을 무시한다.
        • Error가 아니라면 Device는 보내질 Control Data를 포함하는 DATA Packet을 응답하거나, Endpoint에서 Error가 발생했다는 Stall Packet을 보내거나, Endpoint가 일은 할 수 있는 상태이나 보낼 Data가 없다는 NAK Packet으로 응답할 수 있다.
     7. OUT
        • Host가 Control Data를 보내고 싶다면 OUT Token을 보내고 그 뒤를 Control Data를 Payload에 담고있는 Data packet을 보낸다.
        • OUT token이나 Data packet의 어느 한부분이라도 망가졌다면 Function은 Packet을 무시한다.
        • Function의 Endpoint Buffer가 비어 있고 Buffer에 잘 들어 왔다면 Host에게 ACK를 보내 잘 받았음을 알린다.
        • Buffer가 비어있지 않다면(앞의 Packet 처리 등으로) Function은 NAK를 리턴한다.
        • Endpoint가 Rrror상태라서 Halt상태라면 STALL을 리턴한다.
        • Data Stage
     
     
   • Status Stage
     1. Request 전반에 걸친 Status를 Report 하고, 전송의 방향에 따라 방향을 한번 바꾼다.
     2. 항상 Function에 의해 처리된다.
     3. IN
        • 만약 Host가 Data를 받기 위해 IN Token을 보냈다면, Host는 반드시 Data를 성공적으로 받았다는 Acknowledge를 보내야 한다.
        • 이것은 Host가 OUT token 을 Zero Length Data Packet와 함께 보냄으로 성사된다.
        • ACK는 Function이 Command처리를 끝내고 다른 Command를 처리할 준비가 되었다는 것을 가리킨다.
        • 만약 현 Command를 처리할 때 Error가 발생했다면 Function은 (Host에게) STALL를 제기한다.
        • 하지만 Function이 (어떤 Command를) 진행중이라면 Status Stage를 다시한번 하기를 바라는 NAK를 Host에게 보낸다.
     4. OUT
        • 만약 Host가 Data Stage동안 데이터를 보내기 위해 OUT Token을 보냈다면, Function은 IN Token에 Zero Length의 Packet을 응답합으로 Acknowledge를 해야한다.
        • Error가 일어났다면 STALL을, (다른)Data를 진행하기 위해 바쁜상태이면 NAK를 보내 후에 Host가 다시 시도하게 요청한다.
     5. Status IN Stage / Status OUT Stage
        
        
        
6. Host 가 Enumeration동안 Device Descriptor를 요청하는 예제
   1. Host 는 Setup Token을 보낸다. (이것은 곧 Function에게 다음에 따라오는 것이 Setup Packet이라는 것을 말한다.)
   2. 주소 Field는 Device의 (호스트가 Descriptor를 요청하고 있는 곳의)주소를 가지고 있을것이다.
   3. Endpoint Number는 Default Pipe를 가르키는 0일 것이다.
   4. Host 는 다음으로 ?DATA0 Packet을 보낸다.
   5. 이 ?DATA0 Packet은 8 Bytes 의 'Device Descriptor Request(USB Spec. 9장에 있음)'를 Payload에 가지고 있을 것이다.
   6. Function은 Setup Packet을 잘 받았다면 거기에 대한 Acknowledge를 보낸다. 만약 Error가 있다면 Packet을 버린다. (--> Host는 Ack를 받지 못했으므로 Short Delay뒤에 Packet을 다시 보낸다)
   7. First USB Transaction

      1.Setup Token	Sync	PID	ADDR	ENDP	?CRC5	EOP	Address & Endpoint Number
      2.Data0 Packet	Sync	PID	Data0		?CRC16	EOP	Device Descriptor Request
      3.Ack Handshake	Sync	PID	EOP				Device Ack. Setup Packet

   8. USB Device 는 이제 8 Bytes의 Data를 디코딩하고 Device Descriptor Request라는 것을 알아챈다.
   9. 그렇다면 이제 Second USB Transaction이 될 ?Device Descriptor 를 보내는 작업을 시작한다.

      1.In Token	Sync	PID	ADDR	ENDP	?CRC5	EOP	Address & Endpoint Number
      2. Data1 Packet	Sync	PID	Data1		?CRC16	EOP	First 8 Bytes of Device Descriptor
      3. Ack Handshake	Sync	PID	EOP				Host Acknowledges Packet
      1. In Token	Sync	PID	ADDR	ENDP	?CRC5	EOP	Address & Endpoint Number
      2. Data0 Packet	Sync	PID	Data0		?CRC16	EOP	Last 4 bytes | Padding
      3. Ack Handshake	Sync	PID	EOP				Host Acknowledge Packet

   10. 여기에서는 Maximum Payload Size를 8 Bytes로 가정했다.
   11. Host 는 Device가 이제 이 Endpoint로 Data를 보낼 수 있다는 IN token을 보낸다.
   12. Maximum Packet Size 가 8 Bytes므로 12 Bytes의 Device Descriptor를 나누어서 보내야 한다.
   13. 나누워서 보낼때에는 마지막 Packet을 제외하고는 모두 Maximum Packet Size를 꽉꽉 채워서 보내야 한다.
   14. Device Descriptor가 보내졌다면 다음으로 Status Transaction이 따라온다.
   15. Transaction이 성공적으로 끝나면 Host는 전체 Transaction이 성공적으로 끝났음을 가르키는 Zero Length Packet를 보낸다.
   16. 그러면 Function 은 자신의 Status를 가르키는 응답을 한다.

       1. Out Token	Sync	PID	ADDR	ENDP	?CRC5	EOP	Addresss & Endpoint Number
       2. Data1 Packet	Sync	PID	Data1		?CRC16	EOP	Zero Length Packet
       3. Ack Handshake	Sync	PID	EOP				Device Ack. Entire Transaction

1.9.2 Interrupt Transfers

1. 일반적인 Microcontroller의 Interrupt Request를 처리해 본 사람은 Interrupt는 Device 가 생성하는 것으로 알고있을 것이다. 하지만 USB에서는 Device가 Host의 주위를 끌기 위해서는 (Interrupt를 일으켜서), Host가 그것을 Poll할때 까지 기다려야 한다. (그것이 긴급한상황이 아니라면)
2. Interrupt Transfer는 아래 내용을 지원한다.
   1. Guaranteed Latency
   2. Stream Pipe - Unidirectional
   3. Error Detection and Next Period Retry
3. Interrupt Transfer는 일반적으로 주기적이지 않으며 작은 디바이스에서 "초기화된" 약간의 잠복기가 필요한(Host가 Poll할때까지) 통신이다.
4. Interrupt Request는 Device에 의해 Queued된다. (Host가 USB Device에게 Data를 요청할때까지 - Poll할때까지)
5. Low-Speed에서의 maximum data size 는 8 bytes.
6. Full-Speed에서의 maximum data size 는 64 bytes.
7. High-Speed에서의 maximum data size 는 1024 bytes.
8. Interrupt Transfer
   
   
9. IN
   1. Host는 주기적으로 Interrupt Endpoint를 Polling한다.
   2. Polling Rate 는 ?Endpoint Descriptor에 규정되어 있다.
   3. 각각의 Poll은 Host가 보내는 IN Token에 연관된다.
   4. IN Token에서 Error가 발생하면 Function은 해당 Packet을 무시하고 Bus를 Monitoring하는 것을 계속한다. (새로운 다음 Token을 위해서)
   5. 만약 Interrupt가 Device에 의해 Queue에 저장되었다면, Function은 IN Token이 왔을 때 Interrupt와 적절한 Data를 넣어서 Data packet을 보낸다.
   6. Host쪽에서는 Data Packet을 성공적으로 받았을 때 ACK을 되돌려 준다. 하지만 Error가 일어났을 때에는 아무런 응답을 하지 않는다.
   7. IN Token이 왔을 때 Queue에 저장된 Interrupt가 없다면 NAK를 보내준다.
   8. Endpoint가 Error인 상태에 있으면 STALL을 보내준다.
10. OUT
    1. 만약 호스트가 Interrupt data를 보내고 싶으면, 먼저 OUT token을 보내고 바로 이어 해당 Interrupt정보가 들어있는 Data Packet을 보낸다.
    2. 받은 Token이나 Data Packet에 조금이라도 이상이 있으면 Function은 이 Request를 무시한다.
    3. 모두 이상이 없다고, Function의 Endpoint Buffer가 비어있고, Buffer에 무사히 넣었다면 Host쪽에 잘받았다는 신호로 ACK를 보낸다.
    4. Endpoint Buffer가 비어있지 않다면(이전의 데이터 처리를 위해) Function은 NAK를 보낸다.
    5. Endpoint가 Error를 내어 Halt bit이 셋팅되어 있다면 STALL를 보낸다.

1.9.3 Isochronous Transfers

1. Isochronous Transfer는 주기적이고 일정하게 일어난다.
2. 일반적으로 시간에 민감한 정보 (Audio, Video Stream같은)를 포함하고 있다.
3. 만약 Audio나 Video에 Delay나 Retry of Data 등이 있다면 끔찍한 소리나 영상을 예상할 수 있을 것이다.
4. 하지만 Packet 또는 Frame이 지금 부터 계속 drop된다면 문제가 될것이다.
5. Isochronous Transfer는 다음 사항을 지원한다.
   1. Stream Pipe - Unidirectional
   2. CRC로 에러 검출을 하지만 데이터의 무결성을 제공하지 않으며 재전송도 하지 않는다.
   3. Full & High Speed 에서만 지원한다.
   4. Guarnateed Access to USB bandwidth
   5. Bounded Latency
   6. No Data Toggling
6. Isochronous Endpoint의 ?Endpoint Descriptor에 Data Payload의 Maximum Size 가 정의되어 있다.
7. 최대치는 Full speed에서는 1023 bytes, High speed에서는 1024 bytes이다.
8. Maximum Data Payload 값이 Bus의 요구 Bandwidth에 영향을 줄 것이므로, 적절한 Size를 찾는 것이 현명할 것이다.
9. 커다란 Payload를 사용한다면 Alternative Interface 시리즈와 함께 Isochronous Payload Size를 바꾸는 것 등을 정의한다면 하나의 장점이 될수도 있다.
10. Enumeration동안에 Host가 Bandwidth 제한 때문에 Isochronous Endpoint를 활성화 하지 못했다면, 그냥 실패로 끝나는 것 보다는 Size를 줄이는 방안을 검토하는것이 좋다.
11. Isochronous Endpoint로 보내지는 Data는 미리 Negotiated된 Size보다 작아질 수 있으며 Transaction에서 Transaction으로 바뀌면서 변할 수 있다.
12. Isochronous Transfer
    
13. Isochronous Transfer는 Error이나 STALL/HALT 등의 Report는 쓰지 않는다.

1.9.4 Bulk Transfer

1. 큰 용양의 Bursty Data를 위해 사용될 수 있다.(Print-Job to Printer, Image Data from Scanner)
2. Data Payload의 ?CRC16 Field로 Error를 검출하고/재전송하여 데이터를 전송함에 있어 Error Free를 구현한다.
3. 모든 Transaction이 할당된 후 남은 Bandwidth를 사용한다.
4. 만약 Bus가 Isochronous 나(그리고) Interrupt 등으로 바쁘다면 Bulk Data 는 매우 느린 속도로 전달될 것이다.
5. 따라서 Time에 민감하지 않는 곳에 사용될 수 있다.
6. 다음은 Bulk Transfer가 제공하는 것이다.
   1. 큰 용량의 데이터를 전송할 때 사용할 수 있다.
   2. CRC를 통해 에러를 검출하며 에러시 재전송을 하여 데이터의 무결성을 보장한다.
   3. 최소 잠복기(전송을 위해 기다리는 시간)이나 Bandwidth는 Guarantee하지 못한다.
   4. Stream Pipe - Unidirectional
   5. Full & High Speed Modes에서만 사용 가능하다.
7. Full Speed Endpoint에서는 Bulk Packet 사이즈는 8, 16, 32, 64 Bytes이고 High Speed에서는 512 bytes까지 가능하다.
8. Bulk Transfer
   
9. IN
   1. Host가 Bulk Data를 받을 준비가 되었다면 IN Token을 보낸다.
   2. IN Token에 Error가 있다면 Function은 해당 Pakcet을 무시한다.
   3. IN Token을 Error없이 잘 받았다면
      • Bulk Data를 포함하고 있는 Data Packet을
      • Endpoint 가 Error가 있다면 Stall Packet을
      • Endpoint 가 준비가 되었지만 아직 보낼 데이터가 없다면 NAK를 보낸다.
10. OUT
    1. Host가 Bulk Data를 보내고 싶다면 OUT Token과 바로이어 Bulk Data를 포함하는 Data Packet을 보낸다.
    2. OUT Token과 Data Packet의 어느 부분이라도 Error가 있다면 Function은 해당 Packet을 무시한다.
    3. 모두 Error가 없고 Function's Endpoint Buffer가 비어있고 Buffer로 잘 넣었다면 Function은 잘 받았다는 ACK를 보낸다.
    4. 모두 Error가 없으나 Function's Endpont Buffer가 비어있지 않다면 NAK를 보낸다.
    5. 모두 Error가 없으나 Endpoint가 Error상태라 Halt bit이 설정되어 있다면 STALL를 보낸다.

1.9.5 Bandwidth Management

1. Host는 Bus의 Bandwidth를 책임져야 한다.
2. 이것은 Enumeration 때 Isochronous, Interrupt Endpoint및 Bus의 동작을 전부 설정하면서 행해진다.
3. Full Speed bus에서는 90%까지 Periodic Transfer(Interrupt, Isochoronous), High speed에서는 80%까지 할당하도록 하고있다. (나머지는 Control과 Bulk가 쓰도록)
   

1.10 USB Descriptors

• 모든 USB Device는 Device가 무엇이고, 누가 만들었고 어떤 버전의 USB를 지원하는지 등의 정보를 Host에게 설명해주는 Descriptor의 계층구조를 가지고 있다.
• 공통적인 USB Descriptors는 다음과 같은 것들이 있다.
  1. Descriptor Hierarchy
     

1.10.1 Device Descritors

1. Device Descriptor는 Device의 모든것을 표현하고 있다.
2. 따라서 USB Device는 단지 하나의 Device Descriptor를 가지고 있다.
3. Device Descriptor는 (지원하는)USB Revision, 적절한 드라이버를 Load하는 데 쓰이는 Product ID와 Vender ID, Device가 가질 수 있는 가능한 Configuation수 등을 가지고 있다.
4. Configuraion의 숫자는 얼마나 많은 Configuration Descriptor로 Branche할 수 있는지를 나타낸다.
5. Device Descriptor Format
   
   • bcdUSB : device가 지원하는 가장 높은 USB version. Binary Coded Decimal with a Format of 0xJJMN (JJ:?Major, M:Minor, N:Sub Minor)
     ==> USB 2.0 == 0x0200, USB 1.1 == 0x0110, USB 1.0 == 0x0100
   • bDeviceClass, bDeviceSubClass, bDeviceProtocol 는 OS에서 Device의 Class Driver를 찾기 위해 사용한다.
   • bMaxPacketSize : Endpoint 0의 Maximum Packet Size, (모든 Device는 Endpoint0를 반드시 지원해야 한다)
   • idVendor, idProduct : OS가 Device의 Driver를 찾기 위해 사용한다. Vender ID는 USB-IF에 의해 할당된다.
   • bcdDevice : bcdUSB와 같은 Format을 가지고 있고 Device Version Number를 나타낸다. 이 값은 개발자에 의해 할당된다.
   • iManufacturer, iProduct, iSerialNumber : 각각을 설명하는 String Descriptor의 Index 값. String Descriptor를 선택적인 Descriptor이므로 지원하지 않을 경우닌 Index에 0을 넣으면 된다.
   • bNumConfiguration : Device가 그것의 현재 Speed를 지원하는 Configuration의 수를 나타낸다.

1.10.2 Configuration Descriptors

1. 몇개의 다른 Configurations을 가질 수 있다. (대부분의 Device가 간단하고 하나만 사용할지라도)
2. 이 특정한 Configuration이 Power를 얼마나 필요로 하는지, Device가 Self-Powered인지 Bus Powered인지, 가지고 있는 Interface 숫자 등의 정보를 가지고 있다.
3. Device가 Enumerate될 때 Host는 Device Descriptor를 읽고 어떤 Configuration이 활성화 될 것인지를 결정한다.
4. 한번에 한가지 Configuration만 가능하다.
5. Inteface Descriptor의 "Header"가 될 수 있으며 그렇게 사용될 때에는 다른 Configuration의 다른 Transfer Mode를 사용하는 하나의 Configuration을 가질 수 있다.
6. Configuration Descriptor Format
   
   • wTotalLength : Hierarchy의 총 Bytes수 (Configuration Descriptor가 읽히면 그것은 관련된 Interface, Endpoint Descriptor들을 포함한 Configuration Hierarchy의 전부를 리턴한다.
   • wTotalLength
     
   • bNumInterface : 이 Configuration에 존재하는 Interface의 수
   • bConfigurationValue : 이 Configuratino을 선택하도록 ?SetConfiguration Request에서 사용하는 값 (이 Configuratino의 ID)
   • iConfiguration : 이 Configuration을 사람이 읽기 쉽게 설명한 String Descriptor의 Index값
   • bmAttributes : Configuration의 Power Parameter들.
     1. Device가 Self Powered면 D6==1
     2. Device가 Bus Powerd D7 bit을 설정 (in USB 1.0) --> 지금은 bMaxPower가 쓰인다.
     3. Device의 Power모드에 상관없이 Device의 Power Consumption을 bMaxPower으로 보고해야한다. 또한 Host가 Suspend일때 깨어날 수 있도록 Remote Wakeup을 지원해야한다.
   • bMaxPower : Bus로부터 사용하는 Maximum Power

1.10.3 Interface Descriptors

1. Device의 한가지 Feature를 나타내는 기능적 그룹화 과정 또는 Header로 보일 수 있다.
2. 예를 든다면 Fax/Scanner/Printer가되는 Multi-Function Device를 가지고 있다면 Fax, Scanner, Printer각 기능별로 Interface Descriptor가 될 수 있다.
3. Configuration Descriptor와는 달리 한번에 하나의 Interface Descriptor만 활성화 해야한다는 등의 제한은 없다.
4. Interface의 수를 나타내는 bInterfaceNumber Field, Interface에 Setting을 변화시킬 수 있는 bAlternateSetting Field가 있다.
   • 예를 들어 두개의 Interface를 가지고 있는 Device를 가지고 있는데, 각각 Interface one, Interface two라 하자.
   • Interface one은 bInterfaceNumber==0(이 Interface가 첫번째 Interface임을 가르킴), bAlternativeSetting==0, Interface two는 bInterfaceNumber==1(이 Interface가 두번째 Interface임을 가르킴), bAlternateSetting==0(Default).
   • 다른 Descriptor 를 적용시키는데 여기서는 bInterfaceNumber==1(두번째 Interface를 가르킴), bAlternativeSetting==1(이 Interface Descriptor는 원래의 두번째Interface Descriptor의 Alternative Setting일 수 있음을 가르킴)
   • 이 Configuration이 활성화 되었다면 처음의 두개의 Interface Descriptor(bAlternativeSetting==0인)가 사용된다.
   • 하지만 동작 과정에서 Host가 ?SetInterface Request를 Interface one에게 bAlternativeSettings==1인 다른 Interface Descriptor를 활성화 하기 위해 보낼 수 있다.
   • 이것은 두개의 (추가)Configuration을 가지고 있음으로 Interface zero에 전혀 영향을 주지 않고 Interface one에 관련된 Endpoint에 영향을 줄 수 있는 장점을 제공해 준다.
   • Interface Descriptor Example
     
5. Interface Descriptor Format
   
   • bInterfaceNumber : Interface Descriptor의 Index (Zero based, 새로운 Interface Descriptor 에 대하여 +1)
   • bAlternativeSetting : Alternative Interfaces를 나타냄 (?SetIntetface Request에서 Alternative Interface는 선택되어질 수 있다)
   • bNumEndpoints : 현 Interface 에서 사용하는 Endpoint의 수(반드시 Endpoint0의 수 를 포함하고 있어야한다)
   • bInterfaceClass, bInterfaceSubClass, bInterfaceProtocol : 특별히 지원하는 Class 를 나타낼 때 쓰인다(HID, Mass Storage, Communications등). 이것은 많은 Devices들이 특정 Device를 위한 Driver를 쓰는것을(구현하는것)을 Class를 사용하게 함으로 대신할 수 있게 한다.
   • iInterface : 이 Interface에 대한 String Descriptor의 index

1.10.4 Endpoint Descriptors

1. Endpoint (0을 제외한)를 설명하는데 쓰인다.
2. Endpoint 0는 항상 Control Endpoint로 사용되며 어떤 Descriptor의 Request이전에 이미 설정된다.
3. Host는 이들 Descriptor로부터 받은 정보를 Bus의 Bandwidth를 정하는 데 사용한다.
4. Endpoint Descriptor Format
   
   • bEndpointAddress : 이 Descriptor가 설명하고 있는 Endpoint를 가르킨다. (ep ID)
   • bmAttributes : Transfer Type을 나타낸다. Control, Interrupt, Isochronous, Bulk가될 수 있다. 만약 Isochronous 로 정해졌다면 Synchronisation, Usage Type같은 추가의 attribute가 선택될 수 있다.
   • wMaxpacketSize : 현 Endpoint의 Maximim Payload Size를 나타낸다.
   • bInterval : 실제 전송의 Polling Interval을 나타낸다. Unit은 Frames.

1.10.5 String Descriptors

1. 선택적이다.
2. 인간이 읽을 수 있는 정보를 제공
3. String은 Unicode Format으로 인코드되고 Mutiple Language를 지원하도록 할 수 있다. String Index 0 는 가능한 Language의 List를 Return한다. (다른 Descriptor에서 String Index를 0으로 하면 사용하지 않음을 의미한다)
4. String Descriptor Zero Format
   
5. 위의 String Descriptor는 String Descriptor Zero의 Format을 보여준다. Host는 이것을 읽음으로서 어떤 Languages가 가용한지 알 수 있다. 만약 Language가 가용하다면 Get Descriptor(String) Request의 wIndex Field에 Language ID를 보내어 해당 언어의 스트링을 참조할 수 있다.
6. 실제 스트링 데이터는 다음과 같은 Format으로 담을 수 있다.
7. String Descriptor Format 2
   
   

1.10.6 Composition of USB Descriptors

• 모든 Descriptors는 공통 format을 기반으로 만들어져 있다.
• 첫번째 Byte는 Descriptor의 길이를 규정하고
• 두번째 Byte는 Descriptor의 Type을 말한다.
• 만약 Descriptor의 길이가 스펙에서 정의한 것 보다 작다면 Host는 그것을 무시한다.
• 만약 Descriptor의 길이가 스펙에서 정의한 것 보다 크다면 Host는 여분의 Byte를 무시하고 실제 사이지의 끝부분에서부터 다음 Descriptor를 찾기 시작한다.
• Descriptor Common Format
  
  
  

1.11 USB Requests

1.11.1 The Setup Packet

1. 모든 USB Device는 Default Pipe로 Setup Packet에 응답을 해야한다.
2. Setup Packet은 Device를 검출하고 설정하는데 사용되며 USB Device의 Address를 설정하거나, Device Descriptor를 요청하거나, Endpoint의 상태를 Checking하는 등의 공통 Function을 운반한다.
3. USB 호환 Host는 모든 Request는 최대 5초 이내에 처리 될 것을 기대한다. 또한 각각의 Request에 대해 엄격한 Timing을 정의하고 있다.
   1. Standard Device Request without Data Stage 는 모두 50 ms 이내에 처리되어야 한다.
   2. Standard Device Request with Data Stage는 Request후 500 ms이내에 Data를 받기 시작해야 한다.
      • 각각의 Data Packet은 500 ms 이내에 보내져야 한다.(앞 Packet의 성공적인 전송 후에)
      • Status Stage는 가장 마지막 Data Packet의 전송 후에 50 ms 이내에 완료 되어야 한다.
   3. Data Phase를 가지고 있는 ?SetAddress Command 는 50 ms 이내에 Command를 처리하고 Status가 Return되어야 한다. Address를 바꾸기 위해 2ms의 시간을 준다.
4. 위의 Timeout 주기들은 아주 저속의 Device에서도 그대로 받아들여진다. (하지만 Serial로 Debugging을 할때에는 주의를 요한다. )
5. Setup Packet Format
   
   1. 총 8 bytes의 길이
   2. bmRequestType : Request의 방향, 종류, 예상된(Designed) 수신자 를 결정한다.
   3. bRequest : 만들어진 Request 자체
      • bmRequestType이 정상적으로 파싱되고, 실행은 여러 핸들러 (Standard Device request handler, Standard Interface handler, Standard Endpoint handler, Class Device Request handler 등으로)로 처리될 수 있다. Setup Packet을 어떻게 Parsing하고 처리할 것인지는 모두 개발자에게 달려있다. 다른 방법 하나는 bRequest를 먼저 parsing하고 다음에 request에 맞는 type과 수신자 등을 파악할수도 있다.
      • Standard Request는 모든 USB Device에게 공통이된다.
      • Class Request 는 Driver의 Class에 공통이된다. 예를 들면 HID Class를 따르는 모든 Device는 특정 Class Request Set에 대한 공통을 가지고 있을 것이다. 이것은 Communication Class를 따르는 Device와 다르며 Mass Stogage Class를 따르는 Device와도 다르다.
      • Vendor Specific Request는 Device마다 다르며 개발자의 구현과 Imagination에 달려있다.
      • Common Request는 다른 종류의 수신자에게 전달될 수 있으며 각각의 수신자에 따라 다른 Function을 수행할 수 있다. ?GetStatus Reqeust를 예로 들면, 이 Request는 Device, Interface나 Endpoint에 전달될 수 있을것이다. Device에게 전달 되었을 때 만약 Device가 Self Powered라면 Remote Wakeup Status를 가르키는 플래그를 리턴할 수 있다. 항상 0를 리턴하는 Interface에게 전달되었을 때에는 0을 Return할 것이고, Error를 일으려 Halt된 Endpoint에게 전달되었다면 Halt Flag가 셋팅되어 Return될 것이다.
   4. wValue : wIndex : Request에 Parameter를 같이 전달할 때 사용한다.
   5. wLength : Data Phase가 있을 때 전송될 Bytes수를 나타낸다.
      

1.11.2 Standard Request

1. Standard Device Request
   
2. Get Status Request가 Device에 도착했을때 Devcie는 다음의 Format으로 Data Stage동안 2 Bytes를 리턴할 수 있다.
   
   1. D0==1 : Self Powered
   2. D0==0 : Bus Powered
   3. D1==1 : Remote Wakeup Enabled -> Wake the host up during suspend. Remote Wakeup Bit은 ?SetFeature 와 ?ClearFeature Request에서 DEVICE_REMOTE_WAKEUP(0x01)과 함께 사용될 수 있다.
3. Clear Feature, Set Feature Request는 Boolean Feature를 셋팅할때 사용한다.
   1. 만약 대상 수신자가 Device라면, DEVICE_REMOTE_WAKEUP가 TEST_MODE의 2가지 Feature만 사용할 수 있다.
   2. Test Mode 는 Device가 여러가지 Condition에 있게 허용한다.
4. Set Address 는 USB Device에게 고유한 주소를 할당하기 위해 Enumuration시에 사용되어 진다.
   1. Address는 wValue에 써지며 최대 127까지 가능하다.
   2. 이 Request는 Device가 그것의 주소를 Status Stage가 끝나지 전까지 셋팅하지 않는다는 점에서 유일하다. (다른 모든 Request는 Status Sstage이전에 모두 끝나야 한다.)
   3. Set Descriptor/Get Descriptor는 특정한 Descriptor를 wValue에 리턴한다. Configuration Descriptor Request는 Device Descriptor와 모든 Interface, Endpoint Descriptors를 한번에 리턴한다.
      • Endpoint Descriptors, Interface Descriptors 는 이 Request로 직접 Access 되지 않는다.
      • String Descriptor는 Multiple Language Support를 위해 wIndex에 Language ID를 가지고 있다.
5. Get Configuration/Set Configuration Request 는 현 Device를 설정하기 위해 사용한다.
   1. Get Configuration Request인 경우 Device의 상태를 나타내는 Byte가 Data Stage에 리턴되어야 한다.
      • Zero Value는 Device가 아직 설정되지 않았음을 의미하고, None Zero Value는 설정되었음을 의미한다.
   2. Set Configuration Device를 활성화 하는데 사용한다.
      • 어떤 Configuration을 활성화 할것인지 선택하기 위해서 wValue의 Lower byte에 요청되는 Configuration Descriptor의 bConfiguration Value를 가지고 있을 수 있다.
        

1.11.3 Standard Interface Request

1. Standard Interface Request
   
   1. wIndex : Interface에서 직접 요청하는 Interface의 Index를 나타냄 (0 based)
   2. Get Status : Interface의 Status를 Return
   3. Clear Feature, Set Feature : Boolean Feature셋팅에 쓴다. 현재 스텍에는 Interface Feature를 아직 정의하지 않음
   4. Get Interface, Set Interface : Alternative Interface를 셋팅할 때 사용한다.
      

1.11.4 Standard Endpoint Request

1. Standard Endpoint Request
   
   1. wIndex : 참조되는 Endpoint Index, Endpoint에 Directed되기 위한 Request 방향을 나타낸다.
   2. Endpoint Request의 wIndex Format
      
   3. Get Status : 2 bytes의 Endpoint의 상태(Halted/Stalled)를 리턴한다.
   4. Endpoint Get Status Return Format
      
   5. Clear Feature, Set Feature : Endpoint Feature를 셋팅하는데 사용한다. (Boolean Feature)
      • 현재 스펙에는 ENDPOINT_HALT(0x00) 한가지 Feature만을 정의하고 있다.
   6. Sync Frame : Endpoint 동기 Frame을 Report하기 위해 사용한다.
      

1.12 Appendex A : USB SPEC. (Rev2.0) Summary

• Chapter 1 - Introduction
  1. USB의 도입동기와 범위
  2. 정의된 Class를 이해하면 된다. 다른 내용은 참조 정의된 Class
• Chapter 2 - Terms and Abbreviations
  1. 용어, 약자들
• Chapter 3 - Background
  1. End-User에게 매우 편리한 USB, 마케팅을 위한 Full, High Speed Ranges, Feature List
• Chapter 4 - Architectural Overview
  1. 중요하게 읽어야 할 시작 Chapter
  2. USB system의 기본적은 overview제공, (topoloty, data rates, data flow types, basic electrical specs 등)
• Chapter 5 - USB Data Flow Model
  1. USB에서 Data가 어떻게 흘러가는가를 설명하기 시작하는 Chapter
  2. Endpoints, Pipes, 같은 용어 소개
  3. Control, Interrupt, Isochronous, Bulk 의 Flow Type설명
• Chapter 6 - Mechanical
  1. USB의 두개의 Standard Connector에 대한 설명
  2. Type A Connector는 Downstream을 위해 고안되었고, Type B는 Upstream을 위해 고안되었다는 것이 가장 중요 (따라서 두개의 Upstream 또는 Downstream의 Connector만으로는 케이블을 구성할 수 없다)
  3. USB cable 생산자가 아니면 더이상 볼 내용이 없음
• Chapter 7 - Electircal
  1. Impedance, Rise/Fall times, Driver/Receiver Specifications, Bit Level Encoding, Bit Stuffing 등의 Low Level Electrical Signalling을 설명한다.
  2. 두 Data Line을 측정용 Register를 통해 Device Speed를 알아내는 법
  3. Powered Device와 Self Powered Device
• Chapter 8 - Protocol Layer
  1. USB Packet을 Byte Level로 설명 (Sync, Pid, Address, Endpoint, CRC Fields를 포함하여)
• Chapter 9 - USB Device Frame Work
  1. 가장 중요한 Chapter
  2. Bus Enumeration과 Request Codes(Set Address, Get Descriptor 등)설명
• Chapter 10 - USB Host Hardware and Software
  1. Host관련된 주제를 다룸
  2. Frame, Microframe Generation, Host Conntroller Requirements 등
  3. Host를 디자인할 것이 아니면 Skip
• Chapter 11 - Hub Specification
  1. USB Hubs에대한 내용
  2. Hub Configuration, Split Transactions, Standard Descriptors of Hub Class 등
  3. Hubs를 디자인 할 것이 아니면 Skip
• Appendex A - Transaction Examples
  1. 여러 Transaction의 Control, Bulk등의 Flow Type에 따른 예제 (그림으로 잘 나와 있음)
• Appendex B - Example Declaration for State Machines
• Index
  

1.13 Reference

• http://www.usb.org
• http://www.beyondlogic.org