私は、Windows XPと7(そしてそれぞれ2台の異なるコンピュータ)の両方で、「このデバイスを高速USB 2.0ポートに接続すればより速く実行できる」という通知を得ることができたことに気づきました。ケーブルを非常にゆっくりと接続すると(片手でそれをやるのに少し苦労しても)アップします。私が両方の手でそれを十分に速くまたは普通に接続するならば、通知はありません。どちらの場合でも、そのようなデバイスはすべて正常に機能しているように見えます。
私が思うところは、低速/不器用な接続中にワイヤ間の接触が十分な時間中断され、それがUSBコントローラでは2.0ではなく低速だと考えていることです。しかし、なぜそう思うのですか?それとも「ケーブルの接続が苦手なので、抜いてもう一度やり直してください」と言っているのではないのでしょうか。
このメッセージは、480Mbit / sである高速(HS)データレートの代わりに、12Mbit / sの旧フルスピード(FS)データレートを交渉することを指す。 USB2ポートからこの効果を得るのは本当に難しいはずです。 USB2.0 HSプロトコルは、最初はすべてのHSデバイスがFSデバイスとして機能するため、デバイスとホスト間のかなり複雑なネゴシエーションの後に確立されます。
通常のプロセスは次のとおりです。
HS対応デバイスは、1〜1.5kΩの抵抗でVBUS信号を3.3Vに供給した後にD +ラインをプルアップします。 FSデバイスと同じように。
ホストポートはD + =ハイを検出し、最小100msのデバウンス遅延の後、ホストはバス上でUSB_RESET状態をアサートし、10または50msの間45ΩドライバでD +とD-ラインの両方をグランドに駆動します。
デバイスがFSの場合は何もせずにUSB_RESETが終了するまで待ちます。
デバイスがHSの場合、HSドライバ(18mAソース)を使用して約1msの間D-をハイに駆動します。これにより、 "Chirp-K"と呼ばれる振幅約800mV(45Ω負荷で18mA)のパルスが発生します。
ホストがHSモードに対応している場合、Chirp-KのENDが検出されると、この信号は約50µsの間、この信号を元の45Ω負荷に18mA戻します。それがFSホストであるなら、それはChirp-Kを無視し、そしてFSとして進む。
次に、ホストがHSモードに対応している場合は、ドライブをD +ワイヤに切り替え、再び50µsの間「Chirp-J」を形成します。
ホストはUSB_RESET状態の全期間(ハブポートで10ms、ルートハブポートで50ms)にわたってこの交互の50μsパターンを繰り返します。
3つのチャープK/Jを交互に繰り返した後、デバイスはホストがHSであることを認識し、HSモード自体に切り替わります。これは、デバイス側でHS終端をオンにすることを意味します。これにより、総配線抵抗は22Ωになり、チャープ信号振幅は400mVに低下して標準のHS信号レベルになります。
ホストはHSフレーム開始(SOF)パケットを処理し、HSモードで列挙プロセスを開始します。
これで、誰がウィグリングのどの部分がこのプロトコルを破ったのかを推測し、ホストをFSとしてマークするようにしました。
USB2ポートにデバイスを接続すると、コンピュータは最初にUSB2データプロトコルを使用して接続をネゴシエートしようとします。
それが失敗すると、USB1データプロトコルの使用を再試行します。
USB2ネゴシエーションの間、物理的な接続は(連絡先を動かしているために)まだ安定していません。そのため、デバイスがUSB2デバイスであっても、USB1にフォールバックします。
面白いWindowsは、デバイスがUSB2速度(ドライバから取得する情報)に対応する必要があることを認識しているので、Windowsは、接続したUSBポートは遅いUSB1ポートであると結論付けます。 Windowsはポート自体がUSB2に対応しているかどうかをチェックしていないようです。
そしてそれが、やや紛らわしいエラーメッセージを受け取る理由です。
P.SちょうどWindows 10マシンでそれを自分で試してみました:そこに同じ効果。
Windowsがコントローラとの間でハンドシェイクプロセスを完了し、その時点でUSB 2.0通信に必要な連絡先が接触していなかったため、挿入速度が十分でなかった可能性があります。 USB 2.0以上にしか存在しないとマークされたRailsには応答がないでしょう。