ARMの開発環境

デザインウェーブのARM基板で実験するための私の開発環境を紹介します。

まずコンパイラが必要になります。ARM用のGCCを使うには、GCC自体をコンパイルしたり、リンカやライブラリ自体をコンパイルするといった作業から始まります。それはとても大変で長い時間を要する作業です。

そこで私は、「日本の組み込み情報」というサイトにある、GNUWingというツールを利用させていただいています。GNUWingというのは、アップウィンドテクノロジー・インコーポレイテッドさんが開発した、組み込み用開発環境のディストリビューションです。
現在は、ARM用、SH用、MIPS用、PowerPC用の4種類があり、プラットフォームはCygwin用とRedhatLinux用の2種類で、計8種類のものがリリースされています。

GNUWingは、GCCやGDBやリンカなどの開発環境一式をセットにしたものです。GCCなどの難しいことを全く知らなくても簡単にインストールできて、その瞬間からARM用の開発環境を使うことができるようになります。とてもおすすめです。

私は、間発環境サーバとしてRedhatLinux9を24時間動かしていて、そのRedhatにはGNUWingをインストールしています。Linuxのサーバは、SambaとWindowsのファイル共有でWindows環境からアクセスできるようにしています。
ソースコードの編集はネットワーク越しにWindows用のテキストエディタで行います。Linuxにログインするのは、GCCでコンパイルする時だけです。ソースコードの編集や出来上がったアセンブラコードのチェックなど、頭を使う作業は使いやすいWindows環境から行えるので、開発効率が低下する心配もありません。

パソコンとARM基板はJTAGを使って接続しています。シリアルのコネクタは使用していません。プログラムはRAMにダウンロードしています。

ADうC7026に内蔵されたフラッシュROMは使用していません。ADuC7026は、JTAGバウンダリスキャンでフラッシュROMに書き込むということが(たぶん)できないと思われます。したがって、ARM7に内蔵されたEmbeddedICE機能を使って、作成したプログラム(ELFファイル)をダウンロードすることになります。

JTAGのツールは、もちろんMITOUJTAGです。
MITOUJTAGは、Windows上から簡単なGUI操作で使用できます。XILINXやALTERAのパラレルケーブルや、ナヒテック製のSmartJTAG、Mobile JTAG CableといったUSB接続のものなど、いろんな方法でARMデバイスとつなぐことができます。

ケーブルをつないでボタンを押せば自動でデバイスが認識されます。

MITOUJTAGには、ARMデバッガが内蔵されています。このデバッガは、GCCが出力したLSTファイルを使って、機械語レベルで１命令ずつステップ実行させることができます。ネイティブに埋め込まれたARM用デバッガなので、GDBやInsightを使ってリモート接続するよりも、格段に高速なレスポンスが得られます。

また、MITOUJTAGのARMデバッガは、GDBやInsightのリモート接続を受け付けることもできます。ただし、TCP/IP上でGDBプロトコルを受け渡しするので、レスポンスの低下は避けられません。

ARM7用のネイティブなデバッガと、GDB/Insightを使い分けることで、デバッグの方法が広がります。

C言語に入る前のスタートアップコードなどは、昔から少しずつ付け足し付け足し使ってきた秘伝のスープのようなコードを使っています。全く高度なものではありません。cpsrとspを設定してmainにジャンプするだけです。

ARMの電源波形を解析して遊ぶ

DWMのARM基板の電源波形を観察して解析して遊んでいます。
この基板はあくまで評価ボードですから、電源にノイズが乗るなら、それを使った楽しみ方をしたいですね。

まず、BL命令で無限ループさせた場合の波形を調べてみました。(BL命令というのは、ARMアセンブラの分岐命令です)

LOOP:
    bl loop

大きなノイズのピークが２つと、小さなピークが２つ見えます。 この４つのピークが周期的に繰り返されています。 ピークが出る周期は約5.27MHzの逆数で、これはデフォルトのCPUのクロック周波数と一致します。 ピークとピークの間に小さなピークもあります。裏クロックでしょうか。

この波形から、BL命令を無限に繰り返すと１周期に４サイクル要しているのではないかと推測されます。
一方、ARM7のテクニカルリファレンスマニュアルによれば、BL命令のサイクル数は「2S+N」と書かれています。Sはシーケンシャルサイクル、Nはノンシーケンシャルサイクルだそうです。大きなノイズはシーケンシャルサイクルのアクセスを、小さなノイズはノンシーケンシャルサイクルのアクセスを表しているのでしょうか。とりあえず、つぎにいきましょう。

