●受信ＥＲＲＯＲ
一般にパソコンなどで使われるＲＳ２３２Ｃ通信は調歩同期式といわれる方法です。
英語ですとａｓｙｎｃｈｒｏｎｏｕｓという言葉になります。
これですと非同期という意味になります。
うう。
では調歩同期式つうのは、いったい同期なのか非同期なのか？
その昔、はじめてＲＳ２３２Ｃなるものに出会ったときは、大いに迷ったものです。
同期式というからには、送信側と受信側に共通のクロック信号があって、さらにデータの始まりを示す信号などがあって、これに同期してデータを送るから、同期式なのでしょう。
当然、非同期というからには、共通のクロック信号は使いません。
正式のＲＳ２３２Ｃ通信ではデータラインＴＸＤ、ＲＸＤのほかにもＣＴＳ、ＲＴＳ、ＤＳＲ、ＤＴＲなど多くの制御線を使います。
しかし一般的なパソコン同士のＲＳ２３２Ｃ通信などではそれらの制御線は省略してしまって、データ送信（ＴＸＤ）、データ受信（ＲＸＤ）とＧＮＤの３本の線だけで通信を行います。
もしもこちらが送信だけで、相手が受信だけというシステムならば、こちらのＴＸＤと相手のＲＸＤを接続して、ＧＮＤを共通にするだけでデータの送信ができてしまいます。
８ビットのデータを１ビットのシリアルに変換して送信するわけですから、データの始まりを示すマークがないことには、受信側で正しく元のパラレルデータに復元することはできません。
そこで、データが送信されていない状態のときは、データラインを１（Ｈ）にしておいて、データを送るときには、データの前に１ビットの長さの０（Ｌ）を送ります。
これがスタートビットです。
受信側はこのスタートビットの立下りに同期してデータを受け入れます。
しかし、もしも８ビットのデータの最後が０（Ｌ）であったとすると、その最後の０とスタートビットの０との境がわからなくなってしまいます。
そこでデータの終わりには、１～２ビットの長さの１（Ｈ）を置きます。
これがストップビットです。
このようにすることで、８ビットのデータを受信し終わると、必ずストップビットが来ますから、そこで次のデータのスタートビットを待つことができます。
送信側と受信側のクロックに多少の差異があっても、８ビットのデータを受信する期間内では、その差異が誤差の範囲内に収まるならば、次のスタートビットの立下りでそのズレは解消されますから、受信側で正しく受信データを復元することができます。
調歩同期という名前は、おそらくスタートビットで足並みを揃えることで同期を取る、ということから名付けられたのではないか、と思います。
ａｓｙｎｃｈｒｏｎｏｕｓ（非同期）という名前からは、スタートビットで足並みを揃えるという意味は伝わってきません。
いまどきはなんでもかんでも横文字のまま輸入してしまいます。
おそらくアジアでもっとも英語が苦手な国民でしょうにねえ。
そこへいくと我々の先輩達は実にまじめで賢くそしてかつ勤勉でありました。
たったひとつの外国語でさえ、実に丁寧に日本語（実はたいていは漢字なのですが）に翻訳する努力を惜しみませんでした。
調歩同期式のＲＳ２３２Ｃデータ信号については、ＣＰＵをつくろう！［第１８８回］のあたりで説明をいたしました。
そこでの説明図をちょっと引用しましょう。
文字ＡのＡＳＣＩＩコード（４１）の送信波形の説明図です。
４１は、０１０００００１です。
そのようにビットで表現するときは一般にビット７が左で、ビット０が右になるように表記します。
しかしＲＳ２３２Ｃで送信するときの波形は、その表記とはちょうど正反対になります。
ビット０から送信するからです。
●フレーミングエラー（ｆｒａｍｉｎｇ ｅｒｒｏｒ）
またまたえらく前書きが長くなってしまいました。
調歩同期式がそのようなデータの同期方式であることがわかりますと、受信エラーについても自然に理解ができるようになります。
通信時にたまたま信号ラインに強力なノイズが乗ってしまったためにエラーが発生するというようなことも考えられますが、調歩同期式で普通に通信しているときには、突発的なエラーを検出することはできません。
そのようなエラーを検出するためには、パリティビットを追加して９ビットのデータにして送信するとか、データ全体を加算してチェックサムを照合するなどの対策を取ります。
ＰＩＣ１８Ｆ１４Ｋ５０のＲＳ２３２Ｃ受信でハードウェアが検出する受信エラーは、もっと根本的なものです。
たとえば送信側が４８００ボーで送信しているのに、受信側の設定が９６００ボーであったとすると、結果はどうなるでしょう？
おそらくまともに受信できそうにない、ということは容易に想像がつくと思います。
さきほどの送信波形の図で説明をしましょう。
送信側は４８００ボーなのに受信側が９６００ボーの設定になっていたとすると、上の図の上側の波形が送信波形のとき、受信側の信号のタイミングは下の波形で示されます。
ビットの長さがちょうど半分になります。
そうすると受信データは、ビット０から順に、０１１０００００になりますから、送信データの４１だったものが、０６に化けてしまいます。
このとき最後のストップビットのところを見ますと、０（Ｌ）になっています。
調歩同期式のルールではデータの最後は必ずストップビット（Ｈ）が来るはずなのですが、それがありません。
これは明らかに信号に異常があることになりますから、このとき受信エラービットがＯＮになって、受信が打ち切られます。
これがフレーミングエラー（ｆｒａｍｉｎｇ ｅｒｒｏｒ）といわれるエラーです。
決められたワク（ｆｒａｍｅ）から逸脱している、という意味でしょう。
これも容易に想像できますように、送信側と受信側とでボーレートが異なっていても、たまたまストップビットの位置に１（Ｈ）が検出されればエラーにはなりません。
まあ、送信するデータの全てがそのようにたまたまストップビットの位置が１（Ｈ）になっている、などということは滅多にあることではありませんが、送信するデータ数が少ないときなどですと、ひょっとするとエラーにならないで受信が完了してしまうかもしれません。
エラーにはならなかったとしても、当然受信したデータは元の送信データとは異なったものになってしまいます。
●オーバーランエラー（ｏｖｅｒｒｕｎ ｅｒｒｏｒ）
ＰＩＣ１８Ｆ１４Ｋ５０のＲＳ２３２Ｃ受信で発生するエラーには、フレーミングエラーとは別のエラーがもうひとつあります。
オーバーランエラーです。
ＰＩＣ１８Ｆ１４Ｋ５０のＲＳ２３２Ｃ受信では、受信バッファに２バイトのデータを置くことができます。
あ。
この受信バッファは私がプログラムで設定した割り込み受信のデータバッファのことではなくて、標準でハードとして内蔵している受信バッファのことです。
ＰＩＣ１８Ｆ１４Ｋ５０は、ＲＳ２３２Ｃ受信データを２バイトのＦＩＦＯ受信バッファに格納します。
格納された受信データはプログラムによって速やかに引き取らなければいけません。
もしプログラムが受信バッファのデータを引き取るのが遅れて、そこに３バイト目のデータが受信されてしまうと、もう受信データの置き場がありません。
このときオーバーランエラービットがＯＮになって、受信は打ち切られます。
●受信ＥＲＲＯＲ信号
フレーミングエラーもオーバーランエラーも、これはもうあってはならないエラーですから、必ずＺ８０ＣＰＵ側に伝えなければなりません。
そこでエラーの発生を伝えるために独立した１本の出力ラインを割り当てました。
ＭＹＣＰＵ８０ではその出力にＬＥＤをつないでいます。
この回路図は［第８７回］でもお見せしたＮＤ８０ＺⅢのＩ／ＯインターフェースのうちのＰＩＣ１８Ｆ１４Ｋ５０を中心にした部分の、さらにその一部のみを切り取って示したものです。
ＰＩＣ１８Ｆ１４Ｋ５０のＲＣ４（ｐｉｎ６）がＥＲＲＯＲ信号出力です。
当初はエラーが発生したら、このラインの出力をＬにする、というだけのものでした。
エラーインジケータのようなものです。
しかしその後に、Ｚ８０ＢＡＳＩＣでＲＳ２３２Ｃ受信プログラムを書いて、その動作テストをしているときに、受信エラーが発生したのですが、そのときはただＢＡＳＩＣの受信エラーを示すコードが表示されるだけでしたから、そのエラーがどういうエラーなのかがわからなくて、その原因を特定することができませんでした。
そこで、そのエラーの原因を特定するために、それまでは受信エラーが発生したときに、ただ受信ＥＲＲＯＲ信号が出力されるだけだったものに、少し手を加えて、エラーの内容もわかるようにＰＩＣ１８Ｆ１４Ｋ５０のプログラムを変更しました。
そのあたりの経緯につきましてはＣＰＵをつくろう！［第５６９回］に書きました。
受信エラーが発生したときに、受信ＥＲＲＯＲ信号を出力するだけではなくて、そのときにはどうせ受信データは使い物にはなりませんから、受信データの代わりに、エラービット情報も出力するように変更したのです。
ＰＩＣ１８Ｆ１４Ｋ５０のＲＳ２３２Ｃ受信時のエラー情報は、ＲＣＳＴＡレジスタのビット１、ビット２にセットされます。
［出典］ＭＩＣＲＯＣＨＩＰ社ＰＩＣ１８Ｆ１４Ｋ５０ＤａｔａＳｈｅｅｔ
ｂｉｔ１がオーバーランエラーで、ｂｉｔ２がフレーミングエラーです。
ＰＩＣ１８Ｆ１４Ｋ５０がＺ８０ＣＰＵに受信エラーが発生したことを知らせるために、受信エラー出力をＬにするとともにデータとして出力することにしたエラー情報は、ＲＣＳＴＡのエラービットと同じにしました。
すなわち、
オーバーランエラーのときは、データとして０２（００００００１０）を出力し、
フレーミングエラーのときは、データとして０４（０００００１００）を出力することにしました。
ＣＰＵをつくろう！第５９１回（２０１０．８．２４ｕｐｌｏａｄ）を再編集
ワンボードマイコンをつくろう！［第８９回］
２０１１．７．４ｕｐｌｏａｄ
前へ
次へ
目次へ戻る
ホームページトップへ戻る