USB 3.0の研究(38)

一方DeviceがDPを受け取った場合のアクションをまとめたのがPhoto01である。

こちらは、

(1) DPHがそもそもおかしい: 具体的な項目はHostが受け取った場合と同じ。やはりPacketを破棄して終了。

(2) DPHにDeferred bitが立っており、しかもDeviceがHalt状態可能: Defered bitがたっているということは、途中のHubによる遅延が発生している(要するにHubが待機状態だったため、立ち上がりに時間を要した)事を示す。またDeviceがHALT状態をサポートしているので、(Hubが待機状態に入る位だから)Deviceも当然HALT状態にあり、ここから復帰するまでに時間を要している。ただしこのPacketを受け取ったということは、Hub及びDeviceはNormal Stateにあるわけで、なのでそれをHostに通知するためにERDY TPを送る形になる。

(3) DPHにDeferred bitが立っており、DeviceはHALT状態不可ながら受信不能: Defered bitは上述の通り。今度はDeviceはHALT状態をサポートしていないからNormal Stateに入っていると見なされるが、ここでDeviceが受信不能というのは要するに何かしら処理を行っていて、受信処理が間に合わない事を示す。その場合、処理が終わって受信可能になってから、ERDY TPを送ればよいとされる。どのみちDeferred bitが立っている時点で遅延が発生しているので、急いでNRDYとかを送らなくてもいい、という事であろう。

(4) DPHにDeferred bitが立っており、DeviceはHALT状態不可、受信可能: これは要するに(3)の状態からいくばくかの時間が過ぎ、処理可能になった状態と見なせるわけで、やはりERDY TPを送り返すことになる。

(5) Deffered bitが正常、DPHも正常で、DeviceはHALT状態可能: この状態の場合、DPを受け取ることでDeviceはHALTから抜けた(というか、まだNormal Stateへの遷移途中の可能性もある)わけで、Hubに因らず遅延が発生していた事になる。そこで、STALL TPを送り返すことでこれまでSTALL状態にあったことをHostに通知する。

(6) Deffered bitが正常、DPHも正常で、DeviceはHALT状態不能ながら受信不能: これはもうDeviceが何かをやっているなどの理由で到着したDPを処理出来ない状態となる。したがって対処としては、到着したDPは破棄し、Hostに対しNRDY TPを送り返す事でDevice Not Readyを伝える事になる。

(7) DPHは正常に伝達されたが、Data Payload Errorの場合: このErrorというのは前回にも出てきたが、

・CRCが不正
・DPPが途中で破壊されている
・DPPが無い
・DHPのData lengthと実際のDPPのサイズがマッチしていない

というケースである。この場合はDPを破棄し、DP expected bitとRetry bitを立ててACK TPを送り返す事で再送を要求する事になる。

(8) 何もエラーがなく受け取れた: この場合は素直にACK TPを送り返してそのPacketに対する処理は終了となる。

といった流れとなる。

ここまでの話は、DeviceがIN Endpointだった場合であるが、ではDeviceがOUT EndpointのDeviceのふるまいは? だとどうか? というのがPhoto02である。詳細はもう説明しないが、基本的には同じシーケンスであることが判る。今度はDeviceからデータがでるので、DPH InvalidとかDPP Invalidを考慮する必要がない(わざとInvalid Packetを送り出す必要性は考えにくいし、少なくとも仕様で規定する必要はない)ということだろう。

(続く)