次に、BL命令の前に、NOP（実際には、MOV R0,R0）を入れた場合の波形です。

LOOP:
    nop
    bl loop

NOP命令はデータ処理命令ですから、１Sサイクルで実行できるはずです。波形を見ると、大きなノイズが１個増えました。また、ループの周期は５になりました。

こんな調子で、ADD(足し算)命令程度なら追跡できそうなのですが、STR命令やMLA(積和)命令などは、さすがに分からなくなりました。

ARMは1クロックで1つの命令を実行できるわけではなく、ちょっと複雑な命令だとすぐに複数クロックを必要としてしまうことを痛感しました。電源の波形から命令の実行状態を追跡するにはARM7のバスサイクル、特にノンシーケンシャルサイクルについて勉強しなければいけなさそうです。

サイドチャネル解析ができないかなと思って始めた電源波形の解析ですが、予想以上に難航しています。0x55555555と0xAAAAAAAAを足し算させた場合と、0x55555555と0x55555555を足し算させた場合などでは、若干の差はあるような気がするのですが、有意な差があるとは言い切れませんでした。

ナニワ金融道を実践してみた（先物の勧誘の断り方）

自営業の皆さん、先物の勧誘って来ますか？

２年前、ある展示会で、ある会社の人と名刺交換しました。
○○商事と名乗っていたし、展示会に来ていたので、電子部品の商社かなと思っていました。

ところが、２年前のある日、その人から電話がかかってきて、やたらと雑談をしながら、投資がどうのこうのといっていってくるのです。何の会社かはっきり言わなかったのが特徴でした。「もうかけないでくれ」、と言って切ったのですが、１ヶ月くらいするとまたかかってきます。強く断ったら、手紙が来て「一度合いたい」と書かれていました。
当然無視しましたが、かなりしつこかったですね。

さて、最近、「実践！ナニワ金融道＋α～四発目 はまればドつぼ！恐怖の先物取引編～」というマンガを読んだのですが、このマンガは先物取引にはまった人がどのように破滅していくかが描かれていて、とても参考(?)になります。
読み終わってから、先の○○商事はひょっとして先物の会社じゃなかったかな・・と思い出し、調べてみると、案の定先物の会社でした。
ナニワ金融道の最後に、「誰にでもできる電話セールス完全撃退術」というのが書かれてていて、それによると『電話は１分で切れ』とのことでした。

そして、今日、なんと、その○○商事さんから１年半ぶりに電話が来たのです！！
もう電話は来ないと思っていたのに、ちゃんとリストに残っていて、クロールしてるんですね！
これは、先物勧誘の「お断り」を実践する、千載一遇のチャンス！

○○商事「ナヒテックさんですか」
私「はいそうです」
○○商事「以前お名刺交換させていただいた○○商事の○○と申しますが」
私「○○商事さんて、先物の会社ですよね」
○○商事「・・はい、そうですが」
私「私は、先物はやらないんですよ。」
○○商事「いえ、あの今回は・・」

先手を打たれて、相手に先物商社であることを見抜かれると、かなり困惑するようです。
去年電話をかけてきたときには、○○商事は自分を先物の会社だと言わなかったし。

私「貴方の所属部署とお名前を教えていただけますか」
商事「○○商事、○○営業所 ○○です」
私「えっと、復唱します。○○商事、○○営業所の○○さん、ですね。もうかけないでください。」

いかにも、メモしているという感じで私は答えました。
ナニワ金融道には相手の会社と名前をメモしろとあります。先物の営業マンは、証拠が残ることを嫌がるのだそうです。

○○商事「いえ、あああ・・それでは、発信規制リストに登録しますから、ワンコールだけさせてください。そうすれば、うちからは絶対にかからなくなります」

その会社のダイアルの仕組みはよくわかりませんが、ワンコールすると発信されなくなる仕組みを導入しているのでしょうか。しかしながら、ワンコールといってかけさせるのは良くないでしょう。その会社からは来なくなっても、他の会社から来るようになったら困ります。

私「もうかけないでください。今度来たら、消費者センターに連絡です」

消費者センターと全協商というのに連絡されるのを嫌がるらしい。これも、ナニワ金融道に載っていました。

