パターン・チェックまで通ったけど・・・
水魚堂氏の作成したMBE（Minimal Board Editor)はデザイン・ルール・チェックを行うことが出来ます。パターンとランドが近すぎるとか、小さな結線ミス（電気的にはOKだけど、パターンとしては繋がっていない）等を探し出す優れものです。このデザイン・ルール・チェックに通った後、BSch3V（回路図エディタ）とMBE（Minimal Board Editor)のネットリストを使ってパターンの整合性をチェックします。
抵抗や無極性コンデンサのpin番号まで一致させないと通らないので大変なのですが、回路図通りのパターンであることがソフトウェアで確認出来る（目視だとチェック漏れの懸念が拭えない）ので助かっています。
しかし、パターン・チェックは通ったものの・・・
この二日間、回路図を見直すたびに小さな誤りに気づいて訂正を繰り返しています。orz
ネットリストを使ったチェックでは回路図の誤りは（当然ですが）見つけてくれません。またつい先ほど、ベタ・パターンの設定間違いでGNDと+5Vがショートしている所が見つかりました。これもアートワーク上の作業なのでネットリストを使ったチェックには引っかからないのです。危ない危ない・・・
まだ暫くはPic-colo基板を発注できそうもありません。orz
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
１０μF25Vのチップ・コンデンサを1608から2012（こっちの方が安い）に変更しました。この修正が最後になってくれるだろうか？
基板設計を始めた
Pic-coloプログラムのデバッグはまだ終わっていませんが、先行して基板設計に取りかかりました。パターンの設計には水魚堂さんのこれ（↓）を利用しています。感謝！
普通なら、回路図を書き上げてそれに従って基板設計を行うものですが、一人でやる作業なので変更は自由です。パターンが引き辛いときには回路の方を変更します。￥（＾_＾）
先ずはザラザラと部品を配置して、取りあえず必要な部品が配置出来ることを確認しました。コンデンサや抵抗に表面実装部品を使うので余裕で入ります。O.K
（その分、パターンの引き回しが難しくなっているのですが・・・）.
続いて、回路図を眺めながら部品配置を整理します。O.K.
でパターンを引いて行きます・・・ん！ N.G.（<==案の定）
この配置だと真ん中のU1から上辺CN5の6,7,8pinとCN6の2,3,4,5pinにパターンが届きません。orz
もう少し粘ることも考えましたが、無理をして後で回路の修正が入ったときに二進も三進も行かなくなる（４層基板にせざるを得なくなって製造コストに跳ね返る）のが心配です。離れた所からパターンを接続しようとして無理しているのは明かです。ここはスッパリ、今の配置を見直すことにします。
またやり直しだ～（<==実は嫌がっていない）
Windows 10にMosquittoをインストールした
MQTTを試すため、WIndows PCにMosquitto（これ↓）をインストールしてみました。
OSは64bit版ですがdownloadしたのはmosquitto-1.4.14-install-win32.exeです。
インストーラを実行すると、libeay32.dllとssleay32.dllが見つからない無いと言われ、0.9.8版をインストールしたら、「序数****が見つからない」という訳の分からないエラーになりました。orz
このエラーは、libeay32.dllとssleay32.dllが古いときに出るらしく、これ（↓）を入れ、
https://slproweb.com/download/Win64OpenSSL_Light-1_1_0f.exe
OpenSSLのインストール・フォルダにあったlibeay32.dllとssleay32.dll（1.0.2版）をSystemフォルダにコピーしpthreadVC2.dllも探してきて同様に処置し、なんとかインストールを完了しました。
Windows管理ツール==>サービス（ローカル）にあるMosquitto Brokerを起動して、1883ポートを開放し、MQTT publishコマンドと subscriveコマンドを試すと・・・
無事、subscriverのコンソールにpublisherのメッセージが表示されました。
パチパチパチ～
Pic-coloの構想が発散気味になってきた
Pic-coloはUSB－シリアルでPCと接続する構想で設計を進めてきました。リモート接続したい場合はRaspi-PICcoloを使ってもらう（Raspi-3BのWifi機能を利用する）計画です。
しかし、Raspi-3Bを独立電源で動かす（そのつもりでDCDC電源も手配した）のは、なかなか大変（特に運用時の充電）です。PIc-coloにESP-WROOM2（これ↓）を
espressif.com搭載することを考え始めました。
ところが、直ぐ￥150の差ならBluetoothの付いたESP-WROOM32（これ↓）の方が良いような気がしてきて・・・
でも、PIC16F1788では釣り合わない気がしてきて・・・
10月には基板化する計画だったのに、ここにきてPic-coloの構想が発散気味です。orz
--------------------------------------------------------------------------------
方針が決まりました。（早っ）
ESP-WROOM32はオーバー・スペックなのと基板レイアウトが厳しいので止めにして、ESP-WROOM-2をオプション扱いとしてswitch-scienceのこれ（↓）が取り付け
www.switch-science.comられるソケットを設けることにしました。
構想が発散しかけたけれど、これにて収束！
実は、ESP-WROOM-2とPCとの通信をどうするか？迷っています。
ATコマンド？
Socket通信？
MQTT？==>その場合、Brokerは？
この辺りはボチボチ詰めて行こうと思います。
Arduinoを試してみることにした
sw_operationプログラムのデバッグで苦労した
Raspi-PICcoloはPic-coloのRaspi搭載モデルです。
秋月電子のRaspi用ユニバーサル基板にRaspi-PICcoloを組んでみました。
これを使って、プログラムの試作を進めています。
先ずは基本のLチカプログラムから、これはすんなり動いて次はSW操作プログラムです。タクトSWの短押し一回で１点灯、短押し二回で２点灯、長押し一回で１秒間隔の点滅、長押し二回で２秒間隔の点滅を繰り返すというものです。動いたように見えたのですが・・・途中で動作が止まってしまいます。ちょっと嫌な不具合です。orz
いつもなら、PICkit3でプログラムの動作を追いかける所です。しかし、ここはPICkit3に頼らず、Raspi-PICcoloだけでデバッグできることを示さなければなりません。
しかし、何をどうすれば良いのか？PIc-coloに加えたいデバッグ機能が色々でてきましたが・・・
SW操作プログラムのベースはLチカプログラムです。先ずはLチカプログラムに戻って、そこに追加した機能を順番に試してみることにしました。
MainループのLED制御は初期状態では１点灯の反復です。これはLチカプログラムとほとんど同じなのですが、念のため確認しておきます。問題なし。
次は10msインターバルで行う、SWの状態読み取りです。これも問題なし。最後に残ったSW操作の判定処理・・・ん、不具合再現！
不具合箇所が絞られました。ソースコードを見直します。
100msインターバルでSW操作の判定を行っているのですが・・・ あ！
中でdi()ei()を使う関数をms_timer割り込みの中から呼び出していました。orz
関数の呼び出しをMainループに移すと・・・
ビンゴ～
動きました。SW操作プログラムの完成です。
やれやれ
commPortのclose処理で苦労した
Pic-coloは、COMMポートがオープンできない場合はPICとの通信は行わず、SettingメニューでCOMMポートの指定が修正されて、ポートがオープンできた場合にPICとの通信を始めます。
ここまでは、良いのですが問題はCOMMポートが複数ある場合です。一方のCOMMポートを開いた後に、SettingメニューでCOMMポートの指定が変更された場合、現在開いているCOMMポートをクローズしてから、新しく指定されたCOMMポートをオープンすることになります。ところが・・・何故かclose関数から戻ってこないのです。orz
ネット上にもrxtxのclose処理で困っている方が大勢いるようです。
”こうすると良い”という記事を見つけたのですが・・・
> serialPort.removeEventListener();
> serialPort.close();
https://marc.info/?l=rxtx&m=123544269723586&w=2
駄目でした。
諦め半分で、暫くジタバタして・・・
ん！出来た？
ReceiveThreadとSendThreadの停止を待ち、portのInputStreamとOutputStreamをcloseしてからportをcloseしたら、上手く行きました！
（パチパチパチ～）
コードはこんな感じです。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
private class CloseThread implements Runnable {
public void run() {
try {
thread_break = true; <== ReceiveThread、SendThreadの順に停止させる
while( !st_break ) <== SendThreadの停止を待つ
{
try {
sleep(100);
} catch (InterruptedException ex) {
Logger.getLogger(Comm.class.getName()).log(Level.SEVERE, null, ex);
}
}
out.close();
in.close();
port.close();
} catch (IOException ex) {
Logger.getLogger(Comm.class.getName()).log(Level.SEVERE, null, ex);
}
}
}
close処理をThread化したのは、close処理を始めた後もメイン・ループからステータス受信のコマンドを出させるためです。それによって、ReceiveThreadとSendThreadが走り、whileループから抜けます。
やれやれ。
