(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第１８５回］
●またもや、思わぬトラブルが…
前回、ハイパーターミナルを使って、テストプログラムを送信し、実際にそのプログラムを動作させているところの写真をお見せしました。
やっとこれでＡＬＵ回路のうちの、論理演算回路の説明が完了し、いよいよこれから、ＡＬＵ回路の残り、算術演算回路の説明にとりかかります…。
のはずだったのですが、またしても、思わぬトラブルが発生してしまいました。
前々回、［第１８３回］で、ハイパーターミナルを使っての２３２Ｃ送信について、無事送信テストＯＫ、と書きましたが、じつはスンナリとＯＫになったのではなくて、当初、送信エラーが発生していたのです。
いろいろ試みるうちに、エラーが出なくなってしまったので、とりあえずは、それでいいか、と思ったのですけれど。
いやいや、やっぱりあいまいにしておくのはよくないぞ。
と思いなおして、あらためて追求してみることにしたのです。
そうしたら、まあ、なんと、とんでもないことが発覚してしまいました。
まあ、ほんとに、好事魔多しといいますか、いやいや好事どころか、そもそも、今年は最初からついていなかった。
これは、きっと、魔物の仕業に違いない。
●サスペンス劇場…衝撃の結末？
調べていくうちに知ってしまった、予想だにしなかった、衝撃の結末とは？
サスペンス劇場の始まりです。
［第１８３回］で書きましたように、ハイパーターミナルを使うのは初めてです。
そこで、まずは簡単な送信テストをしてみることにしました。
送信先は今回製作した「つくるＣＰＵ」試作基板ではなくて、当社のＢＡＳＩＣボードです。
いつも製品の動作テストで、２３２Ｃ受信テストに利用しているボードです。
使い慣れているものを使ってテストするのが一番です。そう思って試してみたのです。
これは、なんなくＯＫになりました。
おお。ハイパーターミナルも、けっこう使えるじゃないか。
これなら、楽勝だ。
と思って、いよいよ本番。
「つくるＣＰＵ」試作基板あてに送信テストです。
そうしたら…。
●２３２Ｃ送信でエラー発生
あれっ？受信エラー…？
じつは、こういうこともあろうかと、ＰＩＣからの出力端子の１本をエラー出力にして、そこにＬＥＤをつけるようにしておいたのです。
すると、ハイパーターミナルからテストプログラムを送信したところ、途中まで受信するとエラーＬＥＤが点灯して、そこで停止してしまうではありませんか？
まさか？
ＵＳＢ−２３２Ｃ変換コネクタでテストしたのですが、念のため、ＤＳＵＢ９ｐｉｎ同士、２３２Ｃケーブルを使ってｃｏｍ１でも試してみました。
結果は全く同じです。
何度試みても、同じアドレスまで受信すると、エラーで停止してしまいます。
最初、ＢＡＳＩＣボードで受信テストをしたときには、エラーは発生しなかったのに…。
もう一度、ＢＡＳＩＣボードにつないで、送信してみました。
こちらだと、エラーにはなりません。
当然の結論として、これは、ＰＩＣの側の問題だ。
最初は、ＰＩＣが受信したデータをＣＰＵに渡している間に次のデータが来てしまうために、それを落としてしまう、「オーバーランエラー」かと思いました。
ここで、お勉強です。
●オーバーランエラーとは？
ＰＩＣには受信バッファが２バイト分あって、シリアルデータが送られてくると、プログラムの実行とは関係無く、バックグラウンドでハード的に、そのデータを受信バッファに取り込みます。
受信回路は、シリアル受信したデータがちょうど１バイトそろったところで、「受信データがきましたよ」というフラグをたてて知らせます。
あ。今回は２３２Ｃ受信にＰＩＣを使いましたから、ＰＩＣの動作として説明していますが、「オーバーランエラー」はＰＩＣだけの用語ではありません。シリアルデータ受信時のエラーの１種です。
話をもとに戻します。
プログラムの側で、このフラグを見ていて、フラグが立ったら、受信バッファからデータを引き取ります。
この処理を、フラグ発生をトリガとして、割り込みで行う場合には、問題はおこりにくいのですが、そうではなくて、普通のプログラムでフラグの状態を、他の処理の合間にときどき見るようにしていたり、割り込みでも、割り込みを禁止している期間が長すぎたりしていると、データを引き取るのが遅れて、その間に次のデータが到着してしまいます。
ＰＩＣの場合、受信バッファは２バイト分ありますから、１バイト分だけなら遅れても、エラーにはなりません。
しかし、他の処理に時間を取られてしまい、データを引き取るのがさらに遅れたりすると、バッファに２バイト分のデータが残っていて、バッファフルの状態なのに、そこに次のシリアルデータが到着してしまいます。
でも、それを受け取るスペースは、もうありません。
受信回路は、「もう、だめですぅ」というフラグを出します（だから、早く引き取ってよー、って知らせたのにぃ。恨み節です）。
これが、オーバーランエラーです（早く引き取らなかった、アンタが悪い。ワタシのせいじゃぁ、ないもん）。
オーバーランエラーはタイムアウトになってから出ますから、時すでに遅し、です。
フラグをクリアして、最初から受信をやり直すしかありません。
余談になりますが、オーバーランを防ぐ方法はあります。
最も簡単な方法は、送信してくる相手に、「受信バッファがいっぱいだから、今はもう送らないでよねー」ということを、ハードウェア的に知らせることです。
一般的には、ＲＳ２３２Ｃの制御線のうちの、ＲＴＳ（ｒｅｑｕｅｓｔ ｔｏ ｓｅｎｄ）とＣＴＳ（ｃｌｅａｒ ｔｏ ｓｅｎｄ）を使います。
装置によっては、それに加えてＤＴＲ（ｄａｔａ ｔｅｒｍｉｎａｌ ｒｅａｄｙ）とＤＳＲ（ｄａｔａ ｓｅｔ ｒｅａｄｙ）を使うこともあるようです。
互いのＲＴＳとＣＴＳ、ＤＴＲとＤＴＳを接続することで、送信側と受信側のハンドシェイクが出来て、オーバーランエラーを防ぐことができます。
これらの信号をそのように接続することは、正式のＲＳ２３２Ｃのルールにはないことのようで、パソコンの普及に伴って、アマチュア規格的に広まっていったのではないか、と思われます。
ですから、装置によっては、そのような接続になっていないものもあり、接続に際しては、取扱説明書をよく確認する必要があります。
ところで、「つくるＣＰＵ」のＲＳ２３２Ｃ回路には、ＲＸ（ＲｘＤ）とＴＸ（ＴｘＤ）しかなくて、ＲＴＳ、ＣＴＳ、ＤＴＲ、ＤＴＳはありません。
それじゃあ、どうするの？
といいますと、こちら側で、ＲＴＳとＣＴＳ、ＤＴＲとＤＴＳをつないでループにしてしまうのです。
下図はＲＳ２３２Ｃの９ｐｉｎＤＳＵＢコネクタです。
ＤＯＳ／Ｖパソコンについているオス型コネクタを外側から見た図です。
下図は「つくるＣＰＵ」基板の２３２Ｃコネクタ〜ＰＩＣの間の回路図です。
コネクタ端子名はパソコン側に合わせてあります。
（この回路図は、ストレートケーブルでの接続をするように、訂正したあとの回路図です）
図のようにＤＴＲ−ＤＳＲ、ＲＴＳ−ＣＴＳをつないでおくと、受信側から送信ストップの信号を送ることはできませんが、ＲｘＤ、ＴｘＤ、ＧＮＤの３本のラインだけでデータの送受信を行うことができます（今回のように、パソコン→試作基板の向きの送信だけならば、ＴｘＤとＧＮＤの結線のみで済みますから、回路が簡単になります）。
その代わりにオーバーランの可能性がゼロではなくなります。
しかし、その可能性は、今回の試作基板では、ちょっと考えられない、のですよ、ねぇ。
なんたって、２４００ボーですから…。
●いくらなんでも、オーバーランエラーはありえない…
厳密な言葉の定義によると、ボーレートとビット／秒とは異なる、と何かの解説で読んだ気がしますが、でも計算上はそうなります。
２４００ボーは１秒間に２４００ビットを送信する速度と考えて間違いありません。
１バイトのデータにスタートビットとストップビットが加わりますから、ちょうど１０ビットになります。
２４００ビット／秒ということは、すると、２４０バイト／秒ということになります。
いまどきそれはちょっと遅いのじゃないの？といわれてしまいそうですが、何も１０ＫＢや２０ＫＢもあるデータを送信しようってんじゃありません。
大きくても、せいぜい１ＫＢか２ＫＢのプログラムです。
２ＫＢだって１０秒もあれば終わってしまいます。
それよりも、データを受信してアドレスを表示するＬＥＤがカウントアップされていくさまを眺めているほうが楽しいじゃありませんか。
もう季節も春なのですから、そんなにあくせくしないで、のんびりローカル線の旅を満喫しましょうよぉ。
え？何のお話でしたっけ？
そうそう、そうでした。オーバーランのお話でした。
さきほども書きましたように、ＰＩＣは受信バッファを２バイト分持っています。
また、今回の受信プログラムでは、ＰＩＣはＡＳＣＩＩコードで受信した２バイトのデータを１６進数１バイトのデータに直してから、ＣＰＵに渡します。
当然その換算もＰＩＣが行っているのですが、それにしてもそれほど時間がかかるとは思えません。
２バイトのデータを受信するのにかかる時間は、約８．３ｍｓｅｃです（１／２４０×２）。
いくらなんでも、ＡＳＣＩＩ→１６進変換や、ＣＰＵへのパラレルデータ送出に、ミリ秒はかかりませんよぉ。
すると？
残る可能性は、フレーミングエラーかぁ？
●フレーミングエラーとは？
フレーミングエラーとは、シリアル伝送経路のノイズや線路の遅れ、またはボーレートの設定ミスなどで、規定時間内にストップビットが受信できなかったり、逆にスタートビットが早く来すぎてしまった場合に発生します。
下図は２３２Ｃで、１バイトのデータを送るときのビットデータの様子を模式的に示したものです。
文字”Ｃ”のＡＳＣＩＩコード、４３（１６進数）、２進数では０１００００１１を送信するときの例です。
図のように、最初にスタートビット（１ビットの０）を送り、それからデータをビット０からビット７の順に送ります。
最後にストップビット（ふつうは１ビットの１）を送ります。
受信側はスタートビットの下がりエッジから半ビット過ぎたところから、データのサンプリングを開始します。
それからビット長時間毎にサンプリングし、最後のストップビットのサンプリングで、１バイトのデータの受信を完了します。
最後のストップビットのサンプリングのときに、図の中または下のように、１ではなくて、０が検出されてしまうと、フレーミングエラーになります。
うむむ。
と、とりあえず、ストップビット長を２ビットにしてみよう…。
ハイパーターミナルの設定を変更して、通常１ビットを送るストップビットを２ビットの長さにしてみました。
そうしたら…。
エラーが出なくなってしまいました！
いやぁ。よかった、よかった。
これにて、一件落着。
●でも、それって、おかしくね？
ストップビットを長くするっていうのは、本来は、オーバーランエラー対策のはず。
ストップビットでこける、ということは、その前のビットでも、かなり危ないということになりませんかぁ。
とするならば、ストップビットを長くして、たまたまフレーミングエラーにならなくなったとしても、データの信頼性は、相当に低くなってしまうはず…。
ううう。
ここは、やっぱり、もう少し追求しておかなくては。
ＰＩＣはクリスタル発振ではなくて、内部発振回路によって、４ＭＨｚクロックで動作させています。
もっと高いクロック（８ＭＨｚ）にもできるのですが、むやみに速くしなくたって、このくらいで十分、と思ったので、そうしたのです。
うむむ。
さては、ボーレートの誤差か？
ＰＩＣ１６Ｆ８８のデータシートで確認してみました。
［出典］Ｍｉｃｒｏｃｈｉｐ Ｔｅｃｈｎｏｌｏｇｙ Ｉｎｃ．ＰＩＣ１６Ｆ８８ｄａｔａｓｈｅｅｔ（赤四角は筆者）
今回はクロック４ＭＨｚで２４００ボーに設定しましたから、表で見ると、誤差は＋０．１７％ということになっています。
０．１７％…？
つうことは、スタートビットから１０ビット目でも、誤差はせいぜい１．７％…。
あかん。この線は、完全にシロや。
どうころんだって、これじゃあ、半ビットもズレるのは、どだい無理な話だ。
ホンボシはどこかほかにいる！
ううっ。まてよ。クロックが外付けの水晶発振じゃなくって、内部発振？
そ、それだっ！もう、それしか、ないっ！
ホンボシは、きっとそいつだぁぁ。
［出典］Ｍｉｃｒｏｃｈｉｐ Ｔｅｃｈｎｏｌｏｇｙ Ｉｎｃ．ＰＩＣ１６Ｆ８８ｄａｔａｓｈｅｅｔ
８ＭＨｚだなんて、もっともらしいことを言っているようですが、だまされちゃいけませんぜ、警部。
こいつぁ、きっと、いいかげんにきまってまさぁ。
２００９．３．１６ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る