○○商事「ああ・・ちょっと待っ」
私「さよなら」

ここで、無理やり電話を切りました。
これ以上深く会話してみるのも楽しいのでしょうが、「いまSDRAMが値上がりしてます！コンデンサがまたとないチャンスなんです！」とか言われても嫌だし、危うきに近寄らないほうがいいと判断したためです。
たぶん、もう来ないでしょう。手紙は来るかもしれませんが。

技術士登録！

某技術士関係情報サイトによると、10日に登録申請した人の中には既に登録証が送られてきている人がいるというので、ためしに技術士会に電話で問い合わせてみました。すると、「技術士の登録が14日に完了している。一週間くらいで登録証が送られてくるはず。もう技術士を名乗ってよいですよ」、とのこと。登録番号も教えてもらいました。
今月10日に郵送で申請したのに、手続き速い！

というわけで、念願の技術士（電気電子部門）の資格を取得することができました。2001年に技術士という資格の存在を知ってから、受験資格を得るまでに4年。長かった。

技術士について話すと長くなりますが、技術士というのは国が認定した技術コンサルタントの資格です。
技術士には公益確保と資質向上の責務が課されています。
これからは自分の持っている技術を、より一層公益のために使っていきたい所存です。

今後の抱負などについては日を改めて書きます。

パスコンはどこに入れればよいか

DWM付録のARM基板を安定して動作させるためには、ディジタル系3.3V電源にパスコンを入れればよいということが、昨日の実験でわかってきました。
本当は0.47uFがいいのでしょうがあいにく手元になかったので、0.1uFを使うことにします。

さて、パスコンはどこに入れるのがベストでしょうか。

---

まずは、パスコンなしの波形を見てみます。

CPUの動作クロックにあわせて、VCCに大きなノイズが乗っています。LEDチカチカは10秒ほどで止まってしまいます。

---

次は、R4とSW1の間にパスコンを入れた場合です。なお、R4にはディジタル系の3.3Vがきています。

問題のLVDD端子よりも奥の方にパスコンがあるので、ノイズの改善効果は期待できるでしょう。

LEDチカチカがすぐに停止するということはなくなりました。
若干、ノイズが減っているのがわかります。

---

次は、基板の裏側にパスコンをつけた場合です。
LVDDからかなり近い位置になります。LVDD-パスコン-GNDの総配線長はおよそ15mmくらいでしょうか。

なお、この付録基板は、スルーホールの穴に薄いレジストがかかっているので、そのままでは半田が乗りません。付録基板のスルーホールに半田付けするにはレジストを削る必要があります。私は、ドリルの歯を手で持ってくるくると軽くまわして、レジストを削りました。

波形的には、だいぶん改善されてきました。VCCのノイズは、パスコンなしの場合の60%くらいの大きさになりました。LEDチカチカは正常に動いています。

---

最後は、ADuC7026の26番 & 27番端子に直接0.1μFのパスコンをつけた場合です。GNDは、直近のスルーホールから取ります。

ノイズは観測できないほど小さくなりました。

まだ若干のノイズは残っていますが、CPUの動作クロックと明確な相関はなさそうでした。

---

まとめ

パスコンをLVDD端子(27番ピン)の近くに配置すると、ノイズが抑制される傾向が見えてきました。デバイスの固体差にもよるのでしょうが、LVDD端子上のノイズ、すなわち3.3V VCCの電圧変動が大きいと、命令フェッチに失敗して止まってしまう、という現象が出るのだと思われます。

もし動作が不安定という方は、難しくない適当な場所にパスコンを入れてみてください。
これで思う存分、LEDチカチカできます。

DWMのARM基板にパスコンを入れる

このレポートは私がたまたま購入した付録基板で確認したものです。本レポートの結果をご利用される方は各自の責任の範囲内で行ってください。本レポートは内容の詳細な検討も行っておりませんし、デバイスのベンダーや、出版元に確認したわけでもありません。内容の正確さは保証しません。万が一のことが起きても、自己責任でお願いします。以上の点をご了承の上、お読みください。

まず結論だけ言うと、LVDDの端子(27番)が3.3Vにつながっていることが直接の原因ではなく、パスコンの不足によりLVDD端子の電圧に大きなノイズが乗ったため、私が手にした基板では不安定になっていたようです。

---

