プログラマーの理想と現実

第10回 割り込みは来ない

2015.05.13

この記事は、『UNIX Magazine』2004年8月号(2004年7月17日発売)に掲載された同名記事の初稿(著者から編集部に提出したもの)を元に、Web掲載用に一部を修正したものです。10年以上前に執筆したものなので、現在のUNIXを取り巻く環境とは色々と異なることがありますが、プログラミングに対する心構えとしては現在でも通用するものと思い、再掲してみることにしました。

・・・・・・・・・・

デバイスドライバや組み込みファームウェアの開発を担当しているあなた、またはこれから担当するかもしれないあなたへ、格言をひとつ。

割り込みは来ない

これは、デバイスドライバやファームウェアの開発にあたる技術者が持つべき心構えを説いたものだ。肝に命じておこう。

事実、私が担当したデバイスドライバやファームウェアの開発で、最初から正しく割り込みが来たケースはほぼ皆無だ。最初は必ず「割り込みが来ない!」と叫ぶところから始まる。なぜ来ないのか、についてはさまざまではあるが、おおむね25%が微妙なところでのプログラミングミス、25%が仕様書やデータシートの読み取りミス、残り50%はハードウェアのバグといったところか。

端的に言って、割り込みなんて普通はちゃんと来るものだ。でも実際には来ない。そこに落とし穴がある。普通は来るはずなんだけど、という気持ちで原因を探してもなかなか見つからない。だから”割り込みは来ない”のだ。来ないのが普通。そして、冷静に、慎重にデバッグしよう。

ハード屋 vs. ソフト屋

通常、割り込みはソフトウェアがハードウェアを操作することで何らか仕事を起動し、その経過や完了を通知する意味で来るものだ。我々ソフト屋の立場からすると、ハードウェアを正しく操作しているのに割り込みが来ないのだから、ハードウェアに問題がある、と主張したい。しかし、ハード屋の立場からすれば、正しく操作されれば割り込みは出るはずだから、ソフトウェアが正しく操作していないのが問題だ、ということになる。

こういった、ハードウェアとソフトウェアの境界に位置する問題は、非常に厄介だ。ソフト屋もハード屋もそれなりの根拠があって主張しているのだから、お互いになかなか非を認めようとはしない。加えて、ソフト屋はハードウェアの詳細を知らず、ハード屋もソフトウェアの仕組みを知らない状態で開発を進めているケースが多く、どちらも客観的な立場で問題解析にあたることができない。

このような状況は、UNIX系OSのような複雑なソフトウェアを搭載するシステムの開発で顕著に見られる。8ビットCPUで済むような小規模な組み込みシステムでは、ハードウェアもソフトウェアも、両方ともひとりの担当者(またはひとつの組織)が担当することはさほど難しくない。しかし、UNIX系OSのような大規模なソフトウェアを動作させるとなると、ハードウェアもソフトウェアも複雑になり、ひとり(またはひとつの組織)で両方を担当するのは困難になる。

お互いが主張を引っ込めなければ事態は進展しない。そのまま時間だけが過ぎてゆく。行き着く先は納期オーバーだ。ここは何としても歩み寄らねばなるまい。まずは謙虚に、本当にソフトウェアに問題がないかどうかを確認する必要がある。

割り込みを確認する

我々ソフト屋が「割り込みが来ない」と言うとき、それは具体的に何を表わしているのであろうか?ほとんどの場合、割り込みハンドラが呼び出されない という事実をもって、”割り込みが来ない”と言ってしまっているのではないだろうか。本当に割り込みが来ていなければ、確かに割り込みハンドラは呼び出されないが、それ以外にも割り込みハンドラが呼び出されない原因はいくらでも考えられる。

割り込みハンドラの登録を誤っているケース、割り込み信号の割り当てを間違っているケース、割り込みがマスクされていてOSが反応しないケース、などなど、多くの原因が考えられる。これらの可能性を地道に検証し、ソフトウェアに誤りがないことを確認するまで、ハードウェアが悪いと結論づけるわけにはいかない。

とは言え、これらをソフトウェア的に検証するのは、そう簡単なことではない。デバイスドライバやカーネルのデバッグには、常にいろいろと困難がつきまとう。ここは少し視点を変えて、まず本当に割り込みが来ているのかどうかを直接的な手段で確認してみよう。

