(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第４８２回］
●ＷｒｉｔｅＦｉｌｅ（）の続きです
本日もＷｒｉｔｅＦｉｌｅ（）についてのお話です。
［第４７９回］で、ＷｒｉｔｅＦｉｌｅ（）関数を使って、文字列を連続してＵＳＢ（ＨＩＤ）で送信するテストを行いました。
送信側のＷｉｎｄｏｗｓマシンのプログラムは、とくにタイミングなどを考慮せずに連続してＷｒｉｔｅＦｉｌｅ（）を繰り返し実行しました。
一方、受信側のＰＩＣ１８Ｆ４５５０は、その文字列をＵＳＢ（ＨＩＤ）で受信する度に、その受信したデータをＲＳ２３２Ｃ（ＲＳ４８５）で当社のＢＡＳＩＣボードＺＢ２５Ｋに送信しました。
ＲＳ２３２Ｃのボーレートは９６００ボーですが、ＵＳＢ（ＨＩＤ）の通信速度とは比較になりません。
ＲＳ２３２Ｃでは１バイト８ビットのデータを送信するのに、スタートビットとストップビットを付加しますから、１文字あたり１０ビットの送信が必要です。
９６００ボーは９６００ビット／ｓｅｃと考えることができますから、９６０文字／ｓｅｃの送信速度になります。
Ｗｉｎｄｏｗｓマシンが１回のＷｒｉｔｅＦｉｌｅ（）の実行でＰＩＣ１８Ｆ４５５０に送信した文字列は約４０バイトですから、これはＵＳＢ（ＨＩＤ）では１ｍｓｅｃで送信してしまうことのできるデータ量です。
しかしそれを受信したＰＩＣ１８Ｆ４５５０が、ＲＳ２３２Ｃで同じ文字数のデータを送信するには、４０／９６０≒０．０４２ですから、４０ｍｓｅｃ以上もかかってしまいます。
ＷｉｎｄｏｗｓマシンとＰＩＣ１８Ｆ４５５０との間でハンドシェイクができていなかったら、ＰＩＣ１８Ｆ４５５０からＺＢ２５ＫへのＲＳ２３２Ｃ送信はまともに行うことはとてもできません。
ＰＩＣ１８Ｆ４５５０はＵＳＢで送られてくるデータを受信するバッファをもってはいますが、このテストで使ったテストプログラムの仕様では、受信バッファはＨＩＤでの受信データ１回分６４バイトのバッファしかありませんから、連続してデータが送られてきたら、ＨＩＤのデータを受信するだけで精一杯で、それをＲＳ２３２Ｃで送信する余裕はとてもありません。
しかし［第４７９回］で行った連続送信のテストでは、Ｗｉｎｄｏｗｓマシンから連続して送信した文字列データは、その全てが誤り無くＺＢ２５Ｋに送られました。
ということは、ＵＳＢ（ＨＩＤ）では、ホストからＨＩＤデバイスにデータを送信するときに、デバイス側が受信できる状態になるまで、ホストからの送信を待たせておくことができる、ことになります。
実はＰＩＣ１８Ｆ４５５０のプログラムで、ホストからの送信に対して、READY／NOT ＲＥＡＤＹの状態にすることができるはずで、それがうまく機能するかどうかのテストでもあったのです。
その結果は、ご覧いただいた通りで、どうやらうまくいったようですので、とりあえずホストからデバイスへのＨＩＤ送信については、実用レベルにまできた、と考えてよいのでは、と思います。
ＰＩＣ１８Ｆ４５５０がホストからの送信を待たせるための仕組みについては、いずれＰＩＣ１８Ｆ４５５０側のプログラムの説明をするときに、詳しく説明をすることになろうか、と思います。
ですのでここでは簡単にその概略のみを説明することにいたします。
●ＰＩＣ１８Ｆ４５５０のＵＳＢ送受信の仕組み
ＰＩＣ１８Ｆ４５５０はチップ内にＵＳＢ通信に必要な全てを備えています。
ですから外付けの回路は全く必要ありません。
ダイレクトにＵＳＢラインに接続することができます（［第４８１回］ＰＩＣ１８Ｆ４５５０回路図）。
ＵＳＢ信号はＤ＋、Ｄ−の２線で伝達される差動信号です。
ホストのＵＳＢコネクタからはＤ＋、Ｄ−のほかに、Ｖ＋、ＧＮＤの２線が出ていて、Ｖ＋、ＧＮＤは＋５Ｖで最大５００ｍＡの電源としてデバイス側が使うことができますが、Ｄ＋、Ｄ−信号の電圧は約３Ｖです。
ＰＩＣ１８Ｆ４５５０の内部で、ホストからの受信信号はＤ＋、Ｄ−の差動信号からロジックレベルのシリアル信号を生成し、またホストへの送信信号は、ロジックレベルのシリアル信号をＤ＋、Ｄ−の差動信号に変換してホストに送出します。
●ＵＳＢ Ｓｅｒｉａｌ Ｉｎｔｅｒｆａｃｅ Ｅｎｇｉｎｅ（ＳＩＥ）
ＰＩＣ１８Ｆ４５５０は内部に、ＣＰＵとは別に独立して動作するＵＳＢコントローラ（ＵＳＢ Ｓｅｒｉａｌ Ｉｎｔｅｒｆａｃｅ Ｅｎｇｉｎｅ，ＵＳＢＳＩＥ）を持っています。
このＵＳＢコントローラ（ＳＩＥ）に対して、プログラムによって、必要なパラメータさえ与えておけば、ＵＳＢコントローラ（ＳＩＥ）は、ＣＰＵの動作とは全く関係無く、ホストとの間で自動的にデータの送受信を行います。
この送受信は、［第４２４回］から［第４２７回］で説明をしましたＵＳＢのプロトコルにしたがって、ＵＳＢコントローラ（ＳＩＥ）が自動的にこなしてくれますから、プログラムがそれに携わる必要は全くありません。
［出典］Ｍｉｃｒｏｃｈｉｐ社ＰＩＣ１８Ｆ４５５０ＤａｔａＳｈｅｅｔ
●ＵＳＢＲＡＭ
ＰＩＣ１８Ｆ４５５０は内部に、ＵＳＢの送受信バッファとして利用できる１ＫＢのメモリを持っています。
このメモリはＣＰＵからもＵＳＢコントローラからもアクセスできる「双方向」のメモリです。
その１ＫＢのメモリは任意の範囲だけをＵＳＢバッファとして使うこともまた使わないこともでき、ＵＳＢバッファとして使わない範囲のメモリは、通常のプログラムのワークエリアとして使うことができます。
［出典］Ｍｉｃｒｏｃｈｉｐ社ＰＩＣ１８Ｆ４５５０ＤａｔａＳｈｅｅｔ
●Ｂｕｆｆｅｒ Ｏｗｎｅｒｓｈｉｐ
ＵＳＢバッファとして使う（あらかじめプログラムでそのように定義します）範囲のメモリは、ＣＰＵとＵＳＢコントローラ（ＳＩＥ）が、同時にはアクセスしない仕組みが必要です。
ＣＰＵとＵＳＢコントローラ（ＳＩＥ）がお互いに相手の状況とは全く無関係にＵＳＢバッファをアクセスしたら、めちゃくちゃになってしまいます。
で、ＰＩＣ１８Ｆ４５５０では、そこのところの交通整理をするために、ＣＰＵとＵＳＢコントローラ（ＳＩＥ）の間で「ＵＳＢバッファへのアクセス権」とでもいうべき機能が用意されています。それがＢｕｆｆｅｒ Ｏｗｎｅｒｓｈｉｐです。
そのアクセス権（Ｏｗｎｅｒｓｈｉｐ）の設定は、当然のことながらＣＰＵに優先権があって、プログラムで設定ができるようになっています。
下記引用文の中でＢＤとあるのは、Ｂｕｆｆｅｒ Ｄｅｓｃｒｉｐｔｏｒのことです。ＢＤについてはこのあとの項目で説明をします。
［出典］Ｍｉｃｒｏｃｈｉｐ社ＰＩＣ１８Ｆ４５５０ＤａｔａＳｈｅｅｔ
それほど難しい文章ではありませんから、ぜひ皆様もお読みになってくださいませ。
次の項目で説明するＢＤｎＳＴＡＴレジスタのビット７（ＵＯＷＮビット）を０にする（ｃｌｅａｒ）と、ＢＤとバッファのアクセス権はＣＰＵが所有し（ｉｓ ”ｏｗｎｅｄ” ｂｙ ｔｈｅ ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ ｃｏｒｅ）、ＵＯＷＮビットを１にする（ｓｅｔ）と、アクセス権はＵＳＢコントローラ（ＳＩＥ）が所有します（ａｒｅ ”ｏｗｎｅｄ” ｂｙ ｔｈｅ ＵＳＢ ｐｅｒｉｐｈｅｒａｌ）。
ＵＯＷＮビットが０のときは、ＵＳＢコントローラ（ＳＩＥ）はバッファにアクセスすることができません。
このときはＵＳＢコントローラ（ＳＩＥ）はホストからデータを受け取ることも、ホストに対してデータを送ることもできません。
ここが重要なところです（今回は、ここのところを説明するために、長々と引用をしています）。
つまり、ＵＯＷＮビットを０にして、バッファのアクセス権をＣＰＵが持つようにしている間は、ホストがデータをＷｒｉｔｅＦｉｌｅ（）で送信しようとしても、それを待たせておくことができるわけです。
ＵＯＷＮビットが１のときには、ＵＳＢコントローラがホストからのアクセスに応えて自動的にバッファのデータを送出したり、ホストからのデータをバッファに書き込みます。
ホストとの間でのデータの転送が完了すると、ＵＯＷＮビットは０になります。
ここで注意しなければならないことは、ＵＯＷＮ＝１のとき、つまりバッファのアクセス権がＵＳＢコントローラ（ＳＩＥ）にあるときには、メモリアクセスをブロックする仕組みは働かない（Ｎｏ ｈａｒｄｗａｒｅ ｍｅｃｈａｎｉｓｍ ｅｘｉｓｔｓ ｔｏ ｂｌｏｃｋ ａｃｃｅｓｓ ｗｈｅｎ ｔｈｅ ＵＯＷＮ ｂｉｔ ｉｓ ｓｅｔ）、ということです。
ＣＰＵはそのときでもバッファにアクセスできてしまいますから、たとえばＵＳＢコントローラがバッファにアクセスしているときに、ＣＰＵがバッファの値を読み出そうとしたりすると、不正確な値が読み出されてしまうなどの可能性があります。
ですからＵＯＷＮビットが１である間は、ＣＰＵがバッファをアクセスすることのないようにプログラムする必要があります。
●Ｂｕｆｆｅｒ Ｄｅｓｃｒｉｐｔｏｒｓ（ＢＤ）
エンドポイント毎にバッファアドレスやバッファのサイズ（バイト数）を設定するためのレジスタで、アドレス０４００〜０４ＦＦのメモリに置きます。
エンドポイントあたり４バイトを割り当てますので、最大６４個のエンドポイントを定義することができます。
ＵＳＢのエンドポイントは０〜１５の１６個なのですが、なぜ最大６４個なのかについては、もう少しあとの項目で説明をします。
第１バイト（ＢＤｎＳＴＡＴ）はそのエンドポイントのバッファの状態や性格などを定義する、ステータスレジスタです。
このビット７が上で説明したＵＯＷＮビットです。
第２バイト（ＢＤｎＣＮＴ）はバッファのサイズ（バイト数）です。
ということは、バッファの最大サイズは２５６バイト、ということになりますが、じつは２５６バイトよりも大きいバッファを定義することもできます（最大１０２３バイト）。
その場合のバッファサイズのビット８とビット９はＢＤｎＳＴＡＴレジスタのビット０とビット１を使います（下図ＲＥＧＩＳＴＥＲ１７−５のＢＣ８とＢＣ９）。
あれ？
でもＰＩＣ１８Ｆ４５５０のＵＳＢバッファメモリは、このＢＤ定義エリアの０４００〜を含めても、０７ＦＦまでの１０２４バイトしかありませんから、実質的には、１０２３バイトのバッファを使うことは不可能のようです。
まあ、でも、私の場合には、ＨＩＤでの使用が前提ですから、そうするとバッファサイズは６４バイトですから、バッファが足りなくなることはありません。
第３バイト（ＢＤｎＡＤＲＬ）はバッファの下位アドレスで、第４バイト（ＢＤｎＡＤＲＨ）は上位アドレスです。
［出典］Ｍｉｃｒｏｃｈｉｐ社ＰＩＣ１８Ｆ４５５０ＤａｔａＳｈｅｅｔ
●ＢＤｎＳＴＡＴ
ＢＤｎＳＴＡＴのビット７（ＵＯＷＮ）を０にすると、ＢＤとＵＳＢバッファのアクセス権をＣＰＵが所有します。
そのときのビット６〜ビット０が示す意味は、ビット７（ＵＯＷＮ）が１のときにビット６〜ビット０が示す意味とは別の内容になります。
こちらがＵＯＷＮ＝０（ＣＰＵモード）のときのＢＤｎＳＴＡＴです。
［出典］Ｍｉｃｒｏｃｈｉｐ社ＰＩＣ１８Ｆ４５５０ＤａｔａＳｈｅｅｔ
こちらがＵＯＷＮ＝１のときのＢＤｎＳＴＡＴです。
［出典］Ｍｉｃｒｏｃｈｉｐ社ＰＩＣ１８Ｆ４５５０ＤａｔａＳｈｅｅｔ
各ビットの意味については、説明が深くなりすぎますから、ここでは省略いたします。
いずれそのうち詳しく説明するときもあるかと思います。多分ですけれど。
●エンドポイントバッファが最大６４個の意味
ＵＳＢのエンドポイントは０〜１５の１６個なのですが、なぜ最大６４個なのかについての説明です。
エンドポイントは、それぞれにＩＮ（ホスト←デバイス）とＯＵＴ（ホスト→デバイス）を分けて定義することもありますから、その場合には３２個になりますし、さらにそれぞれをＤＡＴＡ０とＤＡＴＡ１に分けてバッファを用意するとした場合には６４個のバッファを使うことになります。ですから最大６４個になります。
簡単に説明をするだけのつもりだったのですが、毎度のことで、結構深くなってしまいました。
２０１０．４．２１ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る