denshikobo’s blog

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

PIC_colo_miniでDAC_ADCサンプルが動いた

PIC_colo_miniで提供するサンプル・プログラムは以下の6種です。

(1)Blink(Lチカ)
(2)sw_operation
(3)dac_adc
(4)pwm
(5)EEPROM
(6)Flash_Memory

 

2011年頃にやったDebug Expressのチュートリアルとほぼ一緒の構成です。その辺りのことはこちら(↓)をご覧下さい。

https://broadbeans.blog.so-net.ne.jp/archive/20110518

 

ただし、Debug Expressのチュートリアルとは異なり、PIC_colo_ConsoleとPIC_colo_Debuggerの使用を前提としているので色々違いがあります。一番大きな違いは、Common_Frame(↓)を使ってプログラムの動作を確認するところです。

f:id:denshikobo:20180824113529p:plain

Value欄の表示はHexバイト配列になっていて、dacの初期設定が0x10(フルスケールの半分)のとき、adc_average(1024回の平均値)が0x01fe(フルスケールの半分)になることを示しています。

 

f:id:denshikobo:20180824113544p:plain

dacValue欄を0x18に変える(TextFieldの値を編集する)と、Common_Frameは変数dacに0x18を書き込むコマンドを送ります。PIC_colo_Debuggerがそれを受け取り、変数dacに0x18を書き込みます。DAC_ADCプログラムは変数dacの値をDACCON1レジスタに設定し、AD変換と平均値の計算を反復して、変数adc_averageの値が0x02fe(フルスケールの3/4)に変わります。

dacの値を0x00から0x1fまで書き換え、変数dacの値に応じて変数adc_averageの値が変わることを確認します。

 

 Value欄をもっと気の利いた表示(adc_averageを電圧で表示するとか)に出来ると良いのですが・・・

 

Common_Frameでは出来ませんが、応用アプリケーションで使うCustom_Frameは、Value欄に表示パラメータ(スケーリングと単位表示)を設けて、PIC_coloユーザがValue欄の表示を容易にカスタマイズ出来るよう配慮しています。

PIC_colo_miniがようやく動いた

PIC16F1829を使ったPIC_colo_miniがようやく動きました。組み立てたのはまだ1台だけです。今年の夏は、あまりに暑いので半田付け作業をする気になれませんでした。(^_^;)

 

PIC16F1788用PIC_coloデバッガをPIC16F1829用に書き換える作業はスムーズに進んだのですが、PIC16F1829に書き込もうとしてPICkit3がConnection Failedになる不具合に見舞われました。ひとしきり修復を試みたものの結局断念してPICkit4(↓)を入手することにしました。

http://ec.akizukidenshi.com/catalog/g/gM-13337/

届いたPICkit4を使ってPIC_coloデバッガをPIC16F1829に書き込み、これで動くと思ったら・・・PIC_colo_consoleがSetup Completeになりません。pic16f1829.hを読み込ませてもDevice not foundのままです。orz

 

PIC_colo_consoleのコードを調べたところ、PIC16F1829が解析対象デバイスから抜けていました。それを追加してPIC_colo_consoleが正常に動作するようになりました。用意しておいたBlinkプログラムをロードして実行するとLEDが点滅を始めました。パチパチパチ~

 

その後、プッシュSW周りのパターンのミス(1カ所)を修正してPIC_colo_miniがようやく動きました。

やれやれ

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のリリースに向けて、大きなハードルを一つ飛び越えました。

パチパチパチ~