[USB 2.0 스펙] Transfer Management

 

5.11.1 Transfer Management
Transfer management involves several entities that operate on different objects in order to move transactions over the bus:
•     Client Software:  Consumes/generates function-specific data to/from a function endpoint via calls and callbacks requesting IRPs with the USBD interface.
•     USB Driver (USBD):  Converts data in client IRPs to/from device endpoint via calls/callbacks with the appropriate HCD.  A single client IRP may involve one or more transfers.
•     Host Controller Driver (HCD):  Converts IRPs to/from transactions (as required by a Host Controller implementation) and organizes them for manipulation by the Host Controller.  Interactions between the HCD and its hardware is implementation-dependent and is outside the scope of the USB Specification.
•     Host Controller:  Takes transactions and generates bus activity via packets to move function-specific data across the bus for each transaction.
Figure 5-13 shows how the entities are organized as information flows between client software and the USB.  The objects of primary interest to each entity are shown at the interfaces between entities.

 

▶ Transfer management

Transfer management는 각각의 엔티티를 포함합니다. 그 엔티티들은, 버스를 통해, 트랜잭션들을 움직이기 위해서, 다른 객체들 작동합니다.

 

▶ Client Software

Client Software는 USB 인터페이스를 가지고 IRP들을 요청하는, 콜 혹은 콜백을 통해서, 기능 엔드포인트(function endpoint) 으로부터/에게로 function-specific 데이터를 소비/발생합니다.

 

▶ Host Controller Driver (HCD):

Host Controller Driver는 IRPs들을 트랜잭션으로 변환합니다. (Host Controller 구현에 의해 요구되어있습니다) 그리고, Host controller에 의해, 조작을 하기 위해서 그것들을 정렬합니다. HCD와 그것의 하드웨어의 상호작용은 implementation-dependent (구현독립적) 이고, 이 USB 명세서 범위의 밖입니다.

 

▶ Host Controller

트랜잭션들을 가져오고, 패킷들을 통해서, 버스 액티비티를 발생합니다, 각 트랜잭션을 위한 버스를 가로질러서, function-specific 데이터를 이동하기 위해서 말이죠.

 

 

 

 

 

 

5.11.2 Transaction Tracking

A USB function sees data flowing across the bus in packets as described in Chapter 8.  The Host Controller uses some implementation-dependent representation to track what packets to transfer to/from what endpoints at what time or in what order.  Most client software does not want to deal with packetized communication flows because this involves a degree of complexity and interconnect dependency that limits the implementation.  The USB System Software (USBD and HCD) provides support for matching data movement requirements of a client to packets on the bus.  The Host Controller hardware and software uses IRPs to track information about one or more transactions that combine to deliver a transfer of information between the client software and the function.  Figure 5-14 summarizes how transactions are organized into IRPs for the four transfer types.  Detailed protocol information for each transfer type can be found in Chapter 8.  More information about client software views of IRPs can be found in Chapter 10 and in the operating system specific-information for a particular operating system.

 

USB 기능은, 

 

 

- 데이터 흐름 타입 : 모든 전송(Transfers)들은 하나 혹은 여러개의 트랜잭션들로 구성되어 있습니다. IRP는 하나 혹은 여러개의 전송(Transfers)들에 대해 대응합니다.

- 제어 전송 : 제어 전송은 하나의 "데이터 방향에 반대되는" Status 트랜잭션에 의해 따르는, 다중의 IN or OUT 데이터 트랜잭션에 의해 따르는, OUT setup 트랜잭션 입니다.

- 인터럽트 전송 : 인터럽트 전송은 하나 혹은 여러개의 IN / OUT 데이터 트랜잭션들 입니다.

= 등시성 전송 : 등시성 전송은 하나 혹은 여러개의 IN / OUT 데이터 트랜잭션들 입니다.

- 벌크 전송 : 벌크 전송은 하나 혹은 여러개의 IN /OUT 데이터 트랜잭션들 입니다.

 

Even though IRPs track the bus transactions that need to occur to move a specific data flow over the USB, Host Controllers are free to choose how the particular bus transactions are moved over the bus subject to the USB-defined constraints (e.g., exactly one transaction per (micro)frame for isochronous transfers).  In any case, an endpoint will see transactions in the order they appear within an IRP unless errors occur.  For example, Figure 5-15 shows two IRPs, one each for two pipes where each IRP contains three transactions. For any transfer type, a Host Controller is free to move the first transaction of the first IRP followed by the first transaction of the second IRP somewhere in (micro)Frame 1, while moving the second transaction of each IRP in opposite order somewhere in (micro)Frame 2.  If these are isochronous transfer types, that is the only degree of freedom a Host Controller has.  If these are control or bulk transfers, a Host Controller could further move more or less transactions from either IRP within either (micro)frame.  Functions cannot depend on seeing transactions within an IRP back-to-back within a (micro)frame nor should they depend on not seeing transactions back-to-back within a (micro)frame.

 

 

 

 IRPs가 USB 상에서, 특정 데이터 흐름을 이동하기 위해 발생해야하는, 버스 트랜잭션을 추적 하더라도,

Host Controller들은 USB 정의된 제약에서 버스 주체 상에서, 특정한 버스 트랜잭션들을 옮겨지는 방식을 선택하는거에 자유롭습니다. (예를 들어, 등시성 전송을 위해, (micro) 프레임을 하나 당, 정확히 하나의 트랜잭션)

 어느 케이스 안에서든, 앤드포인트는 각각의 IRP 내에서, 그들이 나타내었던 순서로 트랜잭션들을 볼 것 입니다, 에러가 발생하지 않았다면 말이죠.

 예를 들어, 아래의 Figure 5-15는 2개의 IRP들을 보여주고 있습니다, 두 개의 파이프의 각각 하나는, 거기서 각각의 IRP는 3개의 트랜잭션을 포함하고 있습니다.

 어떤 transfer type을 위해서, Host Controller는 (micro) Frame 1에 어딘가에 2번 IRP의 1번 트랜잭션이 이끄는, 1번 IRP의 1번 트랜잭션을 이동하는데 자유롭습니다.

 만약, 이것들이 등시선 전송타입이라면, 저것은 오직 Host Controller가 가진 자유도에 입니다.

 

만약 이것들이 제어 혹은 벌크 전송 타입이 이라면, Host Controller는 더나아가 더 혹은 덜 트랜잭션들을 이동해야합니다, (micro)프레임 둘다 안에 IRP 둘다로부터 말이죠.

 

 기능들은 (micro)프레임 내에  IRP 백투백 내에서, 보이는 트랜잭션들을 의존하지 않습니다, 또한, 그들은 프레임 내에, 보이는 트랙잰션을 의존하지 않습니다.