DWM付録のARM基板を眺めてみると、ディジタル用3.3Vの電源ラインがつぎのように配線されていることに気が付きました。

3.3Vのディジタル電源には、パスコンらしきものがC11とC7しかないのです。

---

まず、基板をデフォルトの状態（誤動作する）で、LVDD端子の波形を測定してみました。
オシロはACモードで使います。

VCCに約5.2MHzの周期的な繰り返しのノイズ波形が見られます。そのピーク・トゥ・ピークは300mV近くに達します。

追記　5.2MHzというのは、ADuC7026のデフォルトの動作周波数です。電源投入直後は44MHzの原発振を8分周したクロックで動作しています。POWCONレジスタを変更すると動作周波数が変わり、このノイズ波形の周波数も変わります。

---

次の波形は、CN1のコネクタの部分に0.1uFのコンデンサを入れた状態で測定したものです。

これで約１時間、正常に動作するのを確認しました。
（１時間で止まったというわけではなく、１時間以上の動作確認は行っていないという意味です。）

追記一晩中動かしたところ、朝起きたら止まっていました。

オシロの波形で見るとあまり変わっていないような気がしますが、ノイズは若干減ったような気がします。
短時間なら何とか誤動作はしないようです。

---

次の波形は、27番ピンの近くに0.1uFのコンデンサを入れた状態で測定したものです。


電源のノイズ波形はかなり抑制されました。
正常に動いているようです。

---

ということで、動作が不安定になってしまった原因は、LVDDの端子(27番)が3.3Vにつながっていることが直接の原因ではなく、パスコンの不足によりLVDD端子の電圧に大きなノイズが乗ったことではないかと考えられます。

ネットで検索すると、改良しなくてもちゃんと動いている人もいるようです。

正直な話、パスコンの有無がこんなに波形や動作に効いてくるとは思いませんでした。
もし、動作が不安定ということでお悩みの方は、とりあえず、
①　そのまま基板で動く
②　CN1か、その近くにパスコン(0.1uF)を入れたら動く←一晩中動かしたら止まってた
③　26番 & 27番ピンにパスコン(0.1uF)を入れたら動く←一晩中動かしても動作する
④　LVDDを浮かせてパスコン(0.47uF)を入れたら動く←一晩中動かしても動作する
という感じで検討してみてください。

DWMのARM基板を研究中

昨日、DWM付録のARM基板で、LEDチカチカをやってみたところ、起動してから１０秒くらいでプリフェッチアボート例外で止まってしまうという現象に遭遇しました。昨日はCPUの27番ピン(LVDD:コア電源 2.6V)を浮かせるという処置をすることで、LEDチカチカが安定して動作するようになりました。

LEDチカチカが途中で動かなくなる原因は、このLVDD端子が原因ではないかと推測されるのですが、電圧だけの問題とも思えません。なぜなら、昨日の改良をした状態でLVDDを3.3Vに無理やりつないだ場合、正常に動作した（数十秒で停止することはなかった）のです。

原因を調べるために、今日、試しにこの27番ピンを元に戻してみました。つまり、基板をデフォルトの状態に戻しました。するとやはりプリフェッチアボート例外で止まってしまいます。

ここで、下の図のように27番ピンと26番ピンから、ディジタルGNDに向けて0.1μFのバイパスコンデンサを入れてみたところ、LEDチカチカは1時間以上動きつづけました。(今のところ動作異常は起きていない)

26番ピンと27番ピンを半田でショートさせ（もともと基板上で接続されている）、そこからGNDへコンデンサを通すというものです。

この改良を行ったところ、LVDDが無理やり3.3Vに接続されているにもかかわらず、LEDチカチカは動きつづけました。

デフォルトの基板でLEDチカチカが止まってしまう原因は、おそらく、LVDDにパスコンが入っていないことではないかと思います。ディジタル系3.3Vの最寄のパスコンは、ADM3202の隣にあります(C7)。27番ピンのLVDD位置からはちょっと遠いような気がします。

と、書いているうちに、なんとなく解決方法が掴めてきました。
すごく簡単な解決方法がありそうです。
今思いついた改良を施して、しばらくLEDチカチカをヒートランテストしてみます。続きはまた明日。

DWM付録のARM基板でLEDチカチカ

今日は、午後から新宿で打ち合わせでした。
歌舞伎町は怖いと聴いていたので、人にぶつからないようにビクビクしながら歩きます。ひえぇ

------------

