平成27年 5月 15日
割り込み待ち時間の設定に関して
RS-485によるブロック通信では、時間の大半が割り込みの受付待ち時間になります。
これ以上の高速化を考えるなら、幾つかの方向性があります。これについて少し考えてみます。
１．割り込みの受付待ち時間を減らす
割り込みが発生してから実際の処理が始まるまでの最悪値を短くすることを意味しています。
今回の検討主題はこれですが、それ以外を先に片付けることにして後回しにします。
２．割り込み待ちと通信をオーバーラップさせる
ＵＳＡＲＴのＦＩＦＯを使った通信ではＦＩＦＯの段数と割り込みの受付条件が割り込みの発生回数に直接関係しています。しかし、これは「ハードウェアの仕様」である以上変えることは出来ません。従って現在の方向では高速化は困難です。
別の方向性として、通信と割り込み待ち時間のオーバーラップが挙げられます。現在の方法では通信時間は非常に高速ですが、通信時間が短くなっても結果として通信終了後に待ち時間を置いているため、速度的なメリットはありません。なら、通信速度を落として、通信中に受信処理を行うなら、最終的な通信速度を稼ぐことが出来る可能性が出てきます。
具体的には、受信側では8段あるＦＩＦＯの内4段＋シフトレジスタ1段の5段分を受信待ち時間に割り当てます。つまり、割り込み要求はＦＩＦＯが半分の4段を受信した段階で発生するように設定します。この場合には5文字分の割り込み待ち時間を確保できます。この方法では通信速度が高速になるにつれて割り込みの発生タイミングを早める必要が出てきます。
この方法の欠点
この方法では通信速度の選択が困難です。通信速度は過去の歴史から9,600ｂｐsの倍数が標準です。ある程度の高速を望むなら57,600bps,
115,200ｂｐｓ, 230,400bpsの３つが現実的な選択肢です。このとき、上記のように5文字分の割り込み待ち時間を確保したとすると、
57,600bpsではおよそ520us
115,200ｂｐｓではおよそ260us
230,400bpsではおよそ130us
となります。230Kｂｐｓでは割り込みの応答時間を130usまで短くする必要があり、これは現実的ではないでしょう。メイン側で割り込みを禁止している時間と他の割り込み処理の時間を考えると非常に厳しい数字です。
選択肢としては115Kｂｐｓが最有力になります。それでもＵＳＡＲＴに対する割り込みの優先度を他の割り込みより上げておいた方が良いでしょう。割り込み待ち時間の検討では更に安全な57Kｂｐｓですが通信速度的にやや不満が残ります。
実は当初この方法を検討していたのですが、性能的な限界が100Kbps付近に出来るので取り止めました。今回採用したＦＩＦＯと高速な通信では工夫次第ではもう少し上まで実効的な通信速度を稼ぐことが出来ます。
３．ＤＭＡにより割り込み回数を減らす
通信の途中でＣＰＵに関与してもらうためには、どうしても割り込み待ち時間が必要になります。なら通信のパケットを大きくして一度に多数のデータを送受信すれば良い。これならＣＰＵの関与する回数を減らすことが可能です。この方向ではＤＭＡによる方法が可能です。通信文字数を32バイトや64バイト程度に大きく取り、通信速度を1Mbpsや2Mbpsといった程度まで高速化すれば非常に高速な通信が行えます。例えば1スレーブ(基板)に対する通信コマンドを複数個まとめて送るなどの工夫をすれば一回の送受信で必要な通信を完了できるでしょう。
現時点では、速度の必要な通信用途にはこの方法を考えています。
以上見てきたように、割り込みが発生してから実際の処理が始まるまでの待ち時間は、組み込み装置にとって非常に重要です。特にその最悪条件での時間が割り込み処理全体の性能を決めてしまいます。
ところが、この最悪条件を見極めるのは非常に困難です。具体的な実例を挙げながら見てみます。
１．メイン側（割り込み処理以外）での割り込み禁止時間の最大値を知ることは非常に困難
個々の割り込み処理ルーチンの処理時間は比較的簡単に測ることが出来ます。理由は処理の開始位置が固定されているためです。対してメイン側では、割り込みを禁止する必要がある処理は各所に散らばっています。それら全てに対して処理時間の計測を埋め込む必要があります。
更に、他社が作ったＯＳやライブラリを使用するなら、内部で何をやっているかは全く分かりません。メーカーに問い合わせして返事が返ってくれば良いですが最悪値は保障してくれないか、非常に大きな保障値を示されることが大半です。
２．割り込み処理の性質が異なるものが増えてきた
ＵＳＡＲＴやＳＰＩといった旧来型のＩＦは比較的単純なので、割り込み処理を含めた全体を一人で管理できます。しかし、近年のＩＦは非常に複雑化しています。ＵＳＢ、ＣＡＮ，イーサネットはその代表格です。これらはＩＦ内部にコントローラを内蔵し、自身で通信の大半を処理します。おかげで割り込みの応答性に対する要求は穏やかです。しかし、その分割り込み処理を含めた全体のプログラムは複雑で、全てを自力で書き上げるのは困難です。どうしても第三者のコードを流用するか他社のプログラムを採用することになります。
となると、割り込み処理の応答性が重要な旧来のＩＦと新しいＩＦが一緒に動作する環境では、その応答性を確認しておく必要が出てきます。処理時間が長く掛かるようなら、旧来型のＩＦとは割り込みの優先度を変えて、処理が遅れないようにします。
今回、この文書を書くにあたってＭＰＬＡＢ ＨａｒｍｏｎｙのＵＳＢライブラリの割り込み処理時間を実測してみました。
測定条件は
・ＣＰＵはＰＩＣ32MX795(CPU, PBCLK共に80Mhz)
・ＸＣ32 Ｃコンパイラ最適化は禁止
・MPLAB Harmony Ｖer．1.00 USB_CDC_Dualプロジェクト（メイン側の処理のみ一部変更）
測定結果は割り込み処理時間の最大値でおよそ65usでした。
この値には割り込みによるレジスタの退避・復帰処理などは含まれないので、全体としては70us以下程度と考えたほうが良いでしょう。
同時にUSBライブラリの中でCDC機能から使用するファイルについてのみ割り込み禁止の処理が行われていないかを調べてみました。USBに対する割り込み禁止処理はありますが、グローバルな割り込み禁止処理はありません。
ＵＳＢに関しては割り込み処理時間はやや長いものの、それ程神経質になる必要はなさそうです。ただし、複数のUSARTを使用するならUSARTに対する割り込み優先度はUSBやタイマとは別に分けておいたほうが良いでしょう。その分、割り込み処理の応答性がよくなります。
そのようにしても割り込み待ち時間としては、最低でも200us程度は確保しておいたほうが良い。プログラムは常に変更されていきます。その時点でギリギリの調整はすべきではない。
次は、今回の実験に使用したUSBに関して書いていきます。MPLAB Harmonyのルールに則ってプログラムを書くのではなく、MPLAB Harmonyのドライバ機能をライブラリにして、自作のプログラムにリンクする方法を書いていきます。