思い出したように勉強している AVR
やっとこさ割り込みの仕組みが理解できました。
ピン・チェンジ・インタラプトできました。うれしー。おもしろーい。
本読んでもいまひとつわからず、結局データシートと AVR Studio のエミュレータが一番助けになりました。
次はタイマ割り込みに挑戦です。
AVR エキスパートの皆様に笑われてしまうような話ですが。
Posted in制作記録
割り込み
Posted by
6
6
ちゃくちゃくですねー！
私は製作中のパルスジェネレータで初めてピン・チェンジ・インタラプト(PCINT)を使いました。いつもはタイマをひとつ周期的に回しっ放しにして押釦情報を採っているのですが、今回は通常 押釦用タイマを止めておいてPCINTでタイマを起動、チャタリング安定点で再評価(その後 釦リリースでタイマ停止)としました。
週末を目処にwikiにコードと回路図を掲載したいと思います。
コードはたいへん汚いです。というのも各種割り込みからの情報はFIFOに積んであって、メインループにて取得→動作状態の遷移をやっていて、メイン部分がむちゃくちゃ長くなってしまいました。
どうやったら読みやすいコードになるか、ganさんの意見をうかがいたいところであります。
Chuck さんコメントありがとうございます。
ピン・チェンジ・インタラプトでボタン検知開始という方法は洗練されていますよね。サーバプログラミングでいうリスニングに似てます。ちなみにタイマーぐるぐるもサーバプログラミングの中で意外とよく使われる技法でポーリングと呼ばれてます。
パルスジェネレータの記事わくわくです。
割り込み情報の扱いは、うーん、まだ実際に実用プログラムを組んだことがないぐらいの初心者なので意見なんておこがましいですが、状態遷移の制御はやっかいですよね。業でもたいていこの辺で苦しめられます。この辺はコード組む前にきっちり状態と遷移を定義して設計することが決め手のような気がします。コーディングのコツですと、状態変数と状態数は可能な限り減らす、状態値は極力コピーしない、などがすっきりさせるコツであります。どちらもデータを局在化させるためであります。状態が飛び散るとあわわ、収集つかない、となったりすることあります。（ああ、トラウマが…）
的外れに成っていなければ良いのですが。
ちなみに、文字コード変換（JIS から UTF とか）のコードなど、状態数が異様に多いのでどうがんばっても長大なコードになっちゃうようなものもあります。ものによっては不可抗力、というのもあるかもしれませんね。
ちょー、お試し版のコードを置いてみました。
http://www6.atwiki.jp/fx_geek/pages/51.html
どのように汚いのか と 割り込みはこんな感じ というのの参考になればと思い載せてみました。まだまだ変える予定ですが、とりあえず。
回路図はまだです。
仕事で書くソフトは文字列処理のスクリプトとかハード確認用のレジスタをたたく程度のコードなので、ソフトは本業ではないのです…
見ましたー。
良い機会なので WinAVR インストールしました。
うーむ、やはりCのほうがアセンブラよりはるかに読みやすいです。私も基本の動きを理解したらCに引っ越そう。
確かに状態が多く動きが複雑そうですね。
ボタンや UART などの複数種類の割り込みハンドリングがお互いに依存関係を持って動いているように理解しました。（あってるかな？）しかも状態によって依存しかたが変わるようにも。難しい課題なのですね。
state は動作モードに見えるので（STOP, RUN, EDIT など）、思い切って state はグローバルに参照できるプログラム全体の動作モードにしちゃって、イベントハンドラ （おおまかイコール割り込みハンドラ）が、モードにより動作を変えちゃう、なんて風にするやり方もあるかなー、と思いましたがどうでしょう？もしかしたら割り込みハンドリングの依存関係が減るかもしれないです。
コメントありがとうございます。
なるほど＞モードでイベントハンドラが変身。しかし頭が今のやり方で固くなっていて、ぱっとイメージが沸かないです。
今はメイン中で if ((c=keyGet()) != -1) … で判断している部分を、キー入力がバッファに積まれたらソフトウェア割り込みを発生させる、などもいいかもしれないと考えが広がりました。
構造的な不細工さはまだまだあるのですが、とりあえず、状態をデコードして呼べばいいだけの lcd_position が偏在しているのを直します。
落ち着いてコードをながめると、TとWの値更新がアトミックではないので、宜しくないです。次には直しておきます。