さて、戻ってきてから、購入したDWM付録のARM基板を動かしてみました。
JTAGのコネクタをつけてXILINXのParallelIVケーブルをつなぎます。

MITOUJTAGを起動してみると、見事にARM7を認識成功。MITOUJTAG内蔵のARM7デバッガも動きました。

とりあえず、LEDチカチカのプログラムを作成して、SRAMが配置されているアドレス0x10000にダウンロードしてみると、LEDが点滅。
成功・・・かと思いきや、数十秒でチカチカが止まってしまいます。電源に電解コンデンサを入れたりしても改善せず。

チカチカが止まると、アドレスカウンタは変なアドレスを指して、プログラムが存在していないところを実行しています。

調べたところ、どうやらLEDチカチカの途中でアドレス0x0000000Cへジャンプしてしまっているようです。
（0x0000000cにジャンプしているというのは、0x0000000Cにハードウェアトラップを設定すると引っかかるのに、0x00000008にトラップを設定しても引っかからないということから判断しました。）

ARMの解説本を読んでみると、0x0000000Cにジャンプというのは、ARMのコアがプリフェッチ・アボートした場合です。
プリフェッチ・アボートというのは何かというと、命令のフェッチに失敗するような場合に発生する例外です。これは普通にプログラムを実行している場合には遭遇しない例外です。何か、ハードウェアの問題が起きている可能性があるような致命的な例外です。

不意に聞いた噂によれば、この基板ではADuC7206のコア電源（LVDD）という端子(内蔵のLDOで作られた2.6Vの)が、3.3Vの電源につながってしまっているそうです。

そこで、下の写真のように27番ピン(LVDD)を浮かせ、浮かせたピンの下にカットしたポリイミドのテープを滑り込ませて絶縁します。そして、手持ちにあった1uFと0.01uFのコンデンサでGNDにつないだところ、プリフェッチアボートは起こらなくなりました。
LEDチカチカは１時間経っても正常に動作するようになりました。

この加工は結構大変でした。まず、半田吸い取り線を使って、ICの27番ピン付近の半田をできるだけ吸い取ります。ICのピンにはほとんど半田が残っていないような状態にします。吸い取ったら、細いピンセットを使って、無理やり基板からピンを剥がします。ちょっと力加減を間違うと隣のピンを曲げてしまったり、折ったりします。何度か危ない目に遭いました。こうしてピンを浮かせたら、何らかの方法で固定しないと、簡単に折れてしまいそうです。私はテープで固定しましたが、ホットメルトでもいいかもしれません。
27番の周辺のピンには半田を流して、吸い取られた半田を補充します。

DWMの第3章によれば、本当はLVDDには0.47uFのコンデンサをつけるのだそうですが、手元になかったので、適当な容量のコンデンサをつなぎました。

ただし、LVDDだけが原因ではないかもしれません。なぜなら、LVDDにこのような処置した直後にもプロフェッチ・アボートは完全には収まりませんでした。しばらく使っているうちに、プリフェッチアボートしなくなりました。
しかしながら、ためしにこの27番端子をVCC(3.3V)にショートさせたりすると、再びプリフェッチ・アボートしてしまいました。

LVDDに何か強烈なことが起きると、プロフェッチアボートしてしまうのかもしれません。
ただ、正直なところ、この端子が原因かははっきりとはわかりません。より詳しい検証をするには、浮かせた27番ピンをもう一度戻したり（それは嫌だ！）、もう一冊DWMを買ってきて試すということになりそうです。

技術士の登録で駆け回る

早速、技術士の登録を申請しました。

試験に合格しても、登録が完了しないと技術士を名乗ることはできません。登録には30～45日を要すると書かれています。しかも、込み合っている時期は時間がかかるそうなので、できるだけ早く登録は済ませたいものです。

そこで、朝、技術士会に電話をかけて、登録に必要な書類を確認しました。
　・申請書
　・収入印紙
　・登記されていないことの証明書
　・市区町村の発行する身分証明書
だそうです。
申請書は技術士会にあるので、用意するものは身分証明書と登記されていないことの証明書の、２点です。
会社に勤めている場合などは、さらに会社の承諾書などがいるそうです。

この手続きを知らないと、書類を集めるのはかなり苦労します。勤務先の承諾書をもらったり、証明書を郵送で申請すると、２週間くらいはかかってしまうのではないでしょうか。私は３年前に技術士補の登録をしたことがあったので、心の準備ができていたのは幸いです。

