組込み徒然草

前回の記事にコメントをいただきました。

関心を持ってコメントいただき、ありがとうございました。

さて、少し認識の違うところがあると思います。

一番大きな認識の違いは「割り込み禁止時間」と「割り込み保留可能時間」です。

私は元の記事で割り込み禁止時間という言葉を使っておらず、割り込み保留可能時間という言葉を使っています。にも関わらず、割り込み禁止時間を引き合いに出されたのは恐らく、視点の違いの問題で同じ命題だと思い込んでおられるのではないかと思われます。

先に結論を申し上げますと、両者は別の命題になります。

「割り込み禁止時間」は特定のコンテキストの実行中に割り込み禁止にされると「他の」割り込み処理が実行出来ないという問題を議論する時の命題です。

それに対して「割り込み保留可能時間」というのは現在処理中のコンテキスト、つまり「自分の」割り込み処理が次の同じ要因の割り込みが発生するまでに終了することが出来るかどうか、ということを議論する時の命題です。 したがって、割り込み禁止というよりもその割り込み処理が次の割込みまでに終われるかということが最大の関心事なわけです。

例えばUARTでFIFOを持たないようなコントローラを使うとしましょう。 115200bpsで1文字10bitとします。この時、1文字の受信割込みが発生する間隔は約86μ秒です。

つまり、その受信割り込みが発生した時の割り込み処理は86μ秒未満の時間で処理を終わらせないと次の受信割込み処理が実行できずに、1文字のデータを取りこぼすことになります。 この時、割り込み保留可能時間は86μ秒です。

そんな状況で5μ秒で終わったり80μ秒で終わったりするような時間見積りが出来ないようなサービスコールは使い物にならないわけです。

だから、i付サービスコールの処理時間は「割り込み保留可能時間」とセットで考えなければいけないわけです。

※説明を簡略化するために「自分の」という表現を使いましたが、厳密に言うと「自分の」と「他の」割り込み処理時間の最大時間と割り込みタイミングや割り込み禁止区間のトータルの話になります。