ＶＨＤＬを速習！ ＸＣ９５１４４ＸＬ＋１６ＭＢ・ＳＩＭＭを使ってＵＳＢプロトコルアナライザを作ってしまいました！
主目的は差し迫った事情からＵＳＢプロトコルの解析をすることだったのですが、その手段として選んだのがコレ！
［第１８回］
●スタッフビット（ｓｔｕｆｆｂｉｔ）
前回の終わりのところでお見せした画像に「一箇所おかしいところがあります」と書きましたが、どこだかおわかりになりましたでしょうか？
もう一度その画像をお見せします。
解読したリストの上半分ぐらいはずっと ＳＯＦ ＦＮＯ＝ が並んでいます。
ＳＯＦ とか ＦＮＯ は勿論解読プログラムｕｓｂｃｋｒ．ｃｏｍによってコードを翻訳した結果を表示したものです。
ＳＯＦはフレームの始まりを示すパケット名です（Ｓｔａｒｔ ｏｆ Ｆｒａｍｅ）。
ＦＮＯはＦｒａｍｅ Ｎｕｍｂｅｒの略です。
フレームはホストによって１ｍｓごとに送られます。
そのときフレームには連続したフレーム番号がつけられます。
フレーム番号は１１ビット長ですので１６進数で０００〜７ＦＦの番号になります。
０００から始まって７ＦＦまでいくとまた０００に戻って繰り返されます。
この番号は連続して発行されるフレームに機械的につけられるもので、連番であるということ以上の意味はありません。
その番号をずっと下の方へ見ていきますと、おかしいところがみつかります。
０５Ｄ、０５Ｅ、の次が０９Ｆになっています。
その次が０６０ですから、この０９Ｆは間違いで本当は０５Ｆが正しいのではないか、ということが容易に推測できます。
まあかなり乱暴な回路でデータの取得を行なっていますから、ノイズの影響なのかどうかはわかりませんが、中にはおかしなところがところどころに見られます。
しかしこのＦＮＯについてはノイズの影響やデータの誤読ではありません。
実はこれはＵＳＢ信号をパラレルからシリアルに変換して送る場合にある決ったルールで挿入されるスタッフビット（ｓｔｕｆｆｂｉｔ）のせいなのです。
［第１３回］でＮＲＺＩ変調について説明をしました。
パラレルデータをシリアルに変換するときに、０のビットのときは前の信号の状態を反転し、１のビットのときは前の状態を維持する、という変換ルールでした。
こうすると０が連続したときは、信号が０１０１…と反転を繰り返すために、信号を安定して送ることができます（ずっとＨレベル、Ｌレベルのままだとノイズの影響を受けやすくなります）。
するとここで疑問になるのは、それでは１ばかりが続いたらどうなるのかということです。
もとのデータがたとえば連続してＦＦが続くような場合を考えてみますと、その前の状態によって、０か１が連続して続くことになります。
そこで、もとのデータで１が連続して６個以上続く場合には、６番目の次に強制的に０を挿入して送ります。
０を挿入することで連続して続く状態をそこで反転させてしまうのが目的です。
これをスタッフビット（ｓｔｕｆｆｂｉｔ）といいます。
ビットスタッフということもあるようです。
さきほどの例について考えて見ます。
翻訳前のデータを１６進数ダンプファイルで表示してみると、問題のＦＮＯ＝０９Ｆは８０ Ａ５ ９Ｆ ４０ Ｆ５というデータであることがわかっています。
それを普通のルールで翻訳してみると、上の画像の６〜９行のようになります。
ここではたまたま１６進表記でも翻訳後のコードと同じに見えますが、いつもこのようになっているとは限りません。
ここはたまたまそのようになっただけです。
さてそこでＡ５と９Ｆのところを見ますと１が連続して６個続いています。
これは受信データをシリアルからパラレルに戻したあとを見ているのですが、送信するときにも同じパラレルデータをシリアルに変換して送出しているはずです。
するとここで１が６個連続していますから、その次の０（￥マークで示す）は実は強制的に挿入された０ではないかという推測が成り立ちます。
そこでその０を削除して、そこから後ろを順に前につめたあと、もう一度解読してみたのが、その下の１２行から１５行です。
おお。
ＦＮＯ＝０５Ｆになりました。
なおＳＯＦデータの前後にＦＦが連続していますが、これはデータの’ＦＦ’ではなくて、無信号の状態ですのでホストから送出する意味の有る’ＦＦ’データではありません。
ですからこの部分にはスタッフビットは挿入されません。
ＣＰＬＤ＋ＳＩＭＭを使ってＵＳＢプロトコルの解析を！［第１８回］
２０１４．２．１７ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る