まず、本籍のある市役所にいって身分証明書を取ってこなければなりません。住んでいる市ではなく、本籍のある市役所、というのがポイントです。また、「登記されていないことの証明書」という変な名前の書類は、東京の九段下にある法務局まで行って取得します。これらの書類は禁治産者や準禁治産者、被後見人などに登記されていないことを証明するものだそうです。身分証明書と登記されていないことの証明書の詳しい違いはわかりませんが、技術士の登録を申請するには、この両方の書類が必要です。

「登記されていないことの証明書」は、平成17年からは各県の法務局でもらえるようになったらしいのですが、３年前に技術士補の登録をしたときにも取得したことがあったので、迷わないように東京の法務局で取得しました。
法務局を出たら、地下鉄東西線に乗って、日比谷線に乗り換え、神谷町へ行きます。

そして技術士会のある田中山ビルへ行きます。

技術士会はビルの８階と９階ですが、エレベータの中には案内板がなく、調べずに乗ったら何階で降りればいいのかわからず、ちょっと迷うことに。
気を取り直して８階で降り、申請用紙を購入。１０００円。

その場で記入をしようとしましたが、申請の前に収入印紙と手数料の振込みをしなければならないので、一旦、田中山ビルを出ました。
昼時だったので、近くにある中華料理屋で坦々麺を食べながら、申請用紙に目を通します。

申請書には２種類の様式がありました。どうやら２つ目の申請書は、試験ではなく認定された場合のだそうです。認定なんてのがあるのかと思い、登録の手引きを読んでみると、オーストラリアと日本では技術士の相互互換性を認めているそうで、オーストラリアで技術士に認められた人は試験によることなく日本でも技術士登録ができるそうです。へぇ～

その後、郵便局へいき、手数料の振込み(６５００円)と、登録免許税用の収入印紙（３００００円）を購入。きっと、その日は３万円の収入印紙がいっぱい売れたでしょう。

郵便局では、待ち人数が１６人と、超混んでいたので、待ちの間に申請用紙を記入しました。
申請用紙には、登録する技術士事務所を「有限会社ナヒテック」と書きました。
そして、田中山ビルへ戻り登録申請。

申請用紙には、受験番号ではなく、合格番号を書く必要がありました。
さらに、技術士補だった人の場合は技術士補登録番号と登録の日付も必要です。
合格番号は合格通知に書かれているようなのですが、発表当日にはわかりません。
しかしながら、これらの番号は受付の人に聞けば教えてくれるので、問題はありません。

問題なく登録できると思われたのですが、なんと、登録には会社の承諾書（用紙No2）が必要だといわれました。
自分で会社を経営している旨を伝えたのですが、登録する技術士事務所に(有)とか(株)とかがつくと、自ら経営する場合でも自分で自分を証明する必要があるのだそうです。確かに登録の手引きにもそのように書かれています。会社の角印を持っていれば、その場で押せばよいそうです。

会社に戻りはんこを押して、郵便局へ行き、簡易書留で登録用紙を出しました。

ということで、何とか２月１０日の内に登録申請を済ませることができました。
おそらく、１ヶ月くらいで登録証が送られてくるでしょう。
また、１５～２０日で登録自体は完了するそうなので、電話で問い合わせれば登録が済んだかどうかはわかるそうです。

早ければ、２月の末には晴れて技術士になれていると思います。

技術士二次試験の合格報告

本日、技術士二次試験の結果が発表されました。
技術士会のホームページで確認したところ、自分の名前があるのを確認しました。

これもひとえに指導してくれた技術士の先生や、支えてくれた家族、そしてお客様皆様のお陰と感じております。
この場を借りてお礼を申し上げます。

WindowsXP時代のパラレルポート制御

パラレルポートのアクセス権を理解するため、parport.sysの使い方を習得しました。

parport.sysにアクセスすると、パラレルポートのアドレス等の情報や、排他的アクセス権を取得することができます。
このデバイスドライバを理解するのに、いちばん参考になったのは、翔泳社の「WDMデバイスドライバ 」という本でした。

この本によれば、
　１．「\Device\ParallelPort0」という名前のドライバがある。
　２．IoGetDeviceObjectPointerでデバイスオブジェクトのポインタを得る。
　３．Internal IOCTLを発行する。
　４．TryAllocatePort関数を呼び出す。
　５．FreePort関数を呼び出す。
という手順が書かれています。１ページに満たない短い解説なのですが、意味を理解するのに数日かかりました。