以下のものを用意する。

  • ハードウェアの回路図
  • デバイスやCPUのデータシート
  • デジタルストレージタイプのオシロスコープ

回路図とマニュアルから、目的の割り込み信号がCPUに入力される信号線を探す。デバイスがPCIカードになっていてるならば話は簡単だ。PCIスロットの割り込み信号線(INTAなど)を見つければ良い。続いて、基板上で目的とする信号線を観測できるポイントを探す。試作ボードなどでは、テストピンとして観測しやすくなっていることもある。テストピンがなければ、コネクタのハンダ付け部分、ダンピング抵抗やプルアップ抵抗などのチップ抵抗のハンダ付け部分でも良い。回路図と基板のシルク印刷を見比べて探してみよう。

観測ポイントが見つかったら、オシロスコープをシングルショットのモードに設定し、プローブを観測ポイントに当て、プログラムを動作させる。オシロスコープが信号の変化を検出すれば、割り込みが本当に来ていることが実証されたことになる。

ハードウェアを少しだけ知る

信号線の観測は敷居が高いと感じただろうか?確かに、ハードウェアの知識がまったくないと、難しいと感じるかもしれない。

複雑なシステムになればなるほど、ハードウェアとソフトウェアはそれぞれ専業で開発する傾向が強くなる。UNIXのデバイスドライバともなると、カーネル内部の動作や機能を熟知していなければならず、ソフトウェアだけでも相応の知識と経験が必要になる。ハードウェアの知識までは手が回らない、ということにもなろう。

しかし、オシロスコープによる信号線の観測など、ハード屋にとっては基本中の基本たるデバッグ手法だろう。ソフト屋で言えばprintfデバッグと大差ないレベルではないだろうか。本当は、もっといろいろと奥が深いのだろうが、ソフト屋の観点で信号がどうなっているかを観測する程度ならば、付け焼き刃の知識でもある程度なんとかなるものだ。回路図とデータシートが読めて、基板の配線具合がわかれば良いのだ。たったそれだけで、ソフトウェア的な手法では確認しにくい現象を、より間単かつ確実に把握することができるようになる。

ソフト屋の立場で、ハードウェアの信号線の具合を確認することができるようになると、ハード屋とソフト屋のにらみ合い状況も自然と解消される。まず、ハード屋にも確認しやすい形で問題となる現象を伝えることができる。割り込みハンドラが呼ばれない、という現象よりも、割り込み信号がアクティブにならない、という現象のほうが、ハード屋にとってははるかに調べやすい。

また、必要であれば問題となる現象を再現するための、非常に小さな実験用プログラムを作って渡すこともできる。開発中のデバイスドライバを含むUNIXカーネル全体を渡して、割り込みが来ないと主張しても、ハード屋はソフトウェアの動作を把握できず、確認のしようがない。実験用プログラムが小さければ、ハード屋もソフトウェアの動作を把握でき、プログラムの処理が誤っているか、あるいはハードウェアのバグかを検証することができる。

結局のところ、ほんの少しだけ相手の土俵に踏み込むことで、つまりハードウェアを少しだけ知り、ハードウェアの動作を観測することで、ものごとを建設的に進めることができるようになる。

機材を揃えてみる

ソフト屋として、ハードウェアの領域にちょっとだけ踏み込むことが重要であると説いたが、踏み込むにはどうしてもそれなりの機材が必要だ。ここでは、ソフト屋が持っていて役に立つ機材を3つほど挙げておこう。なお、本格的にハードウェアを開発するわけではないので、それなりに安価に入手でき、気軽に活用できることが条件だ。

テスタ

電気を扱うならば、まずテスタだ。初歩の電気工作でも必須のツールであり、ハードウェアの領域に踏み込むには絶対に必要だ。アナログメータ式とデジタル表示式があるが、デジタル回路で使うならばデジタル表示式の方が良い。おもに電圧の測定と、導通チェックに使用することになるだろう。

価格は数千円~数万円程度で、容易に手が届く範囲だ。もし余力があるならば、周波数カウンタ機能を備えているものを購入しておくと、後々役に立つかもしれない。

オシロスコープ

