denshikobo’s blog

PICプログラミングやPCの操作で感じた日々の由無し事を綴ります

FusionPCBに基板を発注した

久しぶりに基板(↓)を発注しました。発注先はFusionPCBです。

f:id:denshikobo:20180619152846p:plain

10cm×10cmに9面付けしました。¥(^_^)

10枚(×9枚)で$4.9。安い!

送料はDHLで$20。高い!

でも、基板1枚あたり$0.30だから、やっぱり安い。

 

そしてこれ(↓)、手付け用メタルマスクです。期待通りに使えるかどうか

f:id:denshikobo:20180619153110p:plain

まだ判りません。

 

FusionPCBが¥1000以下でメタルマスクを作ってくれることを知って、先ずは「お試し」で作ってみることにしました。

 

左下が今回設計した基板のパターンで、他はTQFPの汎用パターンになっています。

考えている手順は・・・

(1)TQFPのパッドに下半田を施す

(2)基板とメタルマスクの位置を合わせる

(3)TQFPデバイスをメタルマスクに落とす

(4)丸い切り欠きの所で仮り止めする

(5)メタルマスクを外して、全周を半田付けする

 

パッドの下半田は上手く行くか?

基板とメタルマスクの位置合わせをどうするか?

 

届くのは早くても今月末なので、思案する時間はたっぷりあります。

 

使いにくい所を直していく

 『PIC_coloの操作手順』に出てくる、説明が面倒な部分や、同じ操作を繰り返し求める部分が気になっています。開発者なら当然のことであっても、初めて行うユーザに必要事項を細大漏らさず伝えようとすると、どうしても説明がくどくなってしまいます。また、何も気にせず反復していた操作も、あらためて文章にしてみると面倒な操作に思えます。

 

 どうやら、操作手順を記すことでPIC_coloの改善点が浮き彫りになっているようです。

 

 先ずは、同じ操作を反復する部分から改善しようと思います。それと、アプリケーション開発を支援する機能をカスタム・ウィンドウに追加しようと思います。

(1)PIC_coloプロジェクト・フォルダとCOM番号の設定を共通設定

   ファイルに移す。

(2)カスタム・ウィンドウにキーボード操作機能を加える。

(3)カスタム・ウィンドウにファイル操作機能を加える。

 

これで、『PIC_coloの操作手順』が少しスッキリして、データロガー・アプリケーションの開発がスムーズになると良いなぁ

 

 

PIC_coloの説明図を描いてみた

 Inkscapeを勉強し直して、『PIC_coloのGUIアプリケーションの実行制御』を説明する図を描いてみました。

f:id:denshikobo:20180604174940p:plain

この図で伝えたいこと

一つ、PIC_coloコンソールがアプリケーション・プログラム(Hexファイル)を読み取り、PIC_coloデバッガがPICのFlashメモリ(0x1000~0x3fff番地)に書き込む。

一つ、PIC_coloコンソールとPIC_coloデバッガ間のコマンド・レスポンスを介して、パソコン上のCustom_FrameとPIC上のアプリケーション・プログラム間のデータ授受を行う。

一つ、アプリケーション・プログラムからBREAKPOINT(0)を呼び出してPIC_coloデバッガに実行を切り替え、PIC_coloコンソールとPIC_coloデバッガ間のコマンド・レスポンスを処理する。

 

ことなんですが・・・表現できているでしょうか?

PIC_colo_Updateが動いた

 着想を得てからそれが実現するまでの間に起こる諸々をつぶさにお伝えできれば良いのですが、大抵テンパっているのでそんな余裕は持てません。(^_^;)

 

 連携する複数のプログラムを更新する作業は難航しがちです。今回もそうでした。

 

 タイマー割り込みをポーリングで処理してLEDを点滅させることは出来たのですが、『割り込み禁止にしてUARTをポーリングで動かす』ことがなかなか上手く行きません。ようやく動いたと思ったら、レスポンスが何か変!orz

 

 PICkit3を使わずPIC_colo_Debuggerの機能も使えない状態でデバッグするのは大変でした。ハードウェア・リセットを掛けてPIC_colo_Debuggerに戻すという方法で、メモリーに蓄えたスナップ・ショットを読み取ってプログラムの動作を追いかけ、なんとかPIC_colo_UpdateとPIC_colo_Console間のコマンド送受が動きました。

 

 いよいよPIC_colo_Debuggerの書き換えです。0x1000番地以降の書き込みは出来るので、0x0000番地から書き込み可能にすれば良いと簡単に考えていました。ところが書き換えたPIC_colo_Debuggerが動いてくれません。orz

 

 PICkit3でプログラム・メモリを読み出すと、0x0000番地付近が正しく書き込まれていません。書き込み動作をモニタすると0x0000番地付近を最後に書き直しています。Hexファイルの末尾に書かれたコンフィグ・データを0x0000番地に上書きしていたのです。それが判るまでPICkit3を使って何度もPIC_colo_Debuggerを書き直す羽目になりました。

 

 そんなこんなで、何とかPIC_colo_Updateが動くようになりました。

パチパチパチ~

 

 修復手段を持っていないユーザにとってPIC_colo_Debuggerの書き換えは、大きなリスクを伴う作業です。出来るようになったとは言え、PIC_colo_Debuggerの頻繁なアップデートは控えるつもりです。

 

 