何が大変だったかというと、Internal IOCTLを発行するにはIoBuildDeviceIoControlRequest関数でIRPを作って、IoCallDriverを呼び出す、という手順を理解するので一苦労。
IoCallDriverでIOCTL_INTERNAL_GET_PARALLEL_PORT_INFOを発行する方法がわかれば、PARALLEL_PORT_INFORMATION構造体を得ることができます。

そして、PARALLEL_PORT_INFORMATION構造体の中にTryAllocatePort関数のポインタが格納されています。
このTryAllocatePort関数を呼べばよいのですが、引数をどうすればよいのか、かなり悩みましたが、PARALLEL_PORT_INFORMATION構造体の中にあるContextという値を引数にして、
portinfo.TryAllocatePort(portinfo.Context);
とするのが正解のようです。

ただし、同一のプログラムでTryAllocatePortを2回呼び出してしまうと、なんかロックがかかってしまうようで、パソコンを再起動しないとアクセス権が得られなくなってしまうようです。

さて、苦労の末、ようやくInternal IOCTLの使い方をマスターできたのですが、これを使うと、パラレルポートのアドレスや、ポートがECPやEPPに対応しているか、などの情報を得ることができます。
おそらく、ポートのアドレスを調べる最も正当な方法でしょう。

私のPCでは、こんな情報が得られました。

　OriginalController=0x378
　Controller=0x378
　SpanOfController=0x8
　OriginalEcpController=0x778
　EcpController=0x778
　SpanOfEcpController=8
　HardwareCapabilities=0x9　 (ECP mode,BYTE mode, )
　FifoDepth=16
　FifoWidth=1
　EppControllerPhysicalAddress=0
　SpanOfEppController=0
　Ieee1284_3DeviceCount=0
　CurrentMode=0x0

いろいろやった末、ようやくTryAllocateで排他的制御権を獲得することができるようになりました。
WindowsXPのWarmPollを停止させることができ、当初の問題は解決できました。

しかし、排他的アクセス権を得ると、もっと重大な問題が出たのです。

そのことを書く前に、そもそも、なんでこんなことをやっているかを説明しましょう。
ことの発端は、MITOUJTAGからALTERAのByteBlasterを使おうとしたとき、WindowsXPで動作がおかしいことに気が付いたことでした。

WindowsXPでWarmPollが動きだすと、ByteBlasterの中の重要な制御信号がWarmPollに勝手にいじられてしまい、ByteBlasterが正常に動作できません。そこで、WarmPollの回避方法として排他的アクセス権を獲得しようと考えたのです。

確かに、パラレルポートへの排他的アクセス権は獲得できました。WarmPollも回避できました。

ところで、ALTERAのQualtusIIは、内蔵のJTAGプログラマを使用しなくても、なぜかコンパイル中にパラレルポートへ頻繁にアクセスします。困ったことに、QualtusIIも排他的アクセス権を獲得しようとするらしいのです。しかも、獲得できない場合には、諦めるのではなく、長時間のWAITを行ってしまいます。

つまり、QualtusIIは、パラレルポートの排他的アクセス権が得られないと、コンパイルがとても遅くなるらしいのです。
この現象は、QualtusIIに内蔵されたJTAGプログラマを使わない場合でも発生します。

例えば、スカスカのVHDLファイルをコンパイルすると、普通なら10秒くらいで完了します。しかし、QualtusIIがパラレルポートの排他的アクセス権を得られないと4～5分かかってしまうようです。

これではちょっと困ります。QualtusIIを使う場合にはMITOUJTAGが排他的アクセス権を持ったままにはできないのです。

結局、WarmPollを回避するには、レジストリに値を設定するのがベストということなのでしょう。

Windows2000やXPで、パラレルポートのアドレスを正当に取得する方法がわかっただけでも、この数日間の作業の成果があったと思うことにしましょう。

いずれ時間ができたら「WindowsXP時代のパラレルポート制御」ということで、まとめようと思います。

WindowsXPでパラレルポートを自分の物に！WarmPollの回避方法

WinXPのデバイスドライバparport.sysのソースを読んで、WarmPoll機能の回避方法を考えてみました。

