平成27年 8月 7日
汎用の高速シリアル通信機能(4) 通信の基本的手続き(3)
RS-485による半二重通信の高速化について検討しています。基本的な通信のアイデアとエラーの検出までは目処が立ちました。
次は実際にエラーが起きたときにその状態から復帰させる方法を考えます。ここで最優先することはマスタ・スレーブのどちらでエラーが起きた状態であっても統一した方法でエラーから復帰できることです。マスタ・スレーブ共に通信途中の状態を保持する複数の内部変数があるでしょうから、これらを同じタイミングでクリアする方法を検討します。
（３）エラーからの復帰方法
タイムアウトを利用する方法や特定のリセットコマンドを送る方法などを検討しましたが、最終的にはマスタからスレーブに対して単独のBreak信号を送ることでエラー復帰要求とすることにしました。Break信号はマスタおよびスレーブからの送信の終了を示す時にも使用しますが、エラー復帰要求ではBreak一文字のみを送信します。スレーブではもしBreak受信以前にそれ以外の文字が受信されていれば、それはエラー復帰要求ではなく通信とみなします。
もう少し具体的に書くと、次のようになります。
(Ｈ27/10/ 7訂正)
訂正箇所が複数になるので訂正文書を一本線で消して、その後に訂正後の文書を追記します。
- マスタはリセット要求が必要となった段階で、スレーブからの返信データが途切れるのを待ちます。このときの待ち時間は通信切り替え時のタイムアウト時間です。ここでももし途中で一文字でも受信データが帰ってくれば、その時点からタイムアウトとなるまで待ちます。既に送信が途切れてタイムアウト時間以上送信がない状態であれば直ちに次の動作に移ります。
- 単独のBreak信号を送信します。
- その後、通信切り替え時間だけ待って再度単独のBreak信号を送信します。
手順の意味は、マスタは半二重通信が確実に送信可能になっているのを確認して最初のBreak信号を送信します。しかし、通信の直前にどのような送受信が行われていたのかは想定できないので、最初のBreak信号が通信の終わりを示すものと誤認されても問題が無いように二度目のBreak信号を送信します。二度目のBreak送信の前に通信切り替え時間だけ待つのには深い意味は無く、デバッグなどの時に多少は確認しやすいだろうという程度です。 手順の意味は、マスタは半二重通信が確実に送信可能になっているのを確認して最初のBreak信号を送信します。
通信エラーはそれ程起きるものでもないので、ここでは速度よりも分かり易さ・管理しやすさを優先しています。
（４）受信バッファの管理
通信でもう一つ気を使うのが受信バッファのクリアタイミングです。特にスレーブ側は基本的には常時受信している状態です。しかし、受信バッファは有限長ですので、どのタイミングかで受信バッファをクリアする必要があります。基本的には一つの受信が終わったタイミングで受信データを処理してクリアするのが最も安全です。この場合、受信完了から受信データの処理・受信バッファのクリアまでの処理は次の受信開始(他の装置が送信を開始するまで)までに終わっていることが条件になります。
取り決めた通信仕様からある送信が終わった後に次の送信が始まるまでの待ち時間は、通信方向切り替え時間です。標準で100usを予定しています。この時間以内に確実に処理を終わらせるためには、受信データの処理および受信バッファのクリアまでを割り込み処理内で行うことが必要です。従ってスレーブ側では、そのようにします。
対してマスタ側では、常時受信する必要は無く、受信の期間は自分である程度制御できる自由度があります。このため、受信バッファのクリアタイミングはあまり問題になりません。ただし、マスタ側は一般的にスレーブに比べて多くの処理が必要になります。このため特に割り込みリソースを無駄に使いたくありません。他の処理のために出来るだけ空けておきたいのです。通信データの処理に関しても出来れば割り込み処理内では無く、メイン側で処理を行うことを考えます。こうすると、あるスレーブから受信が出来たとしてもそれをすぐに処理することは困難です。とても100usを目標としている通信方向切り替え時間以内には収まりません。このため受信バッファの処理および受信バッファのクリアは個々のスレーブから受信完了したタイミングに同期させず、一連の通信全体で処理することを考えます。つまり、マスタ側では全スレーブからの受信データを一度に受信できるだけの容量を確保し、受信できたスレーブ毎に少しずつ処理します。マスタ側では受信バッファのクリアは全てのスレーブからの応答を受信してその処理が終わったタイミングで行います。この仕様では、スレーブの数が増えるとマスタでの受信バッファが大きくなりすぎる問題があります。スレーブの数は仕様上は100以上可能ですが、実用的には数〜十数個までになります。
（５）通信効率
実用上の通信速度を決める要素として、送信開始タイミングの検出方法があります。通信仕様から送信を始める前に通信方向切り替え時間だけ待つ必要があります。この待ち時間をソフトウェアによるポーリングで待った場合には、その待ち時間は大きく変動します。通信速度は制御システム全体のボトルネックになり易いので、この待ち時間の変動は無視できません。このため全体として送信回数の多いスレーブ側ではこの待ち時間を専用タイマ割り込みを使って管理します。スレーブ側は比較的ハードウェアのリソースにも余裕があることが多いと考えられます（もし足りなくなるようならPLDででも使って追加することを考えます）。これでスレーブ側での変動幅は非常に小さく出来ます。
マスタ側では、専用タイマを用意しないことにします。PIC32には全部で5個の16ビットタイマがありますが、一般的にOS用や汎用の時間管理のためにタイマを一つ使います。通信のためにもう一つ使うと残りは3個です。出来るだけアプリケーション用にリソースを残しておきたいのです。
とはいえ処理内容の多い（=タスク数が多い）マスタ側で従来どおりのポーリングを行うとなると待ち時間の変動は非常に大きくなりますので、、この部分はタスク管理機能で待ち時間の変動幅が小さくなるような工夫を行います。詳細は時期を見て説明しますが処理タスク数の増減に関係なくタスク1個分の処理時間が待ち時間の変動幅となります。一般的な組み込み処理では各タスクの一回あたりの処理時間はそれ程長くはなりません。数十〜百数十us程度です。