PIC_coloをアップデートする方法を見つけた

 PIC_coloのアップデートは、連携して動作する二つのプログラム(PIC_colo_ConsoleとPIC_colo_Debugger)の更新を意味します。PIC_colo_ConsoleはJAVAプログラムなので新しいプログラムファイル(jarファイル)を所定のフォルダに配置すればアップデート完了ですが、PIC_colo_Debuggerの方は新しいプログラムファイル(hexファイル)をPICに書き込む必要があります。PICkit3やPICプログラマがあれば、簡単な作業ですが・・・

 

 PIC_coloは『PICkit3やPICプログラマを必要としない開発環境』を提供しようとしているのに、そのアップデートには『他の書き込み装置が必要』というのは、大変残念です。なんとか出来ないか?

つらつら考えて・・・ん!

 

 『hexファイルを書き込む機能を持つユーザ・プログラムで0x0番地から0x0fff番地(PIC_colo_Debuggerが書き込まれている領域)を書き換える』という方法にたどり着きました。

 

 PIC_colo_UpdateプログラムにPIC_colo_Debuggerが備える機能(シリアル通信やコマンド応答、プログラム書き込み機能等)を一通り組み込んで、PIC_colo_Updateプログラムが走っている間は割り込みを禁止して、PIC_colo_Debuggerのコードは実行しないようにして・・・

 

<PIC_colo_Debuggerの更新手順>

(1)PIC_colo_Debuggerを起動する(リセットが解除されれば起動する)

(2)PIC_colo_UpdateプログラムをLoadして走らせる

(3)新しいPIC_colo_Debuggerのhexファイルとelfファイルを指定する。

   (再度Setupを完了する)

(4)新しいPIC_colo_DebuggerプログラムをLoadする

  (0x0番地から0x0fff番地に書き込まれる)

 (5)”Reset”コマンドを実行する

  (新しいPIC_colo_Debuggerが走り出す)

 

0x1000番地以降にはPIC_colo_Updateプログラムが残っていますが、別のユーザ・プログラムをLoadしたときに上書きされるので、問題ありません。

 

 どうやら上手く行きそうです。PIC_coloのリリースに向けて、大きなハードルを一つ飛び越えました。

パチパチパチ~

 

PIC_colo Common_Frameが動いた

 PIC_coloを使ったGUIアプリケーションのテンプレートとして用意したCustom_Frame(<==以前はUser_Frameと呼んでいた)をサンプル・プログラム用に作り直したCommon_Frameが動きました。

f:id:denshikobo:20180524165415p:plain

Name欄にレジスタ名や変数名を入力すると、Value欄に現在値を表示します。入力に誤りがあるとValue欄に”null”を表示します。(<==get_infoコマンドで返るnullを表示している)

 

 Updateボタンをクリックするとチェックを付けた変数あるいはレジスタValue欄の値を更新します。

 また、Value欄の値を書き換えるとName欄に表示されたレジスタあるいは変数を書き換えます。

 さらに、Repeatボタンをクリックするとチェックを付けた変数あるいはレジスタValue欄の値を1秒ごとに更新します。

 パチパチ~

 

 少しずつ、機能を組み込んできたPIC_coloコンソールですが、Common_Frameの登場であちこち機能の重複が目立ってきました。Common_Frame自体も、人手でコマンドの送受を行うつもりで組み込んだ機能が、処理状態を表示する窓になってしまいました。orz

 

 最初に仕様をがっちり固めないで、その時々の思いつきで開発を進めた弊害と言えば、その通りなんですが・・・

 まぁ、しょうがない!(<==懲りない奴)

ーーーーーーーーーーーーーーーーーーーーー

最初の頃のUser_Frameはこんな感じでした。

f:id:denshikobo:20180128140209p:plain

PIC_colo Thereminの開発初期に使っていたのはこれです。

f:id:denshikobo:20180504125515p:plain

 思えば、Custom_Frameも立派に育ったものです。

『PIC_coloの手引き』をCommon_Frameを使ったものに書き換えなくては・・・

 

PIC_colo_Thereminのセンサーを変更することにした

PIC_colo_Thereminのセンサーには超音波センサ(これ↓)を使う予定でした。

http://akizukidenshi.com/catalog/g/gM-11009/

 

ところが期待したほどの測距可能距離が得られません。

orz

 

10数個のセンサで測距可能距離を調べても、大きな違いは無かったので、PIC_colo_Thereminに使ったセンサの不具合では無さそうです。

 

さらに・・・

超音波センサの感度を調べていて別の問題に気づきました。センサの反応が0.2~0.3秒遅れるのです。

 

超音波センサ内部の計測処理で何らかのフィルタリングを行った結果だと推察しています。

 

別の光学センサ(これ↓)を調べてみると測距可能距離の改善は期待できることが確認されました。反応の遅れも(少し遅延はあるものの)超音波センサよりは良さそうです。

http://akizukidenshi.com/catalog/g/gI-02551/

操作に用いる発泡スチロールの玉との相性も良いのですが、計測電圧から測距値への変換に少し工夫が必要です。

f:id:denshikobo:20180520170155p:plain

5cm以内では操作しないことにすれば、簡単な変換テーブルでなんとか行けそうです。

 

PIC_colo_Thereminは赤外線測距センサを使って、再設計することを決意しました。