WarmPoll機能が動いていると、パラレルポートの制御信号などが勝手にアクセスされてしまって、自分で作ったハードウェアなどに誤った信号を出力してしまうからです。

そこで、parport.sysのソースを読んで解析した結果を、次の図に載せます。ちょっと流れ意訳しているので、微妙に違うかもしれませんが。

このWarmPoll機能は、parport.sysというデバイスドライバが起動しはじめたところから始まります。
つまり、WindowsXPの起動とともに、WarmPollは潜伏を始めると考えていいでしょう。
parport.sysの起動時にはPptFfoStartDevice()という関数が呼ばれます。
PptFfoStartDevice()関数の中では、システムレジストリ
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Parport\Parameters
を読んで、DisableWarmPollというキーがゼロ以外になっていれば、WarmPoll機能は起動されません。

したがって、レジストリにDisableWarmPoll=dword:00000001を書く、というのも一つの解決方法です。

もし、DisableWarmPollが設定されていないと、PptFfoStartDevice関数はWarmPoll用にスレッドを作成します。

そして、そのスレッドが開始します。
まず、規定の時間、待ちます。
もし、バッテリ駆動であれば、WarmPoll機能は作動せず、スレッドはループを繰り返します。
ノートPCならバッテリ駆動にするというのも、解決策の一つではないかと思います。

そして、PptTryAllocatePort()という関数を呼び出して、ポートのアクセス権を取得しようとします。
ここで、アクセス権が獲得できなければ、パラレルポートへの出力は発生しません。

次に、GetStatus()という関数を呼び出します。
この関数で、パラレルポートが接続されていないとか、ケーブルがない、と判断されれば、パラレルポートへの出力は発生しません。

もし、何かがありそうだ、ということになれば、P4ReadRawIeee1284DeviceId()という関数を呼び出します。
この、P4ReadRawIeee1284DeviceId()が、勝手にパラレルポートへアクセスして悪さを引き起こしていると考えられます。

つまり、GetStatus()で何かがある、と判断されれば、P4ReadRawIeee1284DeviceId()を呼び出して悪さをするわけです。システムが暖まったころにポーリングを始めるので、WarmPollというのではないかなと推定されます。

このP4ReadRawIeee1284DeviceIdが呼ばれないようにするためには、バッテリ駆動にするか、TimeToTerminateThreadという値を設定するか、パラレルポートのアクセス権をWarmPollに獲得されないようにするのがよいでしょう。TimeToTerminateThreadは10回失敗すればセットされますが、10回失敗するまでには1分程度かかります。
したがって、「パラレルポートのアクセス権を獲得させない」というのが、最も正解に近いのではないかと思います。

WarmPollが起動するための関数、GetStatus()では何を調べているのか、
P4ReadRawIeee1284DeviceId()は何をしているのか、
そして、WarmPollにパラレルポートのアクセス権を獲得させないようにするには、どうすればよいか、ということは次回に書きます。

WindowsXPでパラレルポートが勝手にアクセスされる！？

WindowsXPで、パラレルポートが勝手にアクセスされるという不可解な現象に悩まされています。

私のマシンでは、WindowsXPを起動後、パラレルポートのコントロールポート(0x37a)に
書き込みを行うと、この不可解な現象が始まります。

最初、このポートの値は0x0cになっていますが、0x0eを書き込んでみると・・・
なぜか勝手に0x06に書き換わってしまい、その後0x0cになります！

一体全体どのプログラムが値を書き込んでいるのかは不明ですが、パラレルポートのAUTOFXINITとSLCTINという信号線が勝手にアクセスされてしまいます。
OSの何かが何かをしているのでしょうか・・

じっと見てみると、0x06→0x0c→0x06→0x0cという動作を、5秒周期で11回繰り返し、
約50秒間続けた後、この不可解な現象は収まるようです。

古いマシンでも、最近クリーンインストールしたマシンでも、同じ現象が起きてしまいます。デバイスマネージャで見ても、LPT1のプラグアンドプレイが有効になっているわけでもないですし。一体なんなんだろう。

XPでパラレルポートにアクセスするプログラムを作るときには、デバイスドライバから、
バスドライバ(?)のparport.sysにアクセスして、排他的制御権を得なければいけないのでしょうかね。
(DDKのコードを見て、パラレルポート関係を調べるは一苦労です・・)

ちなみに、Windows2000ではこの現象は起きません。