●Ｈｏｔ Ｎｅｗｓです！ ＵＳＢ通信に成功しました！
氷解という言葉があります。
溶融とか融解という言葉もあります。
一生懸命加熱しても全く変化がなかったのに、ある点を超えると一気に解けてしまう、ということが物質の世界にはあるようです。
トランジスタやダイオードでも確かブレークダウンという現象があったように記憶しています。
そうそう、社会現象としては、「ベルリンの壁」がまさにそういった感じでした。
人間の脳も物質ですから、その産物たる思考もやっぱり物質としての法則に影響されるのでしょうか。
何日も何日も同じところを堂堂巡りばかりしていて、全く解決できなかったことが、ある日突然一気に氷解してしまう、ということを過去に幾度と無く経験をしてきました。
今回のＵＳＢもまさにその通りで、昨年秋から、大きなカベが３つ４つくらいあったのですが、それぞれがある時点で、まさに「突然に溶けて（解けて）」なくなってしまいました。
この数日間の進展もちょうどその通りの展開で、もう何日も、同じところでカベにぶつかってしまって「わからん、だめだ」の繰り返しだったのですが、突然に「わかったぞぉ！」と、一気に解決してしまいました。
いずれゆっくり順をおって説明をしていく予定ですが、まずはホットなトピックスということで。
ホットもホット、ＵＳＢの通信に成功したのは、ついまだ２時間ほど前のことでした。
こんなことになりました。
あ。かなりコーフンしていましたので、画像の配置が左右逆になっています。
ＤＯＳ窓（ＤＯＳプロンプト）が２つ開いています。
右がホスト（ＰＣ）で、送信側です。
プログラムはＢｏｒｌａｎｄ Ｃ＋＋で作成しています。
！〜’までの文字列をＵＳＢ経由でＰＩＣ１８Ｆ４５５０に送信したところです。
確認のため同じプログラム（ＨＩＤＴＥＳＴ１＿６．ｅｘｅ）を２回実行しています。
いろいろ表示されているデータは、ＰＩＣ側から送信された情報（デバイスデスクリプタなど）です。
中ほどに
ＶｅｎｄｅｒＩＤ：４ｄ８
ＰｒｏｄｕｃｔＩＤ：ａ
という文字が見えます。
４ｄ８というのはＭｉｃｒｏｃｈｉｐ社の登録ＩＤです。
ＰｒｏｄｕｃｔＩＤは、私が適当に書き込んだＩＤナンバー（０Ａ）です。
左のＤＯＳ窓についてはちょっと説明が必要です。
下図は今回のテストの説明図です。
Ｗｉｎｄｏｗｓパソコン（９８ＳＥ）とＰＩＣ１８Ｆ４５５０テスト基板とはＵＳＢケーブルで接続されています。
今回はＵＳＢ通信のテストとして、まずＰＣ→ＰＩＣの方向での送信テストを行いました。
ＰＩＣ１８Ｆ４５５０はＵＳＢ経由で送られてきたデータをバッファにプールしたあと、テストのため、１６進数データ（ＡＳＣＩＩコード）に変換したうえで、２３２Ｃシリアルを通じて送出します。２３２Ｃシリアルデータは当社のＢＡＳＩＣボードＺＢ２５Ｋで受けます。
両者の間の通信は実際には”ＲＳ２３２Ｃ”ではなくて”ＲＳ４８５”に変換して行います（２３２Ｃのように専用のケーブル、コネクタが不要で「ミノムシクリップ」で接続してもいけるという簡便さが、その理由です）。
ＺＢ２５Ｋは送信元のパソコンとパラレルケーブルで接続しています。
ここでＺＢ２５Ｋを間にはさんでいる理由は、２３２Ｃの受信および結果の表示をするプログラムをＺＢ２５ＫのＢＡＳＩＣで組むほうがパソコン本体の上でＣなどで組むよりはるかに楽である、という点に尽きます。
さて、そこでさきほどの左のＤＯＳ窓ですが、ここの緑色の表示は、じつはパラレルポートを通じて接続されているＺＢ２５Ｋから送られてきた「文字情報」をそのまま表示しているだけなのです。
この表示文字列は同じＤＯＳ窓に表示されているＢＡＳＩＣプログラムの実行によって、ＰＩＣ１８Ｆ４５５０からＲＳ４８５経由で送信されてきた文字データを受信して、そのまま表示させたものです。
ＢＡＳＩＣプログラムはＺＢ２５Ｋで実行されていて、パソコンはその実行には直接関与していません。
つまりＺＢ２５Ｋ（ＣＰＵはＫＬ５Ｃ８０１２）がＰＩＣ１８Ｆ４５５０から受信したものを、ちょいとＷｉｎｄｏｗｓの画面を借りて表示しているもの、と理解してください。
で、その表示文字列（つまりはＰＩＣ１８Ｆ４５５０がＵＳＢ経由で受信した文字データを１６進数表示にしたもの）を見てみますと、パソコンから送信した文字列の１６進コードに一致していることがわかります。
ただしよく見ると最初の１文字（！、コード２１）が欠落しています。
２回テストを行って２回とも同じ結果になっています。
これは実は送信側のＡＰＩ（ＷｒｉｔｅＦｉｌｅ）が原因です（バグではありません。Ｍｉｃｒｏｓｏｆｔのサイト”ＭＳＤＮ”にその説明があります）。
この点については、理由がわかっていますから実用段階ではクリアできると思います。
今回はＰＣからＰＩＣへの送信テストでしたが、ここまでできたのですから、「受信」についても多分うまくいくと思います。
かれこれ２〜３ヶ月ほども泥沼状態の中で苦戦苦闘してきましたが、これで、やっと泥沼から抜け出せたのではないか、と思います。
大きく完成に向けて進んだことになると思います。
テスト中の写真です。
左下のジャノ目基板がＰＩＣ１８Ｆ４５５０テストボードです。
ＵＳＢコネクタの横の８ｐｉｎのＩＣがＭＡＸ４８５です。
少し上方にもＭＡＸ４８５のジャノ目基板があります。
これは写真右側のＺＢ２５Ｋに接続されています。
２つのＭＡＸ４８５の間は２本のミノムシクリップでつないでいます（完全な手抜きです）。
●最初は仮想ＣＯＭポート（ＣＤＣクラス）でスタートしたのですが…
ＵＳＢと一口にいっても、その中身は非常に多様で、全体についてはまだよく理解できていません。
ただ、そもそもの目的は、ＭＹＣＰＵ８０で使用した、ＦＴ２３２ＲＬとＰＩＣ１６Ｆ８８を使った、ＵＳＢ→２３２Ｃ変換（仮想ＣＯＭポート）をＰＩＣ１８Ｆ４５５０に置き換えてしまいたい、ということにあったわけですから、当然、ＣＤＣクラス（Communication Device Ｃｌａｓｓというのだそうですね。なるほど）という分類にある、仮想ＣＯＭポート方式でのＵＳＢ通信を行う、ということからスタートしました。
といってもＵＳＢの基本的なことがらを理解すること自体が大変なことで、なかなか実際の通信を行うというレベルにまでは到達できません。
最初のハードルは「Ｅｎｕｍｅｒａｔｅ」とかいう、あのＤｅｖｉｃｅｄｅｓｃｒｉｐｔｏｒやらＣｏｎｆｉｇｕｒａｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒやら、さっぱりわけのわからぬものを送出する（どうやって？）という、不得要領なことを理解しなければなりません。
そこをほぼクリアできるところまで来るのにざっと２ヶ月ほどもかかってしまいました。
とりあえずはＰＩＣ１８Ｆ４５５０のファームウェア構築から取りかかったのですけれど、やっとのことで「不明なデバイス」として検出されるあたりまでこぎつけることができましたので、ぼちぼちＰＣ（ホスト）の側のプログラムにも手をつけようか、と思いましたら…。
うう。ＣＤＣクラスはＷｉｎｄｏｗｓ９８ではサポートしていない…？
んなことはないでしょうよ。だって、ちゃんとＷｉｎｄｏｗｓ９８でもＦＴ２３２ＲＬを使ってＵＳＢ→２３２Ｃ変換をしてるじゃないの？
あれ？そうか。専用のドライバを使ってるんで、ＣＤＣクラスとは限らないわけか。
いや、しかし、それでは、困る。
冗談ではない。
そりゃあ、皆様方は多分ＸＰをお使いでしょうけれど、何回も書いていますように、私ぁＸＰは使いたくない。
ずっとこのまま９８を使いたい。
いろいろ調べてはみたのですけれどねえ。
Ｗｉｎｄｏｗｓ９８ではＣＤＣをサポートしていない、というのは本当のところ、そうなのかどうか、ということもいまひとつはっきりしませんでしたけれど、なにしろまだＰＩＣの側のプログラムも完全には出来ていないのですから、それを確かめるわけにもいきません。
まさに泥沼です。
こんなところからは、はやくぬけださなくっちゃ…。
●で、ＨＩＤクラス、に方針を変更してしまいました
泥沼でもがいていましたら、むむ、ひょっとしてＨＩＤが突破口になるのでは？という考えが浮かびました。
ＨＩＤ（Ｈｕｍａｎ Ｉｎｔｅｒｆａｓｅ Ｄｅｖｉｃｅ）クラスです。
でもねえ…。
キーボードとかマウスでしょ。
ちょっと、そんなんじゃ、２３２Ｃの代用にはならないのでは…。
ところが、ところが、ふと気がついてみましたら、かの秋月のＰＩＣプログラマ、もＨＩＤだったんですよぉ。
ＰＩＣプログラマを接続して、デバイスマネージャで見るとちゃんとＨＩＤデバイスとして認識されていることがわかりました。
秋月のＰＩＣプログラマは、ＰＩＣ１８Ｆ２５５０を使っています。
ＰＩＣ１８Ｆ２５５０を使って、ＨＩＤクラスでＵＳＢ通信をして、ＰＩＣデータの書き込みを行うことができるのですから、その程度のデータの送受信ならできる、ということになります。
（下図）今回通信テストを行ったＰＩＣ１８Ｆ４５５０テストボードはＨＩＤデバイスとして認識されています。
それにしても、ＣＤＣとＨＩＤじゃあ格落ちなんじゃないの？
とお思いかもしれません。
そこで、じゃあ、ＨＩＤクラスではどの程度の通信が行えるのか、というあたりを調べてみました。
あ。ＵＳＢにもいろいろバージョンがあって、通信速度もいろいろ、らしいです。
でもここでは現在ごく一般的なＵＳＢ２．０での場合について考えてみます。
ＨＩＤクラスとしては、１パケットあたり６４バイト、というのが最大送信量のようです。
パケットというのは、ＵＳＢのハードレベルでのミニマムな送信単位（要素）です。
複数のパケットが集まってフレームという単位になって送信されます（いずれもう少し詳しく説明します）。
たった６４バイト？と思うことなかれ、です。
これがなかなかばかにしたものじゃないのですよ。
そのパケットの送信速度に注目、です。
ＵＳＢではフレームを１ｍｓ毎に送信します。
ＨＩＤクラスでは１フレームに１データパケットということらしいので、６４バイト／パケットということは、６４バイト／ｍｓということになります。
それはわかるけど、それのどこが、ばかにできない、なのお？
ばかになどできませんです。
２３２Ｃと比べてみましょうか。
２３２Ｃでは通常１バイトのデータを送るのに、スタートビットとストップビットを付加しますから（ＵＳＢでは、それはありません）、２３２Ｃのレートに換算するなら、６４バイトは６４０ビットの送信量になります。
６４０ビット／ｍｓです。
２３２Ｃではボーレートという単位を使いました。ボーレートは実質的にはビット／秒です。
すると、６４０ビット／ｍｓは、６４０Ｋビット／秒です。つまり、６４０Ｋボーです。
ＤＯＳの時代の２３２Ｃのボーレートは、最高でも１９２００ボーくらいでしたから、ＨＩＤの威力がわかろうというものです。
どうです。
これなら、文句無し、じゃありませんか。
あ。最初にお見せした、送信テスト、あれがそのテストです。
速度の測定はしていませんが、１パケット（１ｍｓ）で６４バイトのデータが送信されたことは間違いありません。
［１０．１．２０追記］
ここでは話を簡単にするため、１パケット＝１フレーム＝１ｍｓ、として説明をしています。
実際には１パケットではなくて複数パケットが集まったフレームが１ｍｓごとに送られる単位です（次回説明の予定）。
転送の方式によっては、１つのフレームに複数のデータパケットを詰め込んでしまうものもあるようです。
映像や音声データなどのように多少データが不正確になっても大量に送りたいとき（アイソクロナス転送方式）は、そうなっているようです。
ここで扱うＵＳＢの送信周波数は、なんと１２ＭＨｚです。
しかもこの周波数はそのまま送信データのビットレートになっています（もちろんチェックビットなどを含めた総体として送るときのビットレートですが）。
ＤＯＳの時代のＲＳ２３２Ｃは、１バイト８ビットにスタートビットとストップビットを加えたうえに、さらに、送信クロックｘ１６とかｘ６４とかということで、１ビットあたり１６クロックまたは６４クロックを消費して送信していたのですから、隔世の感あり、とはまさにこういうことをいうのでしょう（いやあ技術の進歩と言いますが、ほんとにすごいものです）。
１２ＭＨｚでもおったまげてしまいますのに、なんですか４８０ＭＨｚなんていうモードまであるのだそうですから、そりゃあもう、そこまではとてもついていけません。
１２ＭＨｚでもＴＴＬの限界に近い速度ですから、そんなものには、手が出せませんし、理解の外です。
で、話をもとに戻しまして、そのフレームなのですが、ちょっと計算をしてみました。
１フレームが１ｍｓで、ということは、転送クロックは１２ＭＨｚですから、フレームあたり、最大では１２０００ビット送信できることになります。もちろんこれを全て送信データに割り当てることはできません。当然のことながらフレームごとに区切りが必要ですし、いろいろ仕掛けが必要です。
しかし、上で説明しましたＨＩＤでの転送データが１パケット（＝１フレーム）あたり最大で６４バイト（＝５１２ビット）である、ということから考えますと、そのいろいろな仕掛けなるものを考慮したとしても、フレームの中は「がら空き」だということになります。
ま、ちょいともったいない、とも思いますが、その間にホストもＰＩＣも、そのまたさらにその先にあるＣＰＵも、それぞれ送受信のためのプログラムを実行しなければなりませんから、「がら空き｣程度が、それでちょうど、程よい速度、ということになるのでは、と思います。
程よいどころか、６４バイト／ｍｓということは、ＰＩＣや８ビットＣＰＵは、１バイトのデータをわずか１５μｓで処理しなければならない、ということですから、これは多分とても「間に合わない」ほど高速な転送速度である、と言えるでしょう。
たとえばＭＹＣＰＵ８０やその他のマイコンボードで、ＰＩＣを介してＵＳＢで送受信するとした場合、マイコン（ＣＰＵは８０８０とします）側は、すくなくとも
ＬＯＯＰ：ＭＯＶ Ａ，Ｍ
ＯＵＴ ８０ ；Ｉ／Ｏアドレス８０にデータを出力
ＭＯＶ Ａ，ＦＥ ；ストローブパルスＯＮ
ＯＵＴ ８１ ；ストローブパルスがＩ／Ｏアドレス８１のビット０であるとしたときの例
ＩＮＲ Ａ ；ストローブパルスＯＦＦ
ＯＵＴ ８１
ＩＮＸ Ｈ
ＤＣＲ Ｂ
ＪＮＺ ＬＯＯＰ
というようなプログラムを実行して、やっとＰＩＣに１バイトのデータを送ることができるのですから、これはとても１５μｓではこなせません。
概算として、ＯＵＴ、ＪＮＺを１０クロック、その他を５クロックで計算すると、上のプログラム例の１サイクルは、６５クロックかかります。
ＣＰＵクロックが２ＭＨｚの場合、１クロックは０．５μｓになります。
すると６５×０．５＝３２．５μｓですから、とてもとても間に合いません。
ＣＰＵクロックを４ＭＨｚにしてもまだ間に合いません。
６ＭＨｚならなんとか間に合います（約１０μｓ）。
でも６ＭＨｚでも余裕は４μｓぐらいしかありませんから、ＰＩＣへデータを送るだけでほぼ精一杯です。ほかのことはおそらく何もできません。
ＣＰＵはそれでよいとしても、この同じ１ｍｓの間に、ＰＩＣはＣＰＵからデータを受け取ってそれをホスト（パソコン）に送信しなければなりません。
ホスト（パソコン）も、同じ１ｍｓの間で、ＰＩＣから受け取ったデータをファイルに格納するなどの作業をしなければなりません。
そのように考えてくると、ＨＩＤで十分（過ぎる）ということになろうかと思います。
［追記ここまで］
●参考までに、プログラムの送信部分のリストです
ところで、送信部分のプログラム（Ｃ＋＋）なのですが、まだテスト段階なので、一部だけ、お見せいたします。
これがまた、２３２Ｃよりも簡単、あっけないくらいです。
ご覧の通りＷｒｉｔｅＦｉｌｅ（）一発で終わりです。
ＣＰＵをつくろう！第４２１回（２０１０．１．１９ｕｐｌｏａｄ）を再編集
ＰＩＣでＵＳＢを！［第２９回］
２０１１．７．９ｕｐｌｏａｄ
前へ
次へ
目次へ戻る
ホームページトップへ戻る