とにかくこの時点での救いは「開発機（ブレッドボード上）では問題無し！」って事だ。
つまり、まだ連装ロジックは組み込んでない（つまり複雑化していない）状態では、理屈は正しく正常作動している事だ。
それではこれからやるべき事を整理していこう。
おさらいとして、
・定期取得ルーチンは問題なし
・キャリブレーション割り込みは問題なし
・比較ルーチンも問題なし
なのだから、
@アナログ電圧を正確に取得出来る（余裕を持った）ロジックの考案
A最小化したプログラムでの十分なテスト
B試作機１号の基板（以下実装基板という）を使用したテスト
C専用基板の製作
となる。
前提で考えなければならないのが”割り込み速度”だと感じている。
そもそもアラームなのだから”コンマ何秒”ってな脅迫観念があるのだが、そこは十分余裕を持って”数秒”単位で考えてみよう。
要は「数秒後であっても確実に変異をチャッチすればよい」の感覚を自分で持つ事かもしれない。
また同時に連装ロジックも組み込みたい先走り感もあるのだが、ここはグッと堪えて３号機に実装しようと思う。
とにかく２号機は「単純アラームが実用に耐える作動をする完成品」を作る事に専念しよう！
今回の心気一転対策は４点。
T．ラッチングリレーの変更。
U．感光基板用ＣＡＤパターンの作成。
V．より一層のプログラム簡素化
W．感光基板の作成
T．ラッチングリレーの変更
リレーをＧ６ＣＫからＧ６ＡＫに変更した。
正直１回路でよかったのだが、左右で接続出来る事が回路製作を容易にすると判断。
また別件だが、レギュレータ（ＴＡ４８０５Ｓ）は、正規にはＩＮＰＵＴ側に０．３３ｕＦを、ＯＵＴＰＵＴ側に０．１ｕＦ＋４７ｕＦのコンデンサが必要なのだが、秋月電子のパッケージには０．３３ｕＦは入っていない。
聞いてみると、ＩＮＰＵＴ側に０．１ｕＦを、ＯＵＴＰＵＴ側に４７ｕＦで十分である事が判った。
よって設計回路からも０．３３ｕＦを外した。
U．感光基板用ＣＡＤパターンの作成。
前回の試作品の誤動作はプログラムの時間設定が現実とそぐわない為に起きた現象だと判っている。
しかし既製のプリント基板では半田が汚い！のと取り回しが汚い！事から誤動作撲滅の為にもパターン作成を行なおうと考えた。
数十年ぶりに調べてみると、どうも様子がおかしい。
かつてのシールとラインテープの記事が少なく、代わりに「感光」「ポジ」といった言葉が飛んでいる。
どうも最近はマーカーを付けてエッジングするのではなく、ＣＡＤを使ったパターンを露光して焼付けエッジングする工程に変わりつつあるらしいのだ。
ん？目新しい？・・・・い、いかん・・・触手が動いてしまうではないか・・・・！
３５年前に写真部の現像班で暗室に篭っていた記憶が・・・・酢酸がぁ！（違うか！？）・・・！
ってな訳で揃えてしまった感光基板製作用具一式！
@ＣＡＤソフトの入手＆使い方
AＣＡＤでパターン製作
B露光（感光基板に焼付け）
C現像（停止・定着は無いらしい）
Dエッジング
Eフラックス
と、どうなるか楽しみぃ〜♪
@ＣＡＤソフトの入手＆使い方
当然のようにフリーソフトで溢れている。
なんとも便利な世の中だよ。
機械設計屋だった頃（２５年前）はまだ武藤工業のドラフターを使っていたが、丁度ＣＡＤ／ＣＡＭが出始めた頃で、専用のシステムとソフトで一台３００万円くらいはしていた。
だからＣＡＤ課なんてあったくらいで専門職の領域だったのよ。
それが今日では普通のパソコンにフリーソフトをダウンロードすれば、版下業者に発注出来る品質の図面が出来てしまうのだから驚かざるを得ないよね。
いろいろググッてみると、どうもＰＣＢＥという言葉が多かった。
それがパターン製作ＣＡＤ ＰＣＢＥだ。
早速ダウンロードして使ってみる。
”使ってみる”とは、適当に弄ってみて判り易いか？を見極める為で、これぞ人間工学的な根本である。
ソフト制作者は作り手のエゴで作ってはいけない。
何が客を引き寄せるのか？を考えて設計する事が重要だからだ。
結論！
よく出来てる！素晴らしい。
まぁ、どうせ電子回路の設計など未経験なのだから、これから不具合も出てくるだろうが、取り敢えずこれにしよっと！
AＣＡＤでパターン製作
ＨＰを参照しながら奮闘する事２日。
なんて便利なんだ！
すっげ〜よ！これ！
何かそれらしく出来てきたよ。
何が気に入ったって、
ライブラリ（パーツ）が自分で作れる！
ファイルがテキストで編集出来るので、
最初はそれに取り組んだが、途中で、
「あれ？これって作画して登録すればいいじゃん！」
に気がついてしまった！
それからはもう作り放題！
で、他との互換は無視して自分流の定義を設けた。
@２．５４ｍｍ以外のパーツは捨て！
A使わない難しいパーツは捨て！
Bレイヤーの独断設定
レイヤー０（白）：外枠
レイヤー１（赤）：パターンと半田ランド
レイヤー２（桃）：シルクパターン
レイヤー３（水）：部品半田足ランド
レイヤー４（黄）：部品外観
レイヤー５（緑）：部品説明
レイヤー６（茶）：ジャンパー
レイヤー７（深水）：マスク領域
約一週間使ってみた時点でこのソフトに不満が湧いてきた内容。
・ＵＮＤＯが出来ない！結構ムカつく。選択＆削除を間違えた場合最初からやり直し！致命傷じゃ！
・カット＆ペーストや移動モードなどがボタンだけ。目線の移動が激しい。ショットカットが必要じゃ！
・変更箇所の複数選択が出来ない！一つ一つやり直しがムカつく！
・同じパーツ名はライブラリで上書きせんかい！
ってな事。
まぁ、でもパーツの作成も含めて一週間で製作できるなら大満足です。タダだし。
これで導通チェッカーなんぞシミュレートしてくれると嬉しいのだが贅沢か・・・。
【またやってしまった・・・・】
とにかくちょっとでも気を抜くとすぐにだんまりを決め込む電子部品。
半年ぶりにブレッドボードを触るもＬＥＤが点滅しない。
電源供給を確認しようとプラスとリレーをショートさせてみる。ＯＫだ。
ＰＩＣ１６Ｆ８８をＰＩＣｋｉｔ２に載せると「電圧異常エラー（VDD voltate line error）」が出て認識しない。
あれ？と考えてみると、プラスは１２Ｖだったじゃん！
あ〜ぁ・・・・また壊してしまった・・・・・（泣）
このいい加減な性格は治らないのだろうから、ブレッド上で１２Ｖを扱うのはもう止めよう・・・・。
最後の在庫を使う事になってしまった。また買ってこなければ・・・・。
【さらに燃えてるよ！・・・・】
落ち込みながらブレッドのマイナスを左右結合させるジャンパーを付ける。
途端にＫＸＭ５２から煙が上がる！
え？何？・・・・・わっ！マイナスのジャンパーをプラスに差してるよ！
バカさ加減にうんざりしながらも「死んでませんように！」と祈りながら、テスト回路の追加を行なう。
ＡＤＭ３２３２（ＲＳ−２３２Ｃコントローラチップ）を取り付けパソコンへ。（何て余計な手間をかけるんだ・・・）
通信してみると・・・・・数値が全く動いていない・・・・・三軸加速度センサーは完全に燃えていた・・・・・。
これ一個８００円だぜ・・・・いや、今確認したら１０００円になってる・・・・！
も〜・・・・・・こんな事でお小遣い減らしてどうするよ・・・・最低！＞オレ！
（翌日の月曜日）
買ってきたさ・・・・ちょろっと会社抜け出して秋月電子まで徒歩１５分の散歩・・・・ＰＩＣ１６Ｆ８８も２０円上がって２００円になってるし・・・・。
セットしてみると半年ぶりに動いているのを確認。
８ビットにしちゃったもんだから数値が１０ビット（の上位８ビットの値）に比べて１／３近くまで落ちている。
しかし全く安定して稼働している。ここまでは前回と同じ。
さて、ここからだ。
ＲＳ２３２−Ｃモジュールを取っ払い、プログラムもショートカットさせて稼働させてみる。
ふむ。やはり１分に１回程度誤作動を起こしている。完全に再現しているな。
ちょっと休憩・・・・・
余りに部品が煩雑になってきたので整理する箱が欲しいとは思っていた。
百均に行ってみるが引き出し式の小箱は見当たらない。
帰りに女性もののファンシーショップがあったので覗いてみると、真にピッタリの箱見っけ！
ミッキーとマリーとステッチの３種類を購入・・・・・。
５００円／個也。
なんか良くね・・・・・♪
休憩終わり・・・・
黙って様子を見ていると、どうもアベレージの採取の段階で異常値を設定してしまい、そのＡＶＥを基準に正常値を判断するからエラーになるようだ。
しかしシリアル通信のような余計なルーチンを通過させると全く問題が無い事から、やはり、
@アナログ採取値の保存を個別に行なう
A平均化の前にアッパー値とロワー値の削除を行なう
Bさらに前回ＡＶＥから規定範囲を超えたものも除外する。
C平均化する。
という純粋培養の値が必要なようだ。
そしてこのルーチンを明確にプログラムするには絶対的に配列が必要だと思っている。
いや、配列無しでも可能ではあるが、膨大になるアセンブラでは飽きがくると気がついている。
やはりＣ言語化が必要だな。
昨年もＨＩーＴＥＣＨ社のＰＩＣＣを使ってみたかったのだが価格が８万円！？
アホか！・・・・いや、システム屋としては職業で使うなら安い言語だとは思っている。
しかし趣味で調達は出来ない。
無料のライト版があったが、使用出来るチップ一覧に「１６Ｆ８８」が無かったのだ。
要するに「一番汎用出来るＣＰＵを使いたければ買え！」なのだ。
やっぱアセンブラか・・・・・になる訳だ。
ところが、昨年の後半になって、ＨＩーＴＥＣＨ社がＭＰＬＡＢのマイクロチップ テクノロジー ジャパン社に吸収されると、バージョンアップの時点でライト版が消滅。
代わってＰＲＯ版のライトバージョンが出来て、そのラインナップに「１６Ｆ８８」が存在するのだ！
やった！これで無償でＣ言語に移行出来るぞ！と思っていた。
今回のシステムが完成したら移行する予定だったのだが、ここへ来て早く（強制的に？）実現するハメになりそうだ。
そこで「プログラムの簡素化」の意味を「凝縮したアセンブラにする」から「Ｃ言語への移植」と変更しようと思う。
ＨＥＸ的にはコンパイルの関係で恐らく２倍以上に膨れるだろう。
しかしロジック的にはメチャメチャ明確化出来るのでステップ数は大幅に減少するハズだ！
V．Ｃ言語への移行（「V．より一層のプログラム簡素化」を改変）
先ず最初に企業合体したＭＰＬＡＢに標準で載っているＰＩＣＣを手に入れる為にＭＰＬＡＢのバージョンを８．３３から８．４３へ上げる。
インストール時にカスタムインストールでＰＩＣＣも選択する。
ＰＲＯ版だがライトモードを選択する必要がある。
【プロジェクトの作り方】
@StepOne
アセンブラと同じ。
「ProjyectWizerd」からチップを選択する。（ここの冒頭を参照）
AStepTwo
「HI-TECHのC Compailer」を選択する。
へぇ〜！
「ANSI C」なんだ！
数十年ぶりにお目に掛かったが、こんな処で生きていたのか！
超嬉しい！
BStepThree／StepFour／Summaryはアセンブラと同じ。
CＦｉｌｅ⇒Ａｄｄ Ｎｅｗ Ｆｉｌｅ ｔｏ Ｐｒｏｊｅｃｔ
を選択してプロジェクト名と同じ名前のファイルに「．Ｃ」を付け加えて「保存」
以降はアセンブラと同じだが、Ｖ８．４３では、「Ｂｕｉｌｄ ＡＬＬ」から「Ｂｕｉｌｄ」になっている。
ちょっと駆け足で進めてしまったが、pic.htmlを見て頂ければ同じ内容があるので参照されたい。
８８が無い！
勇んでその辺のソースをコピペするもエラーの嵐！でコンパイルまで行かず。
やっぱり「HelloWorld」からかぁ？（泣）
まぁ、シンタックスに関してはＡＮＳＩだからそのうちに思い出してくるだろうけど、さすがにハード（ＣＰＵ）ベッタリのマイコン。
アセンブラで使ったレジスタの知識が無きゃ全く判らんかった。
やっぱアセンブラから入って正解だったかも。
先ずは、擦り込み１番は”PORTA=0x00”だった。
ポツネンと書いてある。
え〜？バンク切り替えしなくていいの？
何の前戯（？）も要らないの？スゲ〜！
試しにビルドしてみる・・・・出来た！
このＶｅｒからコンパイル時にメモリサマリが表示される様になったようだ。
解りやす！すごいぞ！
続けてＰＩＣＫｉｔ２で書いてみる。
をっ！
「このＨＥＸにはコンフィグが書かれてません」エラー。
当たり前か。
で、ＡＳＭの記述をそのままコピーしてみる。
「そんな命令はありません」エラー。
なるほど。
で？どうやって書くの？
ネットで調べるも無い！？
そっか、まだ８８が使える様になって日が浅いから記事になってないんだ！
ちょっと焦ってくる。
いろいろググっていると、
「includeの中にあるpic16f88.hは〜〜」
と書いてあった。
なるほど、サンプルでもあるのかな？とinludeファイルを覗いてみるが「８８」が無い！
「８７」の次が「８８７」なのだ。
え〜！？無いじゃん！
さらにいろいろググってみたが見当たらない・・・・・。
ふざけんなよ！？
８８が使えるって事でここまで来たのに！
ムカつきながらpic16f87.hを開けてみると、
/* header file for the MICROCHIP PIC microcontrollers
PIC16F87
PIC16F88
*/
と記述されてる。
なんだよ！「８７」と「８８」兼用で「８７」ってファイル名かい！
優しくねぇ〜なぁ〜・・・・・。
そこには、
・レジスタで使用するレジスタ名を「unsigned char」でアドレス指定
・その中のステータスで使用するステータス名を「bit」でアドレスシフト指定
した記述が並んでいた。
それらが全て「#defined」で定義されているので、Ｃ言語ではダイレクトに名称を扱えるのだった。
で、コンフィグレーション・ビット定義は一番下に記述されている。
しかしアセンブラと似てはいるが、ちょっと違う名称が並んでいる。
しばらく見ていて気がついた。
「ケツのＥＮとＤＩＳはｅｎａｂｌｅとｄｉｓａｂｌｅの事だ！」
だとしたら「_WDT_OFF」は「WDTDIS」と書けば良いのでは？（って何でそんな解析から入らにゃならんのよ！）
あっ、アブナイ「ＭＣＬＲ」発見！
出来れば記述したくない。
あれ？デフォルトはどっちよ？
書いたら勝ち？負け？書かない方が良かった！ってハメに陥りたくないし・・・。
またジッと見ていると、ＥＮとＤＩＳが内容によって前後して書かれている。
「あっ！判った！先頭がデフォルトだ！」
だから、
#define PWRTDIS 0x3FFF
#define PWRTEN 0x3FF7
とあったらＯＦＦがデフォルトだ！（たぶんあってると思う・・・・）
アセンブラで敢えて記述していた内容をピックアップしてコンフィグにしてみる。
で、焼こうとしたら、
「幾つかのコンフィグ情報がＨＥＸの中にないけどデフォルトで行っちゃうよ！」と警告が出る。
う〜ん・・・・気にしないで焼いてみる。
通電すると・・・・ＬＥＤが光った！
よしよし、ここまで順調だ。（なんかかなり前まで戻ってる様な気もするが・・・・）
ちなみにそのソース（↓）
-------------------------------------------------------------------------
#include<pic.h>
__CONFIG(UNPROTECT & LVPDIS & WDTDIS & PWRTDIS & BOREN & FCMDIS & IESODIS & INTIO & RCIO & BORDIS &DEBUGEN);
int i;
int n;
void main(void){
OSCCON=0x70; //内部クロックを８ＭＨｚで使う設定
TRISA=0x00; //全部出力
for(n=0;n<5;n++){
RA2 = 1;
for(i=20000;i>0;i--);
RA2 = 0;
for(i=10000;i>0;i--);
}
}
-------------------------------------------------------------------------
「OSCCON」なんか勘だけで「これで行けね？」で書いてみたら上手く行っちゃったよ。
こりゃ便利だぞ！Ｃ言語！
しかしここでちょっと不安が過ぎる。
PIC16F87.hにはレジスタの全てが変数に収まっている様に思える。
だから単にレジスタ名を書くだけで反応してくれるのだが、逆に言えば「それって予約語って事じゃん！」になる。
つまり、やたらに変数名を記述出来ないって事だ。
コンパイル時に何かしらの警告が出るのだろう？と思ってもみたが、そもそも予約語だったら間違って記述しても正しいと見なされる。
例えば”ADON（アナログ／デジタルＯＮ）”はＡＤ変換用の充電開始命令だが、自分で「数値の上乗せ変数をADON（アドオン）と命名しよう！」と決めたら、
ADON=1;
とか、やりそうだ。
しかしコンパイラは「ここで充電を開始するのだな！」と思ってしまい、別にエラーにはならない。
だからソース上で自分が命名する変数名は絶対に被らないほど変な（？）名前でなければならないのではないだろうか？
怖いので長めの独特なものにしよう。
じゃ、早速真面目に作ろう。
OSCCONは初期設定だからmain外。
でも逆にＣ言語は他言語の様にmain外から直接call出来ないから実際にはソースはこうなる（↓）
-------------------------------------------------------------------------
#include<pic.h>
__CONFIG(UNPROTECT & LVPDIS & WDTDIS & PWRTDIS & BOREN & FCMDIS & IESODIS & INTIO & RCIO & BORDIS &DEBUGEN);
int i;
void init(void){
OSCCON=0x70; //内部クロックを８ＭＨｚで使う設定
TRISA=0x00; //全部出力
}
void main(void){
init();
@
}
-------------------------------------------------------------------------
@は、
while(1){
for(i=10000;i>0;i--);
RA2 = 1;
for(i=20000;i>0;i--);
RA2 = 0;
}
又は、
Loop:
for(i=10000;i>0;i--);
RA2 = 1;
for(i=20000;i>0;i--);
RA2 = 0;
goto Loop;
-------------------------------------------------------------------------
「pic.h」はおそらく全てのチップ情報への飛び先指定なのだろうから「pic16f87.h」だけあれば良いのだと思うのだが、まだテストはしない。
また、昔は先輩に「Ｃ言語でgoto使う奴はカスだ」と教えられたものだが、アセンブラでは当然の様に使う訳で、現在では余り言われないようだ。
ちょっと休憩・・・・・
今日、帰宅途中の百均に「ＡＫＩ−ＰＩＣ２プログラマボード」を収める箱を買いに寄ってみた。
だって、今まで何気に裸で使っていたけど、これショーットしたらお小遣い無くなるよな・・・って思ってさ。
百均ってなんて便利なんでしょう！
さっそく固定開始。
ドリル出すのが面倒だったので、ビニールだから木ネジで無理やり穴あけ。
カッターでＵＳＢ用の穴を開けておしまい。
事前に「千石電商」（秋月電子の隣）で買っておいた両面テープのゴム足（１５円／個）を付けて・・・・。
簡単なんだからもっと早くやれよ！
休憩終わり・・・・
ＰＩＣＣのタイマー管理
ＡＳＭではＴＭＲ１を使った割り込みロジックが必要であり面倒なので後回しにしていた。
ところが、ＰＩＣＣでは内部関数として、
__delay_ms(ミリ秒)
__delay_us(マイクロ秒)
という関数を持っているらしい。
includeディレクトリの中のhtc.hをincludeしてやるとそのまま使えるようだ。
条件としては最初に周波数の宣言を行い、
#define MHz 000000
#define _XTAL_FREQ 8MHz
のように記述する。（おまじないで良いでしょう）
また、
最大取り扱い時間（x） = (1 ÷ 動作周波数Hz) x 4(サイクル) x 98560(最大取り扱いサイクル数)
なので、msの場合はint(x/1000)らしい。
| 周波数 | 最大時間 | ミリ秒の記述 | ナノ秒の記述 |
| 20MHz | 39,424us | __delay_ms(39) | __delay_us(39424) |
| 16MHz | 49,280us | __delay_ms(49) | __delay_us(49280) |
| 10MHz | 78848us | __delay_ms(78) | __delay_us(78848) |
| 8MHz | 98560us | __delay_ms(98) | __delay_us(98560) |
| 4MHz | 197120us | __delay_ms(197) | __delay_us(197120) |
１６Ｆ８８の内部クロックは８ＭＨｚだからミリ秒で固定すると９８ｍｓ。
これはもう１００ｍｓでいいんでない？超正確を求めるロジックでもないし。
って事はこの内部関数を１０回まわせば１秒って事だ。
で、ソースはこうなる。（↓）
-------------------------------------------------------------------------
#include<pic.h>
#define MHz 000000
#define _XTAL_FREQ 8MHz
#include<htc.h> //順番変えちゃダメ！
int i;
int TimerCount;
void Timer_GO(int TimerCount){
while(TimerCount--){
__delay_ms(98);
}
}
void init(void){
OSCCON=0x70;
TRISA=0x00;
}
void main(void){
init();
MainLoop:
for(i=0;i<5;i++){
RA2 = 1;
Timer_GO(5); //98≒100ms単位で指定（0.5秒だったらTimerCount=5）
RA2 = 0;
Timer_GO(5);
}
goto MainLoop;
}
-------------------------------------------------------------------------
ひゃ〜！こりゃ便利だ！
も、もしかして・・・・こんなんが一杯あんのかぁ？（ワクワク！だからＣ言語やめられねぇ〜！）
【シリアル通信のヒラメキ】
アセンブラのシリアル通信の手順は、
@値の取得
Aビットシフトによる桁の取り出し
B＋０ｘ３０によるキャラクタ化
C一文字送信
だった。
しかしＣ言語だよ！
何かもっと他に方法があるべぇ・・・・と探してみると”sprintf()”があった。
include stdio.h
懐かしい設定・・・・しかし全く動かない。
悩むこと３日・・・・どうも”ANSI C”としては問題ない文法だが、PICに載せるには何かいろいろと別ルーチンの作成が必要なようだ。
だったらこんな重たいヘッダーファイルをインクルードしてまで使いたくないなぁ〜。
何か方法は無いか？と探したら”math.h”を使う事で”fmod”が使える事が判った。
つまり欲しい桁を小数点第一位に除算してその値を変数に代入すれば得られる訳だ。
このヘッダーも重いがそれでもこれだけで実現出来そうなので決定！
送信は一文字送信として諦める。
@値の取得
Afmodによる桁の取り出し
B＋０ｘ３０によるキャラクタ化
C一文字送信
となる。
【怪奇現象のわけ】
さてある程度組み込んだところで怪奇現象が発生。
ブレッドボードの台を触るとプログラムが暴走するのだ。
当然「リーク＆接触不良」というハード面を疑う。
しかし考えてみたらこのハード構成でアセンブラでは問題なく稼働していたのだ。
まぁ、でも触って暴走じゃハード以外に有り得まい・・・・って事で、バラして組み立てて・・・・を数回繰り返す。
しかし現象は治まらない。
それどころか思わず吹き出してしまう現象を発見！
台を外して・・・つまり金属レスにしても触ると暴走・・・・さらには触らなくても指を近づけるだけで暴走・・・。
え？なに？あたしってばマリックさん？或いは、いつの間に熱感センサー組み込んだんだっけ？
その不思議な現象は必ず再現する事からちょっとしたマジックを見てるよう・・・・。
ハードを１０回ほど組み直してからやっと諦める。
「これ・・・ソフトかなぁ・・・・？」
ソフトだとしたら不安定要素＋指先静電が暴走させてる？？？・・・そんな事あるのかぁ・・・・？？？
とにかくアセンブラとの違いは、いい加減なプログラムしかない。
ってか、どこにも参照が無いのでアセンブラ記述をＣ言語風に書いている。
その最たる記述は「コンフィクレーション・ビット」だ。
真面目に取り組もう。
もう一度”PIC16F87.h”を見ながら、以前から気になっていたライティング時の「Some configuration words not in hex file」を撲滅してみようと決心。
上から順番に辿っていく。
====================================================================================================
// Protection of program code
プログラムソースを見られないようにするか？
-----------------------------
#define PROTECT 0x1FFF
#define UNPROTECT 0x3FFF
-----------------------------
これは「UNPROTECT」
// CCP1 Pin selection
キャプチャモード時のＣＣＰピンの設定
-----------------------------
#define CCPRB0 0x3FFF
#define CCPRB3 0x2FFF
-----------------------------
未使用だから使っていないRB3=CCPRB3を指定
// In-Circuit Debugger Mode
デバッグ用ピンを設定するか？
-----------------------------
#define DEBUGEN 0x37FF
#define DEBUGDIS 0x3FFF
-----------------------------
使わないから「DEBUGDIS」
// Flash Program Memory Write Enable
フラッシュメモリを書き込む場所を指定するか？
-----------------------------
#define UNPROTECT 0x3FFF
（どこでもＯＫ）
#define WP0 0x3DFF
（0000h〜0FFFhの範囲でＯＫ）
#define WP1 0x3BFF
（0000h〜07FFhの範囲でＯＫ）
define WPA 0x39FF
（0000h〜00FFhの範囲でＯＫ）
-----------------------------
これは「UNPROTECT」
// Data EE Memory Code Protection
ＥＥＰＲＯＭ書き込み禁止にするか？
-----------------------------
#define UNPROTECT 0x3FFF
#define CPD 0x3EFF
-----------------------------
これは「UNPROTECT」
// Low Voltage Programming Enable
低電圧ＰＧする為にＲＢ３をＰＧＭに指定するか？
-----------------------------
#define LVPEN 0x3FFF
#define LVPDIS 0x3F7F
-----------------------------
しないから「LVPDIS」
// Brown out detection enable
電圧が落ちた時にリセットするか？
-----------------------------
#define BOREN 0x3FFF
#define BORDIS 0x3FBF
-----------------------------
しないから「BORDIS」（後にするの実験が必要）
// Master clear reset pin function
ゼロＶでリセットさせるか？
-----------------------------
#define MCLREN 0x3FFF
#define MCLRDIS 0x3FDF
-----------------------------
させるから「MCLREN」
ってか、絶対に「MCLRDIS」にしてはいけない。
ＰＩＣ２で書き込みが出来なくなるバクがある。
注意！！
// Power up timer enable
電源ＯＮから72ms後にＰＧを稼働させるか？
-----------------------------
#define PWRTDIS 0x3FFF
#define PWRTEN 0x3FF7
-----------------------------
必要だと思うから「PWRTEN」
// Watchdog timer enable
ウォッチドグタイマー（プログラム暴走自己診断）をするか？
-----------------------------
#define WDTEN 0x3FFF
#define WDTDIS 0x3FFB
-----------------------------
今はしないから「WDTDIS」だが、絶対に必要だと思うから保留。
// Oscillator configurations
発振子の場所と周波数はどうする？
-----------------------------
#define RCCLK 0x3FFF
（外部ＲＣ：RA6はClockOut、RA7をI/Oで使いたい）
#define RCIO 0x3FFE
（外部ＲＣ：RA6/RA7をI/Oで使いたい）
#define INTCLK 0x3FFD
（内部：RA6はClockOut、RA7をI/Oで使いたい）
#define INTIO 0x3FFC
（内部：RA6/RA7をI/Oで使いたい）
#define EC 0x3FEF
#define HS 0x3FEE
（外部水晶発振：４ＭＨｚ〜２０ＭＨｚ）
#define XT 0x3FED
（外部水晶発振：２００ＫＨｚ〜４ＭＨｚ）
#define LP 0x3FEC
（外部水晶発振：〜２００ＫＨｚ）
-----------------------------
内部クロック使用でRA6もRA7も使いたいから「INTIO」
// Fail Clock Monitor Enable
外部クロックのバックアップで内蔵クロックを使うか？
-----------------------------
#define FCMEN 0x3FFF
#define FCMDIS 0x3FFE
-----------------------------
関係ないから「FCMDIS」
// Internal External Switch Over
外部クロックに内蔵クロックを併用するか？
-----------------------------
#define IESOEN 0x3FFF
#define IESODIS 0x3FFD
-----------------------------
関係ないから「IESODIS」
====================================================================================================
って事でコンフィグレーションの設定は、
__CONFIG(
UNPROTECT & CCPRB3 & DEBUGDIS & UNPROTECT & UNPROTECT & LVPDIS &
BORDIS & MCLREN & PWRTEN & WDTDIS & INTIO & FCMDIS & IESODIS
);
となる。
でも物理現象に関してソフトウェアって事に否定的な自分としては５０／５０で接続してみる。
あれ？・・・・・治ったよ・・・・・何で？・・・・・？？？
無理やり理屈付けるならば、
・コンフィグレーション（のどれか）の不備によってプルアップ不安定のまま（たまたま）稼働していた。
・指を近づける事によって静電作用が発生しマイナス電圧が生じて暴走を始めた。
とでも解説しなきゃ飲み込めないよ・・・・。
改めて「たかが設定」の恐ろしさを知ったのでした・・・・。
【それでも恐怖におののくわけ】
さぁ、ここまできたら後はプログラミングだけじゃん！
基本ロジックさえ安定動作すれば後は付け足していくだけだもの！
先ずはアベレージ・ルーチンから。
配列のお影でものの数分で完成。だって、
@配列をループして最大値と最小値を求める。
A同一値である可能性が高いので「最大値（最小値）＋初回のみ」を除いた配列を加算・除算する。
だけだもの！
コメントアウトも含めて３０ＳＴＥＰ程度。
コンパイルするとプログラムメモリの使用率が８４％を示している。
えっ？このルーチン作る前は６５％だったよな。
どういう事？
まぁ、気にせず続けよう。
次にコンペア・ルーチン。
これも配列順に最大値と最小値の比較をするだけ。
コメントアウトも含めて１５ＳＴＥＰ程度。
ところがここでプログラムメモリの使用率が９４％を指示している。
「ウソだろ！？もう書けないじゃん！たった５０ステップ追加しただけだぜ！？」
腹の立つ事に、その下には「ちゃんとお金払えばこんなに小さく出来るのにねぇ〜」と書いてある。（→）
コアの部分はほぼ完成ではあるが、
@設定値のＥＥＰ化（任意変更を可能にする）
A再帰アラームのロジック組み込み
B複数アラームのコントロール
Cアラーム・ログのＩＮ／ＯＵＴ
など、機能を追加しなければ魅力的でないのだよ。
ざっと見積もっても、現在（約２５０ＳＴＥＰ）の３倍は必要だ。
アセンブラでのコンパイルではこの時点で約２０％の使用率。
やっぱ段違いに小賢しいリンクと処理が動いている様だ。
（だからいつまでたっても低級言語に属せねぇ〜んだよ！）
冗談じゃね〜ぞ！・・・・と、いろいろ調べてみるが、
@アセンブラに戻る。
Aお金を出してコンパイラを買う。
B大容量のＩＣに変更する。
C機能を制限して我慢する。
の選択肢しかないようだ。
@無理！やっぱ配列の使い勝手は強烈！ヤダ！
Aヤダ！こんな挑発的な事書かれたら意地でも買ってやんない！（５万円だし・・・・）
Bこれは有り。ライターさえ対応していれば問題ないと思うが、その前にＩＣの基本構成を一から理解する必要アリ。
Cう〜ん・・・・・・。
結論としては、
@現在のソースを徹底的に絞って最小構成でとにかく完成させる。
A完成後にチップを変えて追加機能を補うバージョン構成にする。
としよう。
早速、実践では不要なモニタリングのスリム化に取り組む。
最小で認識出来るように纏めてこんなにした。（→）
最初の５つは実測値、６番目は平均値、７番目は上限値、８番目は下限値を表している。
これでプログラムエリアの使用率を８４％まで戻す事に成功。
次にコンペア・ロジックのＸ軸／Ｙ軸ルーチンを共有化して記述を減らす。
これで８０％まで落とす。
最後に、何気に使っていた領域確保の撲滅に取り組む。
改めてデータ型を気にしてみると、
| bit | 1bit | |
| char | 8bit | 整数 （ちなみに文字型は無い） |
| unsigned char | 8bit | 符号無し整数 |
| short | 16bit | 符号有り整数 |
| unsigned short | 16bit | 符号無し整数 |
| int | 16bit | 符号有り整数 |
| unsigned int | 16bit | 符号無し整数 |
| long | 32bit | 符号有り整数 |
| unsigned long | 32bit | 符号無し整数 |
| float | 24bit | 浮動小数 |
| double | 24bit 32bit | 浮動小数 double=24（24ビット） double=32（32ビット） |
| void | なし | なし |
１０ビットデータを扱っているのでどうしてもｉｎｔ型を多様する事になるが、それでも絶対に２５６（１０）を超えない、例えばフラグだとかループだとかの変数を全てｃｈａｒ型に変更する。
このようにY_Aveに対してMLは領域的には半分になるのだから、こまめに設定が必要だろう。（→）
全ての変数を見直し、同時に計算に組み込める変数は省略するなど、絞れる領域と文字数を徹底的に見直した結果、使用率７４％まで落とす事が出来た。
ともかくこれでコア機能の完成までは耐えてくれそうだ。
【ウォッチドッグタイマの組み込み】
コアのみとはいえ、外で日常的に使うのであれば最低のエラー処理は必要。
@暴走してアラームが鳴りっぱなしになった時の為の物理スイッチ。
Aシステム停止時の再起動
何らかの要因でシステムが機能しなくなった場合、そのまま翌日の朝・・・・では意味がない。
よってＷＤＴ（番犬）を組み込む事にする。
前回やった”OPTION”と”INTCON”の設定をしようとＨＰを確認していたら”WDTCON”を発見。
あれ？こんなの８８にもあったんだ・・・・とデータシートを眺める。（Ｐ１４１参照）
ＷＤＴは自己起動しなければならないからオシレータとは別に内部の独自クロックで動く。
３１．２５ＫＨＺで稼働し、１６ｍｓでオーバーフローして再起動を掛けるらしい。
ＷＤＴＣＯＮ
| 7bit | 6bit | 5bit | 4bit | 3bit | 2bit | 1bit | 0bit |
| 未使用 | 未使用 | 未使用 | WDTPS3 | WDTPS2 | WDTPS1 | WDTPS0 | SWDTEN |
SWDTN：
１：WDTスタート
２：WDTエンド（クリア）
この設定のみで動くらしく、逆に”INTCON”の「割り込み許可」や＿＿CONFIGの”WDTEN” などを指定していまうと、このWDTCONを無視して動いてしまうので一切触ってはいけない。
つまりWDTの作動はこの”SWDTEN”だけでＯＮ／ＯＦＦを制御する。
当然プリスケーラに対応していて、WDTPS3〜WDTPS0がそれに相当する。
| WDTPS3 | WDTPS2 | WDTPS1 | WDTPS0 | 倍率 | 参考時間 |
| 0 | 0 | 0 | 0 | 32倍 （初期値） | 16ms |
| 0 | 0 | 0 | 1 | 64倍 | 32ms |
| 0 | 0 | 1 | 0 | 128倍 | 64ms |
| 0 | 0 | 1 | 1 | 256倍 | 128ms |
| 0 | 1 | 0 | 0 | 512倍 | 256ms |
| 0 | 1 | 0 | 1 | 1024倍 | 512ms |
| 0 | 1 | 1 | 0 | 2048倍 | 1s |
| 0 | 1 | 1 | 1 | 4096倍 | 2s |
| 1 | 0 | 0 | 0 | 8192倍 | 4s |
| 1 | 0 | 0 | 1 | 16392倍 | 8s |
| 1 | 0 | 1 | 0 | 32768倍 | 16s |
| 1 | 0 | 1 | 1 | 65535倍 | 32s |
「参考時間」としたのは、あくまでも周波数から算出した理論値らしい。
実際に割り込みが発生してからLEDを点灯させたりピンを操作したりすると待ち時間としてはこの８倍にもなる。つまり、
| WDTPS3 | WDTPS2 | WDTPS1 | WDTPS0 | 倍率 | 待ち時間 |
| 0 | 0 | 0 | 0 | 32倍 | 125ms |
| 0 | 0 | 0 | 1 | 64倍 | 250ms |
| 0 | 0 | 1 | 0 | 128倍 | 500ms |
| 0 | 0 | 1 | 1 | 256倍 | １秒 |
| 0 | 1 | 0 | 0 | 512倍 | ２秒 |
| 0 | 1 | 0 | 1 | 1024倍 | ４秒 |
| 0 | 1 | 1 | 0 | 2048倍 | ８秒 |
| 0 | 1 | 1 | 1 | 4096倍 | １６秒 |
| 1 | 0 | 0 | 0 | 8192倍 | ３２秒 |
| 1 | 0 | 0 | 1 | 16392倍 | １分 |
| 1 | 0 | 1 | 0 | 32768倍 | ２分 |
| 1 | 0 | 1 | 1 | 65535倍 | ４分 |
と、最大にすると約４分間も帰ってこなかった。
余りにも掛け離れているので調査したが「いい加減」程度しか記載がなく、計算ロジックに違いがあって「参考時間」は別物の考えた方がよい。
そこで実測値（具体的にはリセット時に初期設定でLEDを光らせる）を持って値とした。
アラームを何秒鳴らしたいか？によって、それより長い時間をとっておく必要がある。
ここでは３０秒間鳴らすとして、１分間毎に番犬を走らせる事にした。
具体的なプログラムは、それぞれを個別に指定せずに
WDTCON=0x07; //00000111
などとして、クリア時のみ
SWDTEN=0; //WDT停止
Timer(1) //時間稼ぎ
SWDTEN=1; //WDT稼働
とする。
【設定ボタンの作成】
やっぱ設定は必要だよ。
実はもう人柱を頼んでいるのだが遠方の人で、ちょっとソースを直して渡す事が困難。
・斜傾感度の変更
・アラーム動作時間
の２つはあった方がいいかもな。
この時点でのプログラムエリア使用率は７６％、まだいけそうだ。
@仕様
余り設定値が細かいと操作が面倒になるだけなのでザックリと。
斜傾感度の変更
・要は上下限値の範囲なので、４段階のサイクルとしよう。
・スイッチを押す度に４段階の現在をＬＥＤが光る回数で知らせよう。
アラーム動作時間
・５段階のサイクルとしよう。（５秒／１０秒／２０秒／３０秒／１分）
・スイッチを押す度に６段階の現在をＬＥＤが光る回数で知らせる。
A割り込みピン
ここでPICのピン配置をもう一度整理しておこう。
外部クロックはこの先も使わないだろうが念のために予約しておく。
RB0をINT割り込みとして利用出来るが、これを使うにはINTCON”の「割り込み許可」を行わなければならない。
先のWDTで禁止にしているので使えない。
RB4〜RB7のいずれかの入力に変化があるとその時点で割込みを発生させる「PORTB割込み」を使おう。
１）RB6を入力に設定する。
２）INTCONのRBIE=1で「ＲＢポートの変化割込み」を許可する。
３）割込み後の処理後にRBIF=0にして「割込み発生していない」にする。
これを行わないと割込み中と判断されて次の割り込みが出来ない。
ひゃ〜！ついにピンを全部使っちまった。
内部クロックで十分だからオシレータの２つも使えるし、デバッグ用を取っ払えば利用できるけど、それじゃ開発効率が落ちるしなぁ・・・・・。
やっぱ、この試作品が完成したらＩＣを代えよう。
さて、これでインタラプトルーチンを作れば完成だ！
static void interrupt Button1(void){
}
でコンパイルすると・・・・・
何じゃ？こりゃ？（→）
cgpic.exeでググってみると・・・・
PICC V9.70はディレイと割り込みでバグが発生しているらしい。
”HiTech C”のバグかよ！・・・・ここまできて・・・・・・
V9.70のバグという事でV9.65を使ってみるもうまくいかない。
cgpic.exeを入れ替えてみるもこんなとこだけはちゃんとチェックしているようだ。
バグ修正版も出ておらず、買収元のMicrochip社の姿勢を疑う。
という訳でバグフィックス版が出るまでお預け状態。
ならば割り込みではなく、単純にボタンを押し続ける事でルーチン上で認識させて飛ばしてみよう。
RB6=1;
と入力にしてメインループ内に、
if(RB6==1){
Timer_GO(3);
if(RB6==1){ ・・・・・・・・@
Button1();
}
}
Button1(){
RB1=1;
（ＲＯＭ処理） ・・・・・・・・A
RB1=0;
RB6=0;
}
とする。
@は物理ボタンのチャタリング対策で、ボタン押下を認識したら３０ｍｓウェイトしてもう一度確認する事で押下とみなす。
また入力レベルは非常に繊細で他のピンが仕事をしていると勝手にLowからHighに、しかもフラフラと変わってしまう。
その為、入力ピンには必ずプルアップ抵抗を入れてやる事。
抵抗値は余り小さくなければ何でも良いが１０ＫΩ〜１ＭΩとショートにならないものを入れてやる。
AはＥＥＰＲＯＭへの読み出しと書き込み処理。
【ＥＥＰＲＯＭへのアクセス】
不揮発性メモリが使えるメリットは大きい。
初期設定の値を自分で変更する事で、動作を自分仕様に変更出来る。
またデータロギングが出来る事によって過去の状態を把握する事が可能となるのだ。
ＥＥＣＯＮ１
| 7bit | 6bit | 5bit | 4bit | 3bit | 2bit | 1bit | 0bit |
| ＥＥＰＧＤ | （未使用） | （未使用） | ＦＲＥＥ | ＷＲＥＲＲ | ＷＲＥＮ | ＷＲ | ＲＤ |
不揮発メモリへのアクセスに必要なワードは全部で７個。
@ＥＥＡＤＲ：ＥＥＰＲＯＭの番地。
８８の容量は２５６バイトだから、先頭番地「００」〜「ＦＦ」まで。
１バイトでは通常「１文字＝１つの値」だけど、８ビットで考えれば２５６値の設定が可能。
だから数値だけを扱うとすれば２５６＊２５６＝６５５６６もの値を記憶する事が可能だ。
でもそれよりも２５６桁と考えると６８桁の「無量大数」を遥かに超える値を扱える訳だ。
まぁ、今はそんな事は関係ないから、とりあえず１バイト目を”１”〜”６”として扱う。
AＥＥＤＡＴＡ：指定番地に書き込む内容。
BＥＥＣＯＮ１=>ＥＥＰＧＤ：メモリ選択
０：データメモリ
１：プログラムメモリ
以前は未使用だった８ビット目にプログラムメモリにアクセス出来る選択を追加した為、以前は必要の無かった選択が必須になったとの事。
ウソ？って、データシートにしっかり書いてあった！（Ｐ２７参照）
最初はこれを知らなかった為に、動作が不安定だった。
というより、それでも動いていたので不安定だぞ！と感じていたのだが、動く時はたまたま一致しただけの事だったのだ。
プログラムメモリ領域は２５５バイトを超えるので、アクセスには２バイトのアドレスを持つ必要がある。それが、
・ＥＥＡＤＲＬ
・ＥＥＡＤＲＨ
のＬＯＷとＨＩＧＨだ。
またそのデータも１４ビットになるから、
・ＥＥＤＡＴＡ
・ＥＥＤＡＴＨ
の２つにアクセスしなければならない。
・プログラムでプログラム書き換えて暴走したくないしぃ〜・・・・・
・２箇所のアドレスから２箇所のデータ持ってくるの面倒くさいしぃ〜・・・・・
の理由からデータメモリしか使わない！
CＥＥＣＯＮ１=>ＷＲＥＮ：書き込み許可
０：不許可
１：許可
DＥＥＣＯＮ２：論理エリア
書き込み指示を出す前にＥＥＣＯＮ２に対して、
０１０１０１０１ を書き込み
１０１０１０１０ を書き込み
とおまじないを行う事で最終ロックが解除されるとの事。
なぜこんな仕様になっているのか？はどこにも書かれてないので不明。
EＥＥＣＯＮ１=>ＷＲ：書き込み状況
０：指示が無い限りゼロ
１：書き込み開始指示
書き込みが終わると自動で０に戻る。
だから書き込み後にこの値を監視して終了したか？判断する。
FＥＥＣＯＮ１=>ＲＤ：読み出し状況
０：指示が無い限りゼロ
１：読み出し開始指示
普通は使わないがこの他にも、
ＥＥＣＯＮ１=>ＦＲＥＥ：消去
プログラムメモリを消去するフラグらしいが使い方が良く判らんので詳細はなし。
ＥＥＣＯＮ１=>ＷＲＥＲＲ：書き込みエラーフラグ
０：通常
１：書き込みでエラーが発生した
今回はＥＥＰＲＯＭに関する割り込みを使用しないので、エラーは発生しないものと仮定して進める。
しっかし、どうもＣ言語によるＨＰ上の記述例が少ないと感じる。いや、殆ど無いと言っていい。
だからいろいろ調べた結果、諦めてアセンブラの例のソースを見ながらＣ言語に変えていく事の繰り返し。
MOVLW 00h
MOVWF EEADR
MOVF PORTB,W
MOVWF EEDATA
BSF STATUS,RP0
BCF EECON1,EEPGD
BSF EECON1,WREN
MOVLW 55H
MOVWF EECON2
MOVLW 0AAH
MOVWF EECON2
BSF EECON1,WR
EEW
BTFSC EECON1,WR
GOTO EEW
BCF STATUS,RP0
といった例を見ながら、
EEADR=0x00
EEDATA=EEP_DATA（任意変数）
EEPGD=0
WREN=1
EECON2=0x55
EECON2=0xAA
WR=1
while(WR==1){
Timer_GO(1)
}
と変えていく作業が続く。
本当に「そのレジスタ名」が存在するのか？を”PIC16F87.h”の定義を見ながら確認して進める。
ちなみに赤い部分はおまじないで順序も変えてはいけない。
（青い部分は新機能のメモリ選択で指定しないと動作しない）
それでもＣ言語はバンク切り替えが必要ないし、ジャンプも無いから非常〜〜〜に楽だっ！！
それにこうも簡単に変換出来るのは先にアセンブラを習得したおかげだと感じる。有難うです！＞先生！
【作動ログボタンの追加】
これで２つの設定（リレー作動時間と傾斜感度）が完成したが、もう一つ追加したい。
それは「この動作中にアラームが何回作動したか？」を知るボタン。
で、配置的には２個のボタンが精一杯なので、
ａ）ボタン１押下で作動ログ表示
ｂ）ボタン２押下（未定）
ｃ）両方のボタン押下で設定モードに移行
ｄ）設定モード＋ボタン１押下でリレー設定
ｅ）設定モード＋ボタン２押下で傾斜設定
とする。
実際の動作としては、
作動ログの表示
ａ）ボタン１押下
ｂ）押下確認でＬＥＤ１を点灯１秒＋消灯０．５秒
ｃ）もし作動回数がゼロだったらＬＥＤ２を１回点滅
ｄ）１回以上あったら作動回数分ＬＥＤ１を点滅
作動ログは今回の作動中、つまり電源ＯＮの時の回数なので、電源ＯＦＦ時にはクリアしなければならない。
だからこの値はＥＥＰＲＯＭに書き込むのではなく、あくまでも変数としてメモリ上で展開していなければならない。
設定時の動作
ａ）両方のボタン押下
ｂ）両方のＬＥＤの点滅（１秒）で両方のボタンの押下を確認
ｃ）再びどちらかのボタンが押されるまで無限ループに入る。（＊１）
ｄ）ボタン１押下だったらリレー作動時間設定へ
ｅ）ボタン２押下だったら傾斜設定へ
（＊１）：無限といっても番犬（ＷＤＴ）が居るので実際には１２０秒前後。
リレー作動時間設定
ａ）押下確認でＬＥＤ１を点灯１秒＋消灯０．５秒
ｂ）現在の設定＋１（ＭＡＸならゼロ）を記憶させて、＋１回分だけＬＥＤ１を点滅
傾斜感度設定
ａ）押下確認でＬＥＤ２を点灯１秒＋消灯０．５秒
ｂ）現在の設定＋１（ＭＡＸならゼロ）を記憶させて、＋１回分だけＬＥＤ２を点滅
となる。
ここまで一気にプログラムして気がついた。
コンパイル出来てるって事はまだメモリは大丈夫なんだ・・・・。
と見てビックリ！（→）
もうなんも書けない・・・・・・。
やっぱ４ｋ以上のＩＣにしないとダメだ・・・・・。
製品にすれば半分、つまり倍かぁ・・・・。
まぁ、ここまで使えるなら買ってもいいかぁ・・・・とも思うが、やっぱ個人で５万円は高いよ・・・・。
商用以外の使用で１万円くらいで買えるなら買ってもいいなぁ・・・・と思うのだが。
【強制システム停止ボタンの追加】
まぁ・・・行けるとこまで行っちゃれ！
１つ残ったボタンを「システム停止」ボタンに当てる。
物理停止には外部にシステム切断ＳＷを別途付けるが、それはＯＮすると同時にシステムが作動し始めて、その瞬間に検知を始める。
だから最初は「バイクを離れてから遠隔でＳＷーＯＮする」を想定したのだが、それはリモコンで赤外線操作をしなければならない為、この試作ではピン数もプログラム領域も足りない。
では次に「初動開始時間を設定してバイクから離れる」を考えたが、それではバイクに戻った時に停止操作を検知してしまう。
結局「指定時間システムを強制停止させる」ボタンを追加する事にした。
具体的にはボタン２を押す事で５分間システムを強制的に停止させる。
これは初動に限らず、ちょっと弄る時にも有効であるメリットがある。
当然の事ながらＷＤＴを軽く超えてしまうので分割してＷＤＴを割り込ませる。
尚、このボタンの配置についてはセキュリティ上詳細は書かない。
【プログラム完成！】
最後にパソコンと切離す為にＲＳ２３２Ｃへのジャンプを切断。
それに伴なう一サイクルの時間変化をタイマーで調整して完成だぁ！
【パターンの完成へ】
プログラムと格闘しつつ、焼いてはテスト、焼いてはテスト・・・・。
すでに謎の生物化（？）しているブレッドボートの配線をうっかり触らないようにそっとね・・・・・。
プログラムが要求仕様に合致した処で、最終的に配線の点検を行なう。
以降はこの実際の配線が一番の拠（よりどころ）になるからだ。
そしてそのイメージからテスト系を除いてブレッドボード調に配線図を起こすとこうなる。
それを製図するとこうなる。
さすがに１枚レギュレータは発熱がキツイ。
一晩点けっ放しで約５０℃だった。
だから放熱板用にスペースを開ける事にした。
【露光装置の製作】
やっぱり・・・・というか予想通り「作りたいムシ」が騒ぎ出したのだからしょうがない。
という訳で露光装置の製作へ。
（１週間後）
帰ってきました！
露光器を作っている間、パソコン作業が無いから寂しかったよ・・・・。
だから回路を眺めはちょっと手直ししているうちに段々効率良くなってきました。
その結果（→）
具体的なフィンの大きさを当て嵌めてみたら、ちょっと違うぞ・・・？
無理っぽいと判った時点でアキバに走る・・・・。
秋月には適当なのが無く、隣の「千石電商」の２Ｆでゲット。
やっぱお互いに強みと弱みがあるのね。
現物合わせ覚悟で３種類買い込みました。
【最終型】
上記スペースの関係から５Ｖと１２ＶのＧＮＤを纏めてみた。
０Ωの抵抗が１本残ったがこれは仕方あるまい。
グランドを多く取って僅かな抵抗も阻止する。
しかしここまできてやっと「孔レイヤー」の使い方が判った。
ランドを貼った後で孔を重ねると版下印刷の時点でポジ反転するとの事。
つまり抜いたのと同じ事なのだ！
これは便利！
最後にシルクを反転させて版下反転印刷準備終了！
【版下反転印刷】
最近のＯＨＰシートはインクジェットに対応しているらしい。
でも高け〜な！相変わらず・・・・ってか、今時ＯＨＰってあるのか？
だってパソコンでモニタケーブル延長すればいいだけじゃん！今時・・・・。
でもこの透明シートのお陰で露光時間がかなり変わるので助かるわぁ〜
んで、インクジェットで試したら薄い！
いろんな設定を試みるも薄くて使い物にならん！
（うちのＰＭ−７３０Ｃが悪いか？）
諦めてレーザー（ＮＸ１００）で印刷してみる。
紙送りするか？心配だったが全く問題なし。
綺麗！
なんだよ。
最初からレーザーで印刷すりゃよかった・・・。
上：ＯＨＰフィルム
下：普通紙でテスト
トナーなのでムラあり？は仕方あるまい。
レジストペンで修正する。
【感光基板の作成】
ところで露光時間が全く判らん！
「露光テストチャート」なるものを買ってきて、しばらく紫外線に当ててみるも変化なし。
何で？と説明を読むと「このシートを感光基板に貼って露光してから現像して基板の数字を読み取って下さい」
ええっ！？
結局基板でテストせにゃならんのかい？
このシートはただのセロファンだったのかい？
だったらブツけ本番でも（基板をダメにする枚数は）同じじゃんか！・・・・ってなった訳。
でもさ・・・・それじゃ余りにもいい加減過ぎないかい？・・・・って探していて見えてきた事。
１：いろんなＨＰで書いてある露光時間は１分〜２０分と幅あり過ぎ！全然参考にならん！
２：でもそれはサンハヤトの製品が新しいのか？旧タイプなのか？で異なっているらしい。
３：だから「クイック感光ポジ基板」で検索しないと痛い目に合いそうだ・・・・。
で、探していたらサンハヤト自体で「クイック感光ポジ基板の作り方」ってＰＤＦ出してんじゃん！
早々にダウンロードして眺めると、そこには「露光プロファイル」なるグラフチャートが有るではないか！
やっと安心して確定出来そうだ。
それがこれ（→）
今回の基板は１００＊７５なので「ちびライト用チャート」を用いる。
製造年月日が３ヶ月前だから・・・１３６秒だ。
自作露光器は「ちびライト」に比べて照射能力が２倍以上あると思うのだが、クリアランスも２倍程あると予想されるので、とりあえずこの時間を基準値としてスタートしてみよう。
それでは始める前にもう一度手順のおさらい。
１：エッジング液をボトルのまま４０℃の湯で温め、液温４０℃近くになるまで待つ。
２：４０℃の湯２００ｍｌに現像液を溶かして撹拌後放置。
３：部屋を暗くしてから感光基板を取り出しＯＨＰシートと重ねあわせて露光器へ置く。
４：上記時間で露光。
５：現像液が３０℃前後を確認してから現像時間３０秒を目安に現像開始。
６：ゆすりながら青い液が流れ出すまで洗うように。
７：剥がす部分の銅板が現れて感光皮膜との差がハッキリしてきたら終了。
８：水洗い後に回路のチェック。感光皮膜が切れていたらレジストペンで修正する。ドライヤーで乾燥させる。
９：エッジング液が４０℃近くを確認後、バットに移してエッジング開始。
10：目安は１０〜１５分でベーク板がハッキリと露出したら終了。液が手につかない様に注意する事。
11：水洗い後にチェック。
12：回路上の感光皮膜を落とす為に、再度上記時間で露光。
13：現像しながら皮膜が剥離するのを確認したら水洗い＆ドライヤーで乾燥。
14：回路チェック後にフラックスを塗って終了。
廃液処理について：
現像液は１枚処理しただけでも８時間を超えると使えないので破棄する事。
エッジング液も間が開くようなら破棄する事。
１：青色になった現像液に酢を加えて淡黄色に変色したら水で流して終了。
２：付属のポリ袋にエッジング液を入れＡ剤を入れる。
３：揉むと発熱するので口を開けて冷やしてからＢ剤を入れる。
４：揉むと発熱するので口を開けて冷やす。
５：これで化学処理は終了。そのまま固まれば「燃えないゴミ」へ。
６：翌日になっても固まらなければセメント１５０ｇを入れて固形にして「燃えないゴミ」へ。
さぁ、いくぞ！
今回用意した基板は、
・紙フェノール（Ｐ１０Ｋ）：３８０円
・ガラスコンポジット（Ｅ４０Ｋ）：４８０円
・ガラスエポキシ（Ｇ３０Ｋ）：５３０円
の３種類。
失敗したら次々に開封していく予定だ。（３発がリミットだけど！）
先ずは回路に沿って切り取ったＯＨＰシートを露光器の真ん中に据える。
この時に裏表を間違えたら台無しだから気を付けてね！
回路の方が基板より小さいので、この上から基板をガバッって置くだけでＯＫ。
両面テープで貼り付けたフタの役目のアクリルが意外にもしっかりとホールドしてくれてズレる心配は全く無い。
でも念のために携帯電話を重しにしちゃったりして・・・・。
先に決めた１３６秒を守って現像開始。
１０秒ほどでマスク外の感光皮膜が溶け出す。
３０秒ほどゆすった処で水洗いしてみる。
あれ？なんか薄い。
全体的に薄くてマスク部分も透けて見えるのだ。
明らかに露出オーバーだった。
この時点で２個目の基板を用意する。
露光時間は・・・・えぇ〜ぃ！９０秒でどやっ！
その結果。（→）
１３６秒の方は後からレジストペンで描いた部分だけが濃く見ている。
印刷が薄い・・・・というより２重に濃くした部分だけが生き残ったと解釈すべきだろう。
９０秒でもまだ薄い気がするのだが、まぁ、途中で文句を言う程手馴れている訳ではない（ってか、初めてじゃん！）ので、このまま進んでみよう。
次にエッジングに入る。
ゆすること１０分・・・・ええ？まだかよ・・・・？
取り出して洗ってみるも、まだ銅板のまま。
ここで温度をいい加減に考えていた事を後悔し始める。
２０分後。
端っこがわずかに剥がれてベーク板が出来てきた・・・・。
激しく後悔し始める・・・・。
ここでワンの餌入れにお湯を張ってコンロでそ〜っと炊いてみる。
グングン温度が上がり、銅の溶け方が早くなっていく。
本来ならこの時点でまだ感光皮膜がビッシリとついているハズ。
やはり露出の問題だな。
９０秒の方はまだ全体に皮膜が覆っている。
そこで皮膜落としの露光時間を６０秒に設定して焼いてみる。
現像してみると、いい感じで溶けていく。
なんかこう・・・溶け感覚というか溶け具合が好き。
露光時間は６０秒が最適なのかもしれない。
ここまでの作業を終えて、
諦めていた紙フェノール（１３６秒）が意外にも健闘している。
矢印の様に細い文字は消滅しているし、外枠も溶けてしまっているが回路そのものは使えない程損傷していない。
あれ？回路が切れてる！
やっぱダメか！？
それに視認しにくいな。紙フェノールって。
一方のガラスコンポジット（９０秒）はいい感じ。
逆に基板の端の方がまだ溶けきっていない。
これはエッジング時間の問題でもっと温度を上げれば解決すると思われる。
ガラスコンポジットは薄くて色違いだから回路も良く見える。
こっちの方が好きだな。
これからはガラス系（まだエポキシを試してないが）にしよう。
まっ、今回は初めてのトライにしてはいいんじゃない！？
最後にフラックスを塗布して終了！
さて、勿体無いとは思うものの、当面は使わないだろうから、これも学習と思って廃液処理に移ろう。
先ずは現像液から。
家庭用のお酢を入れて中和させる。
まぁ、現像液なんだから当たり前かもしれないが、写真屋から言わせたら冗談みたいなんだろうな。
それをメーカーが推奨してるって・・・専用剤くらい付けろよ？
それも違うか？１２０円なんだから・・・・。
主成分はメタ硅酸塩とあるが、要はケイ素化合物の液晶体だから、酸を加える事で、アルカリ＋酸で中和される。
またこの時に沈殿するケイ酸は二酸化ケイ素（シリカ）なので”燃えないゴミ”と化す事が出来る訳だ。
次にエッジング液だがこの理屈はよくわからん。
塩化鉄の強い酸化作用で銅を溶かすのがエッジングの原理だが、さらに鉄を加える事で銅を析出出来るらしい。
そこにカルシウムを加えると塩化カルシウムと水酸化鉄に分離する。
塩化カルシウムは除雪剤や除湿剤として、水酸化鉄はいわゆるサビとして”燃えないゴミ”扱いが可能となる。
厳密に言えば産廃なのだが、個人が扱う量ならば、セメントで水分を除去して固形化させて、地中に染み込むのを防げば、そのまま廃棄しても可能・・・・・という処か？
鉄粉と聞いて恐ろしいと思うのはジェネレーションなのだろうか？
簡単に周囲を発火点まで上げて火災に発展する注意すべき剤だと思っているのだが。
７０℃くらいにはなってるぞ！？
このポリ袋耐えられるのかな？
まぁ、そんなこんなで今回の反省点。
１：露光時間
初めてだから仕方がないが、自分で作った露光器の露光時間が判明した。
９０秒でも”やや満足”だったのだが、次回は１５秒減らして７５秒でやってみよう。
２：エッジング液温度を上げる。
現像に比べて動きが鈍いようなので、思い切って温度を上げても良いだろう。
液温度を４０℃〜４５℃でやってみる事。
【穴開け＆カット】
面倒臭いなぁ〜・・・・と思いながらもボール盤に向かうと集中出来るから楽しい。
ものの十数分で孔開け完了！
やっぱ楽しい・・・・・。
ところで最近は穴開きのポジ感光基板が発売されたらしい。
ちょっとそそられもするが、おかしくね？
だって孔開いていたらフリーランスの結線が描けないじゃん？
う〜ん・・・・。
最後にカッターで周りを落として基板作成の完了！
【組み立て】
ここまできたら後はプラモデルと同じ様に組み立てるだけ。
ＰＣＢＥという素晴らしいソフトウェアのお陰で何の不安もなく小一時間で完成です。
本当にありがとう！
フラックスを塗ったままベタベタ触っちゃったから汚くなっちゃった・・・・。
ちゃんと乾燥させにゃ〜ダメよね。
なんて、ちょっといい気になってるとこれだ・・・・。
ブザーは五月蝿いので最後まで接続テストしてなかったのね。
で、完成後に接続してみたらセット（Ｓ）とリセット（Ｒ）を逆に配線して焼いちまったぜぃ！
ソースで全部逆にする事も考えたが、何か今更面倒くさいので基板を加工しちまった！
ダハハッ！こんな処でもまた素人がバレちまったぜぃ！
だから図面は本当にこれが最後！
こうなった。
ってな訳で２号機の完成！
細かい事を言えばサーキット（回路）は１０回以上書き直してるし、プログラムロジックは言語変更も含めて試行錯誤の連続。
だから自分では何号機もう判らない状態ですが、とりあえず完動品としては２号機という事で。
さて、一ヶ月半ぶりに実装ＨＰに戻りますか！