※本記事は広告を含みます。
目次
割り込み処理解説シリーズ
本記事は「割り込み処理解説」シリーズの1つです。
- 割り込みとは何か？ポーリングとの違いから理解する【組み込み入門】
- 割り込み処理でやってはいけないこと5選｜組み込み設計の落とし穴
- 割り込みは「処理を書く場所」ではない｜組み込み設計の本質（この記事）
- 割り込み×状態遷移設計｜イベント駆動型組み込みの基本パターン
- 割り込み優先度設計の考え方｜リアルタイム性を壊さないために
- 割り込みとRTOSなし構成の違いとは？設計思想の本質を整理する
これまで、
- 割り込みの基本
- 割り込みでやってはいけないこと
を整理してきました。
今回は少し抽象度を上げます。
割り込みは「処理を書く場所」ではない。
これは単なるテクニックではなく、設計思想の話です。
なぜ人は割り込みに処理を書いてしまうのか？
理由はシンプルです。
- そこにイベントがあるから
- すぐ動くから
- コードが短く見えるから
例えば：
void UART_IRQHandler(void)
{
receive_data();
parse_packet();
update_state();
}一見きれいに見えます。
しかしこれは、
責務を混ぜている状態
です。
割り込みの本来の役割
割り込みの役割はたった一つ。
「イベントが発生した」ことを通知すること
処理を完結させる場所ではありません。
理想形はこうです。
volatile uint8_t uart_event = 0;void UART_IRQHandler(void)
{
uart_event = 1; // 通知だけ
}あとはメインループ側で処理します。
なぜ“通知だけ”が正解なのか？
理由は4つあります。
① 実行時間を最小化できる
② ネストに強くなる
③ テストしやすい
④ 保守性が上がる
特に重要なのは③と④です。
割り込み内にロジックを書くと、
- 単体テストが困難
- 再利用しづらい
- 仕様変更に弱い
という構造になります。
割り込みは「入口」にすぎない
設計の観点で見ると、
[割り込み] → [イベント通知] → [状態管理] → [処理]
というレイヤー構造が理想です。
割り込みは一番外側の「入口」。
ロジックの中心にしてはいけません。
並行処理としての割り込み
割り込みは本質的に「並行処理」です。
- いつ実行されるか分からない
- メイン処理と同時に走る
- スタックを共有する
ここを理解すると、
ISRにロジックを書くのがいかに危険か
が見えてきます。
実務で意識していること
私が意識しているのはこの原則です。
ISRは3行以内に収める。
- フラグを立てる
- バッファに1バイト入れる
- タイムスタンプを取る
それ以上はメインへ。
これだけでトラブルは激減します。
設計思想の話
割り込みをどう扱うかは、
- 設計レベル
- 並行処理理解
- 保守性意識
がそのまま出ます。
動くコードを書く人と、
壊れない設計をする人の差が出る場所です。
とはいえ、割り込み内で処理せざるを得ない場合もある
理想は「通知のみ」です。
しかし実務では、
- ハードウェアFIFOが小さい
- 受信データを即座に退避しないと溢れる
- レイテンシが数µs単位で厳しい
といった事情で、
割り込み内で最低限の処理が必要になることもあります。
例えば：
void UART_IRQHandler(void)
{
uint8_t data = UART_DR; // レジスタ読み出し
buffer[write_idx++] = data; // 即退避
}ここで重要なのは、
ISRで「完結させない」こと。
- 解析はしない
- 判定はしない
- 状態変更は最小限
- ループ処理はしない
まとめ
割り込みは、
- 処理を書く場所ではない
- 通知する場所
- 設計の入口
ここを理解すると、設計全体が安定します。
この記事が参考になった方へ
割り込みについてはこちらの記事でもまとめています。
- 割り込みとは何か？ポーリングとの違いから理解する【組み込み入門】
- 割り込み処理でやってはいけないこと5選｜組み込み設計の落とし穴
- 割り込みは「処理を書く場所」ではない｜組み込み設計の本質（この記事）
- 割り込み×状態遷移設計｜イベント駆動型組み込みの基本パターン
- 割り込み優先度設計の考え方｜リアルタイム性を壊さないために
- 割り込みとRTOSなし構成の違いとは？設計思想の本質を整理する
技術に関するご相談・開発・自動化ツール作成・記事執筆などのご依頼も承っています。
小さなご相談からでもお気軽にご連絡ください。
コメント