オシロスコープと言えば、かつては残光の長いブラウン管に周期性のある信号を表示し、その波形を観測するものであった。つまり、アナログ信号の観測には便利だが、周期性に乏しく、単発事象の多いデジタル信号の観測には使えないものだった。その後、高速A/Dコンバータと高速メモリを搭載したデジタルストレージオシロスコープが登場し、周期性のない信号や単発事象も観測できるようになり、デジタル信号の観測にも使われるようになった。しかし、大変に高価で、とてもソフト屋がちょっと便利だからといって購入できるようなものではなかった。

しかし、近年のデジタル技術の発展により、デジタルストレージオシロスコープは高価であるという状況は一変した。特に、表示部にブラウン管ではなく LCDを用いたデジタルオシロスコープは安価に入手できる。LCDはブラウン管に比べると解像度が低く、アナログ波形の再現性には難があるが、デジタル信号の観測用と割りきってしまえば、さほど問題にはならない。

オシロスコープには、性能として観測できる信号帯域の制約があり、その大小で価格が大きく異なる。高性能なもの(すなわち観測可能周波数の高いもの)ほど高価である。ソフト屋がちょっとしたデバッグに使う程度であれば、100MHzもあれば十分であろう。100MHz程度のものであれば、10万円~20万円で入手できる。

ロジックアナライザ

ロジックアナライザは、CPUのアドレスバスやデータバスなど、複数の信号線で構成されるデジタル信号を観測するための装置だ。各信号線の状態を時間とともに記録し、あとで画面に波形を表示させて確認することができる。バスに流れるデータを直接把握することができるので、ソフトウェア的な手段ではデバッグが困難なときに、うまく使うと大変便利だ。

ハードウェア開発の現場で使われるものは、単一のかなり大きな筐体に表示用の画面と操作用のボタンやダイアルなどがついたオールインワンタイプで、使い勝手は良いが大変に高価で、ソフト屋がちょっとデバッグに使うというような雰囲気ではない。

しかし、近年では、PCの処理能力が格段に向上したせいか、表示や操作やデータ解析などはPC上で動作する専用のソフトウェアに任せ、ハードウェアとしては小型のボックスで信号の収集のみを行い、パラレルポートやUSBなどでPCと通信を行うセパレートタイプのものもあり、比較的安価に入手できるようになって来ている。ソフト屋がデバッグに使うのであれば、こういったセパレートタイプでも十分だろう。

価格は、同時に観測できる信号線の数(チャンネル数)と、信号線をサンプリングする周波数、および信号記録用のメモリ容量によって大きく異なる。ソフト屋がデバッグに使うことを前提とすると、少なくともCPUやPCIカードなどのバスが観測できる程度のチャンネル数が必要になる。32ビットのバスと制御用の信号線を合わせて、合計36~42チャンネルくらいあるとよい。対して、サンプリング周波数はそれほど高いものは必要ない。200MHz程度あれば、PCI バス(33MHzか66MHz)やちょっとした組み込み用CPUのバス(50MHz~100MHz程度)は観測できる。それ以上高速なバスの観測となると、色々とハードウェア的な影響があって、ソフト屋の付け焼き刃の知識では対処できなくなるからだ。36チャンネルで200MHzサンプリング程度のものであれば、10万円~20万円くらいで入手できる。

☆☆☆

今回の副題でもある”割り込みは来ない”という格言には続きがある。

バスはハングする

レジスタには書けない

メモリは読めない

いずれも、デバイスドライバやファームウェアの開発を行っていると、頻繁に出会う現象である。バスはしょっちゅうハングし、レジスタに書いた値がが消えてなくなり、メモリから読んだ値はゴミだらけ、ということだ。いずれも普通は起きないことではあるが、なぜか良く起きる。「そういうものだ」と割りきって、冷静に、慎重に、そしてちょっとだけハードウェアに踏み込んでデバッグしよう。

注釈

  • 初稿に由来する表現の差異、ならびにWeb掲載に伴う修正のため、雑誌掲載の内容とは一部文章等が異なることがあります。
  • 転載許諾を頂いた株式会社KADOKAWAアスキー・メディアワークスブランドカンパニーならびに旧『UNIX Magazine』編集部の皆様に深く御礼を申し上げます。

著者プロフィール

tom

当社設立直後に入社して約30 年、UNIX の移植、日本語化、デバイスドライバ開発、周辺機器ファームウェア開発などに継続的に携わり、現在も現役でUNIX 系OS の移植、改造などの開発業務を行う。社内でもっともプログラムを書いている人の一人。代表取締役社長。

記事一覧Index