2007-10
もう１０月
- この暑さはなんなんだろう。
- ＢＢＲ-４ＭＧを買った。
- しかも新品でだ。正気の沙汰ではないなぁ。暑さのせいか？
さて、このルーターでＷＬＡＮ ＡＰを作ろうと思うが、はたして気力が続くだろうか？
- 中古のＡＰを買っといたほうが良かったかなぁ・・・とすでに後悔先に立たず。
- だめだめだぜ。すでにＡＶＲとは何の関係もない展開。
ＵＳＢ ３.０
ＭｙＣＯＭジャーナル連載記事
引用
＞USB 3.0の信号にはPCI Express Gen2のx1 Laneの物理層(Electrical層とLink層)を ＞そのまま流用した。ただし流用したのはここまでで、Transaction層は全く独自となる。 ＞ソフトウェア面では、USB 2.0までのソフトウェアスタックをそのままUSB 3.0でも ＞「なるべく」採用する。これにより、USB 2.0→USB 3.0への移行に要する手間をなるべく抑える。
ふーん。
ますますＡＶＲとは無縁の方向だな。
LowSpeed , FullSpeed , HighSpeed と来て、次は何と呼ぶのかだけが興味の的だ。
いやいや、もしかしたらマイクロフレームの次にナノフレームが出来るかもしれないし、 超ハイスピードハブをＡＶＲとＰＣの間に挟むことでＰＣから見たらＡＶＲ側が超ハイスピードデバイスに見えるのかもしれないという予測が当たったら笑えるというただそれだけだ。
ＢＢＲ-４ＭＧは、一瞬でＬｉｎｕｘＢｏｘになった。
びんずめ堂 BBR-4MG::Linux化ファームウェア
- びんずめ堂さんのＬｉｎｕｘ化ファームのおかげで、半田ごても改造も一切なしで（そうだ、蓋さえも開けることなく*1 ）、 新品のＢＢＲ-４ＭＧはものの３分もしないでＬｉｎｕｘ Ｂｏｘになってしまった。
凄すぎる。
- ２ＭのＦｌａｓｈによくこれだけ詰め込めますな。
BBR-4MGを改造してlinuxルータにする計画
- こちらのほうは、ＵＳＢを繋ぐために基板を改造して４８ＭＨｚの水晶モジュールを接続して、ＵＳＢメモリー にファイルシステムを置くタイプ。（ファームはＵ-ＢＯＯＴだけを入れている）
- ＢＢＲ-４ＨＧのほうは２０００円くらい高いが、おそらく付属品（ＬＡＮケーブル）とファームが違うだけなんじゃなかろうか。
- ＦＬＡＳＨはｉｎｔｅｌだった。
- ＡＤＭ５１２０Ｐはｉｎｆｉｎｅｏｎ製のようだ。（ＡＤＭｔｅｃｈと違うの？）
- （ADMtechはinfineonに買収されたらしい）
- さすがに１７５ＭＨｚなので熱くなる。
- ５．５Ｖ９００ｍＡの電源は重い。トランスのようだ。５Ｗ程度？買ってきた箱には定格３．５５Ｗと書いてある。
ＡＶＲｔｅｒｍは１９２００に追いついてない。
- 久しぶりにH8/3048FをUSBに繋ぐ。（１９２００）
- ＶＩＡのＵＳＢホストだと文字化けする。
- ＳｉＳならＯＫ。
えーと、ＶＩＡだとＵＨＣＩなので、７バイト受信トランザクションに４ｍＳ。
- ってことは１秒に１７５０バイト。
- ボーレートにすると１４０００ボー。
バッターアウト！
- ＶＩＡだめだめじゃん。
- っていうかＡＶＲｔｅｒｍ使うためにＨｉＳｐｅｅｄハブかＮＥＣのＵＳＢホスト買ってくる必要があるなんて・・・ナンセンスだよなー
- 送信パケットのペイロードは４バイトより増やせないけれど、受信パケットを１６とか３２にしておいて、ＡＶＲ側が可変長パケットで応答するというふうに変更しようかな・・・。面倒だけど。
ＡＶＲｔｅｒｍは１９２００に追いついた。
- コントロール転送時の受信パケットを２４バイトに増やした。
./checksize main.bin ROM: 1722 bytes (data=4) RAM: 109 bytes
３２バイトに増やすとたぶんスタックが足りない。 - ＡＶＲ＿ｔｅｒｍも改造。
- Ｈ８/３０４８Ｆのモニターと交信できた。
- 文字落ちしなくなった。
ついでにＷ３２＿ｔｅｒｍのほうも同じプロトコルに改造した。
- Ｗ３２＿ｔｅｒｍを使用してＨ８/３０４８Ｆとの交信に初成功
おめでとう。俺 これでＨ８はめでたくWindowsの仮想ＣＯＭ：ポートに接続完了だ。
- ちなみにＵＳＢホストはインテル（ＵＨＣＩ）でハイスピードハブなし直結だ。
解説：
- ＵＨＣＩは１回のコントロール転送（ベンダリクエスト＋８バイト受信）のトランザクションに４フレーム（＝４ｍＳ）を費やす。
- ＡＶＲ＿ｔｅｒｍではそのトランザクションで７バイトの受信データを転送するので都合１４０００ボーが転送スループットの最大である。
- Ｈ８/３０４８Ｆのモニターは１９２００ボーに設定されている。
- 間に合わない。
そこで、１トランザクションでの受信要求サイズを２４に増やした。
- １回のコントロール転送ではベンダリクエスト（８バイト）＋受信データ（可変長）最大２４バイトを受け取るように改良した。
- ２４バイトの転送が発生すると２フレーム増加し６ｍＳになるが転送量は２３文字に増えるため、３８００バイト/秒のスループットが稼げる。
- これはビットレートに換算すると３０４００ボーだ。
- これでも３８４００に達しないところが凧であるが・・・
- こうしておけば、ハイスピードハブを挟むだけでこの３倍くらいはいけるようになる（はずだ）
（マイクロフレームのおかげ・・・）
- ＡＶＲ側のメモリー的にはＲＳ２３２Ｃ受信バッファ（ＦＩＦＯ）が３２バイトとＵＳＢ転送バッファ（ＰＡＣＫＥＴバッファ）２４バイトでだいぶ圧迫される。
- これを１つにまとめられれば一挙にメモリー節約になるのだが・・・
- たぶんigorさんのはまとめているのだろう。
- なんとなく・・・チト無理か。
usbdrvasm16.S解読
このソースは芸術品だ。
- クロック数のとおり寸分違わず時を刻むＣＰＵのなんと有難いことよ。
- 今どきのＣＰＵはキャッシュがあるのでタイミングなんて合うわけない。
- で、受信の同期取りはleapという８ビット変数だが。
- 初期値＝０
- １ビット読むたびに-3
- ８５回で-２５５（＝＝１）
- １バイトは８５.３３３３３cycles
- 最後に１引いて正（＋）だったら３足して１サイクルＮＯＰ。
- 「最後に」というのは１バイト受信後である。つまり１ビット単位でのleapはやってない。
さっぱり分からん。
- 単純化するならば、８５.３３３３という周期を生成したいなら、
- ｛８５，８５，８６｝（のくりかえし）というふうにすればよい。
- ほんとにバイト単位で３バイトに１回の１サイクル挿入をやっているのかどうか*2
- 読解する力が足りない・・・
- 送信は00101010（０ｘ２Ａ）というビットパターンをbitcntに入れる。
- lsr bitcntするので、右から数えて、
10, 11, 10, 11, 10, 11, というクロック進行になる。
- あとの２ビットはどうするかって？そりゃアンロールされたほうのルーチンで制御だ。(didStuff6,didStuff7)
- 送信についてはleapは使っていない。たぶん10.5cycle/bit固定なのだろう。
- 誤差が10.6666 vs 10.50000(?) = 0.16666 / 10.6666 と1.5％くらいあるが、ＵＳＢの許容範囲らしい。
- むしろ10,11,10,11のジッターのほうが気になる・・・。
昔、磁気ドラムの回転（に同期するように）うまく利用して書かれた（大型？）計算機のプログラムがあったらしいが（ハッカーズディクショナリに書いてあった奴）、それに匹敵するくらいのトリックだ。
メルの物語
磁気ドラムの話は、うろおぼえだったので、Google先生に聞いてきた。
たぶんこれ。ちょっと極端かもしれない。
usbdrvasm16.Sを読み返すと・・・
- やはり予想通り、受信時もEven bitとOdd bitで所要クロックを変えてある。
- クロック進行は10,11,10,11,10,11だ。
- これだと平均クロックが10.5000になり、１６ＭＨｚで必要な10.66666cycle/bitと比べて １.５％程度速いコード進行になる。
- ８ビットで10.5×8＝８４クロックだ。
- しかし、正確な８ビットの時間は８５.３３３３３cycleなので、１バイト受信ごとに１クロック遅れるようにしてさらに３バイトに１回で１クロック遅れさせると８５.３３３３３cycle/byteを達成できる。
- １.５％の誤差は１バイト単位でスタートビットの同期合わせが出来るＲＳ２３２Ｃでは問題にならない*3が、
- ＵＳＢの最大パケット長はペイロードだけでも８バイトあるので（ＰＬＬ的な処理でも入れない限りは）累積誤差*4でエラーを起こすことになる。
このソースは「メルの物語」に匹敵するほどの価値があると思う。
目次
*1 嘘。ＦｌａｓｈＲＯＭのメーカーを調べるためと、ＣＰＵの発熱具合を知るために一回フタ開けた
*2 正確にはビットスタッフを含めた８ビット時間ごとに１回分の挿入と２４ビット時間ごとに１回分の挿入が必要なはずだが、正味１バイトデータに対して１回の挿入になっているので誤差をどうやって処理しているのか解読出来なかった
*3 スタート、ストップビットまで合わせて１０ビットあるから１.５×１０＝１５％。パルス中央に対して最大１５％ずれてもなんとか許容できる
*4 荒っぽく１６バイト時間＝１２８ビット時間を仮定すると１.５％×１２８＝１９２％もずれて別のビットを読んでしまう
