次に各転送におけるホストとファンクション(周辺機器)の動作を説明します。Bulk、Interrupt、Isochronous転送はそれぞれ、InまたはOut転送のいずれかを利用して転送を実現します。
一方、Control転送は他の3つの転送と異なり、Setup/In/Outの転送を組み合わせて使うことで実現されます。USBリクエストを送るSetup転送を利用するSetupステージ、返信や受信のためにIn/Out転送によってデータのやり取りを行うDataステージ、Dataステージとは逆方向の転送(Data ステージがIn転送だったら、Out転送) によってやり取りの結果を通知するStatusステージの3つのステージでControl転送は構成されます。この転送の組み合わせ方でホストからファンクションへの書き込みを行うControl Write転送、ファンクションからホストへの情報の提出を行うControl Read転送とControl Write転送の派生でホストからファンクションへのデータ書き込みのためのDataステージを持たないNo Data Stage転送の3つに分類されます。

 

Control Write転送

Control Write転送

 

Control Read転送

Control Read転送

 

No Data Stage転送

No Data Stage転送

 

Setup転送

 

Setup転送は Control転送のSetup Stageで使用される転送シーケンスで、Token、Dataはホストが発行し、Handshakeをファンクションが発行します。Setup転送ではファンクションはACK応答のみが許されています。

Setup転送

 

In転送


In転送は Control転送のDataまたはStatus Stage、Bulk In、Interrupt In転送で使用される転送シーケンスで、Token, Handshakeはホストが発行し、 Dataをファンクションが発行します。 Isochronous転送ではHandshakeは使いません。

In転送

 

Out転送

Out転送は Control転送のDataまたはStatus Stage、Bulk Out、Interrupt Out転送で使用される転送シーケンスで、Token、 Dataはホストが発行し、Handshakeをファンクションが発行します。Isochronous転送ではHandshakeは使いません。

Out転送

 

Handshakeパケットを使うことでデータ転送が成功したかどうかは判断できますが、 Handshakeパケットそのものが欠損した場合、同じものを2回連続で受信してしまうことが考えられます。2回目に受信したデータは不要なものですから、そのデータを処理してはいけません。このため、Data パケットを示すDATA0(C3h)とDATA1(4Bh)を交互に利用することで同じデータが複数回来ていることを認識できるようにしています。ホスト、ファンクションともにエンドポイント単位でシーケンス ビットと呼ばれる受信したDATA PIDの比較対象ビットを備えています。

SETUP

Transfer i

ファンクションが現在処理中で送受信を受け付けられないなら、シーケンスビットを維持したまま、NAKを返信します。もちろん、ホストもACKを受信していないのでシーケンスビットを維持したまま再転送を実施するので、シーケンスビットの同期は維持されます。

Transfer i : Reject Data

データ受信側は正常にデータ受信が完了した上でシーケンスビットが一致していたら、シーケンスビットを反転させた後にACKを返信します。データ受信側が返信したACKが何らかの理由で送信側で受け取れなかった場合、送信側はACKを受信していないため、シーケンスビットを維持したまま再転送を実施します。
このため、シーケンスビットの同期はずれが起こります。データ受信側は再転送時にシーケンスビットが一致していないため、再転送であると判断し、シーケンスビットを維持したまま、ACKを返信し受信データの破棄を行います。データの送信側はACKを受信した後に、シーケンスビットを反転させます。これによりシーケンスビットの復旧は行えます。

Transfer i : Accept Data

Control転送以外のBulk / Interrupt転送では一つエンドポイントに対しては一つの転送方向のサポートしか許されません。このため、In転送でファンクションがACKを受信できなかったとしても、次のIn トークンを受信したときに上述の動作が起こり、シーケンスビットの同期はずれの復旧は行えます。ところがControl Read転送のData ステージでの一番最後のIn転送でファンクションがACKを受信できなかった場合は特殊なケースになります。つまりACKを受信できなかった場合、次のIn トークンを受信できる可能性はなく、Status ステージを示すOut転送が開始されます。このため、Control Read転送ではIn転送でファンクションがACKを受信できなかった場合にその直後にOutトークンを受信したら前回のInはホストによって正しく受信されたものと暗黙のうちに理解して次のシーケンスに進むことが義務づけられています。
Control/ Bulk / Interrupt転送と異なり、Isochronous転送ではバス上でCRCエラー等の問題が入り込む可能性が低いであろうということを拠り所にし、また問題が起こったとしても再転送している時間がないのでHandshakeは使いません。さらにIsochronous転送特有の概念がホスト側との同期の取り方についてです。同期の取り方はAsync/Sync/Adaptiveの3種類が定義されています。Asyncは周辺機器のサンプリング周波数が固定されていて、システムのクロックと同期をとることができないものです。データを受け取る側がAsyncの場合、レートマッチは送る側で行う必要がありますから、どの周波数で動作しているかをデータの送信側にフィードバックしてあげる必要があります。SyncはSOFと同期したクロックでサンプリングする周辺機器です。Adaptiveはレートマッチ機能を持っていて、動作しながらSourceならSinkにSinkならSourceに、つまり相手のサンプリング周波数に自分のサンプリングレートをあわせることができるもののことです。

  • カタログポータル