项目上发现, 板子如果接hub, hub上挂两个手柄的话, 会发现只有一个手柄能用. 但是同样的hub和手柄在PC上是能正常使用的.
由于手柄是低速设备, 因此需要涉及到 SPLIT INTERRUPT IN 的传输, 这部分需要host的软件对TT以及SSPLIT/CSPLIT进行恰当的处理.
估计是什么地方代码有问题. 检查代码后发现, tt_no_collision 这个函数居然是一个空的return 1. 真是坑人啊.
没有对iTD, SiTD进行处理.
顺便再阅读了usb 2.0 spec中hub那一节里面对TT和SPLIT TRANSACTION的描述. 摘要在这里, 方便随时查阅.
8.4.2.1split transaction
USB defines a special token for split transactions: SPLIT. This is a4 byte token packet compared to other normal 3 byte token packets.
There are two split transactions defined that use the SPLIT special token: a start-split transaction (SSPLIT) and a complete-split transaction(CSPLIT).
A high-speed split transaction is used only between the host controller and a hub when the hub has full-/low-speed devices attached to it.
Split transactions are only defined to be used between the host controller and a hub.
Start split transactions can consist of 2, 3, or 4 packets as determined by the specific transfer type and data direction.
Complete split transactions can consist of 2 or 3 packets as determined by the specific transfer type and data direction.
Figure 8-8 shows an interrupt IN example. Note that in the example,the hub provided the full-/low-speed handshake (ACK in this example) to the
device endpoint before the complete-split, and the complete-split did not provide a high-speed handshake to the hub.
Figure 8-9 shows an interrupt OUT example.
8.4.2.2SSPLIT token
A SPLIT special token packet with the SC (Start/Complete) field set to zero indicates that this is a start-split transaction (SSPLIT).
The S (Speed) field specifies the speed for this interrupt or control transaction as follows:
• 0 –Full speed
• 1 –Low speed
8.4.2.3Complete-Split Transaction Token
A SPLIT special token packet with the SC field set to one indicates that this is a complete-split transaction (CSPLIT).
The U bit is reserved/unused and must be reset to zero(0B).
11.14Transaction Translator
11.14.1Overview
Figure 11-24 shows an overview of the Transaction Translator.
The TT acts as a high-speed function on the high-speed bus and performs the role of a host controller for its downstream facing ports that are operating at full-/low-speed.
The TT has buffers (shown in gray in the figure) to hold transactions that are in progress and tracks the state of each buffered transaction as it is processed by the TT.
The TT has two buffer and state tracking sections (shown in gray in Figure 11-24 and Figure 11-25): periodic and non-periodic. The requirements on the TT for these two buffer and state tracking sections are different.
11.14.1.3 Multiple Transaction Translators
A hub can have one TT for all downstream facing ports that have full-/low-speed devices attached or the hub can have one TT for each downstream facing port. The hub must report its organization in the hub class descriptor.
11.14.2 Transaction Translator Scheduling
11.14.2.1 TT Isochronous/Interrupt (Periodic)Transaction Buffering
Periodic transactions have strict timing requirements to meet on afull-/low-speed bus.
The host software manages the host controller to cause high-speed split transactions at the correct times to avoid over/under runs in the TT periodic transaction buffers. The host controller sends data “just in time”for full-/low-speed OUTs and retrieves response data from full-/low-speed INs to ensure that the periodic transaction buffer space required in the TT is the minimum possible. See Section 11.18 for more detailed information.
11.14.2.2 TT Bulk/Control (Non-Periodic) Transaction Buffering
Non-periodic transactions have no timing requirements, but the TT supports the maximum full-/low-speed throughput allowed. A TT provides a few transaction buffers (at least two) for bulk/control full-/low-speed transactions. The host and TT use simple flow control (NAK) mechanisms to manage the bulk/control non-periodic transaction buffers. The host issues a start-split transaction,and if there is available buffer space, the TT accepts the transaction. The full-/low-speed handler uses the buffered information to issue the downstream full-/low-speed transaction and then uses the same buffer to hold any results (e.g.,handshake or data or timeout). The buffer is then emptied with a corresponding high-speed complete-split and the process continues.
11.14.2.3 Full-/low-speed Handler Transaction Scheduling
Whenever the full-/low-speed handler finishes a transaction on the downstream bus, it
takes the next start-split transaction from the start-split periodic transaction buffer (if any). If there are no available start-split periodic transactions in the buffer, the full-/low-speed handler may attempt a bulk/control transaction.
11.17 Bulk/Control Transaction Translation Overview
Each TT must have at least two bulk/control transaction buffers. This buffer is filled and emptied by split transactions from the high-speed bus via the high-speed handler. The buffer is also updated by the full-/low-speed handler while the transaction is in progress on the downstream bus.
11.17.5 Other Bulk/Control Details
When a bulk/control split transaction fails, it can leave the associated TT transaction buffer in a busy (ready/x) state. This buffer state will not allow the buffer to be reused for other bulk/control split transactions.Therefore, as part of endpoint halt processing for full-/low-speed endpoints connected via a TT, the host software must use the Clear_TT_Buffer request to the TT to ensure that the buffer is not in the busy state.
11.18 Periodic Split Transaction Pipelining and Buffer Management
The host must determine the microframes in which a start-split and complete-split transaction must be issued on high-speed to correctly sequence a corresponding full-/low-speed transaction on the downstream facing bus. This is called “scheduling”the split transactions.
11.18.1 Best Case Full-Speed Budget
A microframe of time allows at most 187.5 raw bytes of signaling ona full-speed bus.
187.5 = 12MB/s * 1ms / 8 / 8 1MB= 1000KB
11.18.2 TT Microframe Pipeline
The host always uses the maximum data payload size for a full-/low-speed endpoint in doing its budgeting. It does not attempt to schedule the actual data payloads that may be used in specific transactions to full-/low-speed endpoints. The host must include the maximum duration inter packet gap, bus turnaround times, and “TT think time”. The TT requires some time to proceed to the next full-/low-speed transaction. This time is called the “TT think time”and is specified in the hub descriptor field wHubCharacteristics bit 5 and 6.
11.18.3 Generation of Full-speed Frames
The TT has its own frame clock that is synchronized to the microframe SOFs on the high-speed bus. The TT must stop issuing full-speed SOFs after it detects 250 µs of high-speed idle. This is required to ensure that the full-/low-speed downstream facing bus enters suspend no more than 250 µs after the highspeed bus enters suspend.
11.19 Approximate TT Buffer Space Required
A transaction translator requires buffer and state tracking space for its periodic and non-periodic portions.
The TT microframe pipeline requires less than:
• 752 data bytes for the start-split stage
• 2x 188 data bytes for the complete-split stage
• 16x 4x transaction status (<4 bytes foreach transaction) for start-split stage
• 16x 2x transaction status (<4 bytes foreach transaction) for complete-split stage
There are, at most, 4 microframes of buffering required for the start-split stage of the pipeline and, at most, 2 microframes of buffering for the complete-split stage of the pipeline. There are, at most, 16 full-speed (minimum sized) transactions possible in any microframe. (怎么算出来的?)
The non-periodic portion of the TT requires at least:
• 2x (64 data + 4 transaction status) bytes
Different implementations may require more or less buffering and state tracking space.
11.20 Interrupt Transaction Translation Overview
11.20.1 Interrupt Split Transaction Sequences
In contrast to bulk/control processing, the full-speed handler must not do local retry processing on the full speed bus in response to a transaction errors (including timeout) of an interrupt transaction.
11.21 Isochronous Transaction Translation Overview
Full-speed isochronous OUT transactions issued by a TT do not have corresponding complete-split transactions. They must only have start-split transaction(s).
The host controller must preserve the same order for the complete-split transactions (as for the start-split transactions) for IN handling.
Isochronous INs have start- and complete- split transactions. The “first” high-speed split transaction for a full-speed endpointis always a start-split transaction and the second (and others as required) is always a complete-split no matter what the high-speed handler of the TT responds.