"cgpic.exe"がクラッシュ [PICkit3]
(2012.01.29)
PIC10F322のプログラム・サイズが厳しくなってきて、殆どの関数をインライン・アセンブラで書き直しています。HITECH-Cが生成したコードの無駄を省くだけで何とかなりそうな見通しですが、デバッグは未だこれからなので、少しでも余裕を設けておく必要があります。
そこで、さらにインライン・アセンブラ化を進めたところ・・・
エラー・メッセージが表示された
初めて遭遇するエラー（というかリンカのバグ？）です。リビジョン管理などせずにコードをガシガシ書き換えたので、簡単には元に戻せません。エラー箇所を特定する常套手段（エラーが出なくなるまでプログラムをコメント・アウトする）で、不具合状況が明らかになりました。
nco_resetは別のCソース・ファイルに定義された関数で、main.cでも呼び出し（nco_resetはglobal定義されている）ています。それをserial_comm.cの中から呼び出す部分をインライン・アセンブラにした結果、生じたエラーです。HITECH-Cはv9.83を使っています。
ちゃんと勉強しないで適当に作業を進めているので、HITEC-Cのリンカに適切な指示を出す方法が判りません。orz
コード・サイズには影響しないようなので、このまま作業を進めるつもりです。
PIC10F322のプログラム・サイズが厳しくなってきて、殆どの関数をインライン・アセンブラで書き直しています。HITECH-Cが生成したコードの無駄を省くだけで何とかなりそうな見通しですが、デバッグは未だこれからなので、少しでも余裕を設けておく必要があります。
そこで、さらにインライン・アセンブラ化を進めたところ・・・
エラー・メッセージが表示された初めて遭遇するエラー（というかリンカのバグ？）です。リビジョン管理などせずにコードをガシガシ書き換えたので、簡単には元に戻せません。エラー箇所を特定する常套手段（エラーが出なくなるまでプログラムをコメント・アウトする）で、不具合状況が明らかになりました。
＜エラーを起こしたコード＞
void serial_comm_main(void)
{
#asm
_s_comm_main1:
movf (_sync_error),w
|（省略）
_reset_command:
fcall _nco_reset
goto _s_comm_main44
＜エラーにならないコード（nco_resetを呼び出す所だけＣの関数コールにする）＞
_reset_command:
#endasm
nco_reset();
#asm
goto _s_comm_main44
nco_resetは別のCソース・ファイルに定義された関数で、main.cでも呼び出し（nco_resetはglobal定義されている）ています。それをserial_comm.cの中から呼び出す部分をインライン・アセンブラにした結果、生じたエラーです。HITECH-Cはv9.83を使っています。
ちゃんと勉強しないで適当に作業を進めているので、HITEC-Cのリンカに適切な指示を出す方法が判りません。orz
コード・サイズには影響しないようなので、このまま作業を進めるつもりです。
 |
 |
 |
イマイチでも（なんとか）使う [PICkit3]
(2012.01.27)
先日、”Stimulusが使えるようになってシミュレータを利用するメリットを感じた”と書いたのですが、やっぱり”イマイチ”な部分が出てきて悩まされています。
実機では入る割り込み（TMR2、IOC、NCO）がMPLAB SIMでは入りません（要求フラグが立っても割り込みハンドラが呼び出されない）。”StimulusでPIRbits.TMR2IFをセットすると割り込みハンドラが呼び出される”と思ったのも勘違いでした。
シミュレーション開始から100μSインターバルでPIRbits.TMR2IFをセットするようにStimulusを設定したところ、TMR2の割り込みハンドラが呼び出されました。
『しめしめ、これなら行ける！』と思ったのですが・・・
色々試していて、StimulusのPIRbits.TMR2IF設定とTMR2割り込みハンドラの呼び出しが一致しないことに気付きました。
結局、割り込みハンドラを呼び出していたのは、インターバル（=1ms)が正しくシミュレートできていないTMR0割り込みでした。（シミュレーション開始から600μS以内にTMR0割り込みが３回入っていた）
Stimulusについて判ったことは以下の通りです。
（１）リセットするとStimulusのシミュレーション時刻は０クリアされる。
（２）”Run==>Break”を繰り返す間も、シミュレーション時刻は経過し、Stimulusの設定に応じた割り込み要求信号等が設定される。
（３）以下のように設定すると、（ほぼ）所定の時刻にTMR2割り込みハンドラを呼び出すことが出来る。
ただし、TMR0割り込みハンドラも呼び出される。
（４）IOCAFを設定するとIOCIFが設定される(2012.01.31 誤りでした）入力信号を変えてもIOCIFは設定されない。以下のように設定すると、（ほぼ）所定の時刻にIOC割り込みハンドラを呼び出すことが出来る。
ただし、TMR0割り込みハンドラも呼び出される。
（５）StimulusでADIFを設定すると（ADON=0でも）AD割り込みハンドラを呼び出すことができる。AD割り込みハンドラ内にブレー・ポイントを設定しておくと、（ほぼ）所定の時刻にシミュレーションを停止できる。（その後、シミュレーションを再開することもできる）
これで、なんとかシリアル通信の制御ロジックをデバッグするつもりです。
先日、”Stimulusが使えるようになってシミュレータを利用するメリットを感じた”と書いたのですが、やっぱり”イマイチ”な部分が出てきて悩まされています。
実機では入る割り込み（TMR2、IOC、NCO）がMPLAB SIMでは入りません（要求フラグが立っても割り込みハンドラが呼び出されない）。”StimulusでPIRbits.TMR2IFをセットすると割り込みハンドラが呼び出される”と思ったのも勘違いでした。
シミュレーション開始から100μSインターバルでPIRbits.TMR2IFをセットするようにStimulusを設定したところ、TMR2の割り込みハンドラが呼び出されました。
『しめしめ、これなら行ける！』と思ったのですが・・・
色々試していて、StimulusのPIRbits.TMR2IF設定とTMR2割り込みハンドラの呼び出しが一致しないことに気付きました。
結局、割り込みハンドラを呼び出していたのは、インターバル（=1ms)が正しくシミュレートできていないTMR0割り込みでした。（シミュレーション開始から600μS以内にTMR0割り込みが３回入っていた）
Stimulusについて判ったことは以下の通りです。
（１）リセットするとStimulusのシミュレーション時刻は０クリアされる。
（２）”Run==>Break”を繰り返す間も、シミュレーション時刻は経過し、Stimulusの設定に応じた割り込み要求信号等が設定される。
（３）以下のように設定すると、（ほぼ）所定の時刻にTMR2割り込みハンドラを呼び出すことが出来る。
時刻 TMR2IF TMR0 TMR2 150μS １ FF 00 250μS １ FF 00 350μS １ FF 00
ただし、TMR0割り込みハンドラも呼び出される。
（４）
時刻 RA2 IOCAF2 IOCIF TMR0
0μS 1 FF
1100μS 0 1 1 FF
1150μS 1 1 0 <== IOCIE = 0なのでIOCIFも0のまま
1250μS 0 1 1 FF
1350μS 1 1 1 FF
ただし、TMR0割り込みハンドラも呼び出される。
（５）StimulusでADIFを設定すると（ADON=0でも）AD割り込みハンドラを呼び出すことができる。AD割り込みハンドラ内にブレー・ポイントを設定しておくと、（ほぼ）所定の時刻にシミュレーションを停止できる。（その後、シミュレーションを再開することもできる）
これで、なんとかシリアル通信の制御ロジックをデバッグするつもりです。
|
|
|
|
MPLAB SIMが役に立った [PICkit3]
TMR2割り込みが入らなかったり、設定してもNCOが動かなかったりして、PIC10F322のMPLAB SIMには”イマイチ使えない感”を抱いていたのですが、”Stimulus”が使えるようになって漸くシミュレータを利用するメリットを感じました。
PIC10F322にシリアル通信機能を持たせる計画ですが、そのデバッグをどのように進めるか悩みました。テスト信号（動的に変化する入力信号）を加えて受信機能をテストしようと思っても、内部の動作が判らないのではデバッグになりません。（一か八かで試すことは出来ても、カットandトライでデバッグする気にはなれない）
そこでMPLAB SIMのUser's Guideを読み直し、Stimulus機能を使ってみました。動的な制御が必要なので”Pin/Register Actionsタブ”で時刻に応じてポート入力や割り込み要求フラグを制御してみました。
μS単位でRA2,IOCIF,TMR2IFの動作を設定して、”Apply”ボタンをクリックすると、シミュレータの応答メッセージがOutputウィンドウに表示されます。
こんな感じ
そこで”Run”する（F9キーを押す）と・・・
ブレーク・ポイントで止まる
AD割り込みにブレーク・ポイントを設定しておく（シミュレーション終了時刻=1600μSにPIR1.ADIFをセットしている）と、シミュレーション直後の状態が確認できるという訳です。
始めたばかりですが、”MPLAB SIMのStimulus”はなかなか使えそうです。
PIC10F322にシリアル通信機能を持たせる計画ですが、そのデバッグをどのように進めるか悩みました。テスト信号（動的に変化する入力信号）を加えて受信機能をテストしようと思っても、内部の動作が判らないのではデバッグになりません。（一か八かで試すことは出来ても、カットandトライでデバッグする気にはなれない）
そこでMPLAB SIMのUser's Guideを読み直し、Stimulus機能を使ってみました。動的な制御が必要なので”Pin/Register Actionsタブ”で時刻に応じてポート入力や割り込み要求フラグを制御してみました。
μS単位でRA2,IOCIF,TMR2IFの動作を設定して、”Apply”ボタンをクリックすると、シミュレータの応答メッセージがOutputウィンドウに表示されます。
こんな感じそこで”Run”する（F9キーを押す）と・・・
ブレーク・ポイントで止まるAD割り込みにブレーク・ポイントを設定しておく（シミュレーション終了時刻=1600μSにPIR1.ADIFをセットしている）と、シミュレーション直後の状態が確認できるという訳です。
始めたばかりですが、”MPLAB SIMのStimulus”はなかなか使えそうです。
|
|
|
|
なんとか復旧しました [PICkit3]
グシャグシャになってしまったPIC10F322の開発環境ですが、何とか復旧させることができました。
”アップデートしたMPLAB IDEをアン・インストールしても元に戻らない”と書きましたが、実はアン・インストール後も”C:\Program Files\Microchip\MPLAB IDE”以下にファイルが残っていることが気になっていました。
それをマニュアル操作で削除して、MPLAB IDEの最新版（V8.83）をインストールし直しました。しかし、それだけでは駄目（ターゲット・デバイス ミスマッチ）で、PICkit3を（パソコンから一旦外して）接続し直したところ、プログラマで書き込める（元の）状態に戻りました。（パチパチパチ～）
デバッガは相変わらずターゲット・デバイス ミスマッチになり、シミュレータの動作も変なままですが、取りあえず開発を進めることが出来るようになりました。
空きポートにLEDを付けて、割り込みの発生状況を確認したところ、TMR0割り込みもTMR2割り込みもちゃんと機能していました。NCO割り込みも入って一安心と思ったら、NCO1INCレジスタの値を変えてもNCO割り込みのインターバルが変化しません。NCOもシミュレータでは動作しないので、実機の中で何が起きているのか見当もつかず、暫く途方にくれていました。
NCO割り込みのインターバルから、NCO1INCレジスタが初期値のまま動作している（書き換わっていない）ように思われたので、NCO1INCLレジスタの設定方法（NCOをイネーブルする前にNCO1INCLレジスタを設定していた）を見直すことにしました。
マニュアルには以下のように書かれています。
20.1.4 INCREMENT REGISTERS
＜一部省略＞
The buffer loads are immediate when the module is disabled.
Writing to the MS register first is necessary
because then the buffer is loaded synchronously with
the NCOx operation after the write is executed on the
lower increment register.
前半部分を読むと、”NCOをイネーブルする前にNCO1INCLレジスタを設定する方法”で良さそうに思ったのですが、後半の”the buffer is loaded synchronously with the NCOx operation”に着目して、NCOをイネーブルしてからNCO1INCH、NCO1INCLの順にレジスタを設定してみました。すると・・・
”ビンゴ～！”
何だか釈然としませんが、取りあえずNCO割り込みも期待通りの動作になりました。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
”PICの開発はLEDピカピカから始まる”という鉄板セオリーはPICkit3になっても健在です。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
”アップデートしたMPLAB IDEをアン・インストールしても元に戻らない”と書きましたが、実はアン・インストール後も”C:\Program Files\Microchip\MPLAB IDE”以下にファイルが残っていることが気になっていました。
それをマニュアル操作で削除して、MPLAB IDEの最新版（V8.83）をインストールし直しました。しかし、それだけでは駄目（ターゲット・デバイス ミスマッチ）で、PICkit3を（パソコンから一旦外して）接続し直したところ、プログラマで書き込める（元の）状態に戻りました。（パチパチパチ～）
デバッガは相変わらずターゲット・デバイス ミスマッチになり、シミュレータの動作も変なままですが、取りあえず開発を進めることが出来るようになりました。
空きポートにLEDを付けて、割り込みの発生状況を確認したところ、TMR0割り込みもTMR2割り込みもちゃんと機能していました。NCO割り込みも入って一安心と思ったら、NCO1INCレジスタの値を変えてもNCO割り込みのインターバルが変化しません。NCOもシミュレータでは動作しないので、実機の中で何が起きているのか見当もつかず、暫く途方にくれていました。
NCO割り込みのインターバルから、NCO1INCレジスタが初期値のまま動作している（書き換わっていない）ように思われたので、NCO1INCLレジスタの設定方法（NCOをイネーブルする前にNCO1INCLレジスタを設定していた）を見直すことにしました。
マニュアルには以下のように書かれています。
20.1.4 INCREMENT REGISTERS
＜一部省略＞
The buffer loads are immediate when the module is disabled.
Writing to the MS register first is necessary
because then the buffer is loaded synchronously with
the NCOx operation after the write is executed on the
lower increment register.
前半部分を読むと、”NCOをイネーブルする前にNCO1INCLレジスタを設定する方法”で良さそうに思ったのですが、後半の”the buffer is loaded synchronously with the NCOx operation”に着目して、NCOをイネーブルしてからNCO1INCH、NCO1INCLの順にレジスタを設定してみました。すると・・・
”ビンゴ～！”
何だか釈然としませんが、取りあえずNCO割り込みも期待通りの動作になりました。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
”PICの開発はLEDピカピカから始まる”という鉄板セオリーはPICkit3になっても健在です。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
|
|
|
|
MPLAB IDEのアップデートでグシャグシャ [PICkit3]
MPLAB SIMでPIC10F322のデバッグを始めたのですが、TMR2割り込みの動作が何か変です。
以前、”デバッガでステップ実行しているときは割り込みが入らない（らしい）”ということを書きましたが、今回は違う現象で、ペリフェラルの割込みが受け付けられていないように思われます。（TMR0割込みは入る）
”もしかして、MPLAB SIMがPIC10F322にちゃんと対応出来ていないのかも”と考え、MPLAB IDEを最新版（V8.83）にアップデートすることにしました。
これまで、MPLAB IDEのアップデートでは何も問題無かったので気楽に作業を進めたのですが・・・
”ん！ターゲット・デバイス ミスマッチ（targetが0x2980で期待値は0x29c0）”
アップデートしたらプログラマで書き込めなくなってしまいました。
慌てて、MPLAB IDE(v8.83)をアン・インストールして元に戻そうとしたのですが・・・
戻りません。（泣）
それまで使っていたMPLAB IDEのバージョン（多分v.8.76）のインストーラをMPLAB Archivesから持ってきてインストールしても駄目です。
ここに来て、突然PIC10F322の開発が頓挫してしまいました。
一体、どーすれば良いのでしょうか？
以前、”デバッガでステップ実行しているときは割り込みが入らない（らしい）”ということを書きましたが、今回は違う現象で、ペリフェラルの割込みが受け付けられていないように思われます。（TMR0割込みは入る）
”もしかして、MPLAB SIMがPIC10F322にちゃんと対応出来ていないのかも”と考え、MPLAB IDEを最新版（V8.83）にアップデートすることにしました。
これまで、MPLAB IDEのアップデートでは何も問題無かったので気楽に作業を進めたのですが・・・
”ん！ターゲット・デバイス ミスマッチ（targetが0x2980で期待値は0x29c0）”
アップデートしたらプログラマで書き込めなくなってしまいました。
慌てて、MPLAB IDE(v8.83)をアン・インストールして元に戻そうとしたのですが・・・
戻りません。（泣）
それまで使っていたMPLAB IDEのバージョン（多分v.8.76）のインストーラをMPLAB Archivesから持ってきてインストールしても駄目です。
ここに来て、突然PIC10F322の開発が頓挫してしまいました。
一体、どーすれば良いのでしょうか？
|
|
|
|
デバッガ接続に５１２ワードの壁 [PICkit3]
PIC10F322をブレッド・ボードに乗せて、PICkit3を接続しました。無事にデバイスを認識したので、早速デバッグにとりかかろうとしたのですが、リンカでマッピング・エラーになってしまいました。
”あれ～、間違えてコードを書き換えたのか？”
しかし、コード調べてもおかしな所はありません。
”ん！デバッグ・モードに変えたせい？”
”ビンゴ～”<==でも全然うれしくない
DebugモードからReleaseモードに戻すとマッピング・エラーは無くなりました。
PICkit3のデバッガを使うとき、実機（PIC10F322)上にデバッガ用のコードが追加される（らしい）のです。プログラム・メモリに５０ワードくらいの余裕が出来たので、”なんとかなるんじゃないか？”と期待したのですが追加されるデバッガ用コードはもっと大きかった（２００ステップくらい？）ようです。
LCD表示器を接続してデバッグ・メッセージを表示することも出来ないので、実機デバッグの進め方に大きな問題を抱えてしまいました。取りあえず、simulatorで出来そうなところ（タイマ割り込みとか）のデバッグを始めるつもりです。
”あれ～、間違えてコードを書き換えたのか？”
しかし、コード調べてもおかしな所はありません。
”ん！デバッグ・モードに変えたせい？”
”ビンゴ～”<==でも全然うれしくない
DebugモードからReleaseモードに戻すとマッピング・エラーは無くなりました。
PICkit3のデバッガを使うとき、実機（PIC10F322)上にデバッガ用のコードが追加される（らしい）のです。プログラム・メモリに５０ワードくらいの余裕が出来たので、”なんとかなるんじゃないか？”と期待したのですが追加されるデバッガ用コードはもっと大きかった（２００ステップくらい？）ようです。
LCD表示器を接続してデバッグ・メッセージを表示することも出来ないので、実機デバッグの進め方に大きな問題を抱えてしまいました。取りあえず、simulatorで出来そうなところ（タイマ割り込みとか）のデバッグを始めるつもりです。
|
|
|
|
MPLAB SIMの落とし穴 [PICkit3]
（2011.12.16）
以前、このブログの中で『MPLAB SIMは有用なツールの一つだが、それに頼りきりになるのは危険だ』と書きました。意味ありげですが、空疎な言葉であったと反省しました。
温度コントローラの出力機能を確認（まだ計測補正機能のデバッグ中なので準備だけ）しようとして、SSRの制御信号を出力するプログラムを動かしてみることにしました。まさかポートの制御にこれほど苦労させられるとも思わずに・・・
本来は温度計測値に基づいてデューティ制御を行うのですが、確認だけなのでモード切替で制御出力をON/OFFすることにしました。ところがモードを替えても出力がLOWのまま変化しません。
”あれ～、出力ピンを間違えたのか？”
”出力ピンがGNDと半田ブリッジしているとか？”
最初は（これまでの反省を生かして）自分のミスを疑いました。しかし、単純な配線なのでミスを見逃している可能性はほぼ０です。
”となると、プログラム・バグか！”
再三書いていますが、PIC18F14K50は専用のヘッダが無いとデバッガが使えません。有り難いことにMPLAB SIMならPIC18F14K50でも使えるので、早速シミュレータを起動してプログラムの動作を調べてみると・・・
”あれ～、ちゃんと動いてるじゃないか！”
ANSELやTRISBの設定も（正常に動作するのだから当然）問題ありません。
”配線もOK”
”プログラムもOK” <== MPLAB SIMの結果を信じきっている
”それじゃ、何故実機だと動かないんだ？”
どこをどう調べれば良いのか見当もつかず、すっかり頭を抱えてしまいました。
結局、実機の初期化プログラムでLATBに0xffを書くと制御出力がHIになると判って、『変数の初期化漏れ』という不具合原因にたどり着くことが出来ました。
=======================================================
power_on_offを初期化しないと正しく動かないプログラム
=======================================================
ここに至って初めて、リセット起動の際にMPLAB SIMはFile Registerを（全て）０クリアすることに気付きました。実機ではFile Registerは不定値のまま起動するので、変数の初期値に依存したプログラムは正常に動作しなかったのです。
『MPLAB SIMを使うのは正にそれが必要なときなのだから、その結果に頼りたくなるのは止むを得ない。けれども、実機とは異なる部分があることを忘れてはいけない。』
以前、このブログの中で『MPLAB SIMは有用なツールの一つだが、それに頼りきりになるのは危険だ』と書きました。意味ありげですが、空疎な言葉であったと反省しました。
温度コントローラの出力機能を確認（まだ計測補正機能のデバッグ中なので準備だけ）しようとして、SSRの制御信号を出力するプログラムを動かしてみることにしました。まさかポートの制御にこれほど苦労させられるとも思わずに・・・
本来は温度計測値に基づいてデューティ制御を行うのですが、確認だけなのでモード切替で制御出力をON/OFFすることにしました。ところがモードを替えても出力がLOWのまま変化しません。
”あれ～、出力ピンを間違えたのか？”
”出力ピンがGNDと半田ブリッジしているとか？”
最初は（これまでの反省を生かして）自分のミスを疑いました。しかし、単純な配線なのでミスを見逃している可能性はほぼ０です。
”となると、プログラム・バグか！”
再三書いていますが、PIC18F14K50は専用のヘッダが無いとデバッガが使えません。有り難いことにMPLAB SIMならPIC18F14K50でも使えるので、早速シミュレータを起動してプログラムの動作を調べてみると・・・
”あれ～、ちゃんと動いてるじゃないか！”
ANSELやTRISBの設定も（正常に動作するのだから当然）問題ありません。
”配線もOK”
”プログラムもOK” <== MPLAB SIMの結果を信じきっている
”それじゃ、何故実機だと動かないんだ？”
どこをどう調べれば良いのか見当もつかず、すっかり頭を抱えてしまいました。
結局、実機の初期化プログラムでLATBに0xffを書くと制御出力がHIになると判って、『変数の初期化漏れ』という不具合原因にたどり着くことが出来ました。
=======================================================
power_on_offを初期化しないと正しく動かないプログラム
unsigned char power_on()
{
if( power_on_off == FLAG_OFF )
{
power_on_off = FLAG_ON;
SSR_CTRL = 1;
return OK_FLAG;
}
return ERROR_FLAG;
}
=======================================================
ここに至って初めて、リセット起動の際にMPLAB SIMはFile Registerを（全て）０クリアすることに気付きました。実機ではFile Registerは不定値のまま起動するので、変数の初期値に依存したプログラムは正常に動作しなかったのです。
『MPLAB SIMを使うのは正にそれが必要なときなのだから、その結果に頼りたくなるのは止むを得ない。けれども、実機とは異なる部分があることを忘れてはいけない。』
|
|
|
|
PIC18のlong演算 [PICkit3]
先日のブログで”long intを使った計算を外しても殆どプログラム・サイズが減らない”と記しました。”もしかして、longの計算が標準で組み込まれている？”なんて怪しげなことまで書いてしまいましたが、後学のため事の真偽を確かめてみることにしました。
以下の関数を定義して、TEST_PROGの定義／未定義でプログラムがどのように変化するのか調べました。
long calc( long v1, long v2, long v3)
{
#ifdef TEST_PROG
return (v1*v2)/v3;
#else
return 0;
#endif
}
その結果、以下のmathライブラリ（144ワード）がTEST_PROGを定義したときに組み込まれることが判りました。
374-3E3 C:\MCC18\src\traditional\math\fxm3232.c
3E4-44B C:\MCC18\src\traditional\math\fxd3232s.asm
44C-493 C:\MCC18\src\traditional\math\fxd3232u.c
なので、”longの計算が標準で組み込まれている”なんてことはありませんでした。
多謝！ <(_ _)>
ついでに、ライブラリの中を眺めていて気になることを見つけました。PIC18系のデバイスにはハードウェア乗算器が搭載されていて、こんなプログラムで８×８の乗算が出来る筈なのですが、mathライブラリでMULWF命令を使用している形跡が有りません。
========================================
8 x 8 UNSIGNED MULTIPLY ROUTINE
MOVF ARG1, W ;
MULWF ARG2 ; ARG1 * ARG2 -> PRODH:PRODL
========================================
さらに調べてみると、”C:\MCC18\src\extended\math\”以下のディレクトリにMULWF命令を使った算術ライブラリが用意されていました。しかし、Ｃコンパイラのユーザーズ・ガイドを調べても、こちら（extendedディレクトリ）のライブラリを利用する方法が見つかりません。
使いたければ”５００ドル払え（有償版のコンパイラを購入しろ）”と言う事なんでしょうか？
まぁ、extended\math\以下のコードをインライン・アセンブラで組み込んだ自前のライブラリを用意すれば済むことなんですが、なんか癪に障る話です。
以下の関数を定義して、TEST_PROGの定義／未定義でプログラムがどのように変化するのか調べました。
long calc( long v1, long v2, long v3)
{
#ifdef TEST_PROG
return (v1*v2)/v3;
#else
return 0;
#endif
}
その結果、以下のmathライブラリ（144ワード）がTEST_PROGを定義したときに組み込まれることが判りました。
374-3E3 C:\MCC18\src\traditional\math\fxm3232.c
3E4-44B C:\MCC18\src\traditional\math\fxd3232s.asm
44C-493 C:\MCC18\src\traditional\math\fxd3232u.c
なので、”longの計算が標準で組み込まれている”なんてことはありませんでした。
多謝！ <(_ _)>
ついでに、ライブラリの中を眺めていて気になることを見つけました。PIC18系のデバイスにはハードウェア乗算器が搭載されていて、こんなプログラムで８×８の乗算が出来る筈なのですが、mathライブラリでMULWF命令を使用している形跡が有りません。
========================================
8 x 8 UNSIGNED MULTIPLY ROUTINE
MOVF ARG1, W ;
MULWF ARG2 ; ARG1 * ARG2 -> PRODH:PRODL
========================================
さらに調べてみると、”C:\MCC18\src\extended\math\”以下のディレクトリにMULWF命令を使った算術ライブラリが用意されていました。しかし、Ｃコンパイラのユーザーズ・ガイドを調べても、こちら（extendedディレクトリ）のライブラリを利用する方法が見つかりません。
使いたければ”５００ドル払え（有償版のコンパイラを購入しろ）”と言う事なんでしょうか？
まぁ、extended\math\以下のコードをインライン・アセンブラで組み込んだ自前のライブラリを用意すれば済むことなんですが、なんか癪に障る話です。
|
|
|
|
PIC16F887にOnboard書き込みが出来なくなった [PICkit3]
これまで何度も行なってきた手順に従って、操作・表示モジュールのプログラムをOnboardで書き換えようとしたのですが、突然出来なくなってしまいました。
Outputウィンドウには”verify complete”と表示され、正しく書き込めたように思えます。ところがresetを掛けると、以下のエラー・メッセージが出て、先に進めません。
PK3Err0040: The target device is not ready for debugging.
Please check your Configuration bit settings and program（以下省略）
このエラー・メッセージは、これまでにも何回か出会っています。例えば”クロックが動いていない”とか、”コンフィグの設定がDEBUG_OFF”だったとか・・・
ところが今回はいくら調べても（それまで動いていたプログラムなのです）原因が判りません。
実は、I2Cライブラリの開発中に操作・表示モジュールへのOnboard書き込みが不安定な様子を示す事は度々ありました。一回目の書き込みで正しく起動しないときに、同じプログラムをもう一回書き込むと動くようになるのです。結果オーライで作業を進めてきましたが、とうとう行き詰まってしまいました。
『問題は書き込む際のVdd電圧なのではないか』と考えています。PICkit3のUser's Manualに以下の記述があります。
”For programming, no clock is needed on the target device, but power must be supplied.”
ところが、書き込み時に必要なVddの電圧に関する記述が（探した限りでは）見つからないのです。 PICのUSER'S FORUMかどこかで4.5V以上という数値を見た気もするのですが、定かではありません。
確かにVddを５Vにして書き込むと一発で正しく書き込めます。今回も、Onboardで書き込めなかったデバイスをブレッド・ボードに移して、Vddを５Vにすると正しく書き込める（デバッガで動作する）ことが分かりました。ターゲット・ボードでも電源電圧を５Vにして書き込めれば良いのですが、同じVddにつながっているLCD（3.3V仕様）の最大定格（＝4.5V）が問題です。
書き込みの度にLCDを取り外したりすると、コネクタのピンを曲げてしまったり、接触不良を起こしたりしそうで、心配です。問題を起こす前にさっさと５V系のLCDに変更した方が良いかなぁ〜。
Outputウィンドウには”verify complete”と表示され、正しく書き込めたように思えます。ところがresetを掛けると、以下のエラー・メッセージが出て、先に進めません。
PK3Err0040: The target device is not ready for debugging.
Please check your Configuration bit settings and program（以下省略）
このエラー・メッセージは、これまでにも何回か出会っています。例えば”クロックが動いていない”とか、”コンフィグの設定がDEBUG_OFF”だったとか・・・
ところが今回はいくら調べても（それまで動いていたプログラムなのです）原因が判りません。
実は、I2Cライブラリの開発中に操作・表示モジュールへのOnboard書き込みが不安定な様子を示す事は度々ありました。一回目の書き込みで正しく起動しないときに、同じプログラムをもう一回書き込むと動くようになるのです。結果オーライで作業を進めてきましたが、とうとう行き詰まってしまいました。
『問題は書き込む際のVdd電圧なのではないか』と考えています。PICkit3のUser's Manualに以下の記述があります。
”For programming, no clock is needed on the target device, but power must be supplied.”
ところが、書き込み時に必要なVddの電圧に関する記述が（探した限りでは）見つからないのです。 PICのUSER'S FORUMかどこかで4.5V以上という数値を見た気もするのですが、定かではありません。
確かにVddを５Vにして書き込むと一発で正しく書き込めます。今回も、Onboardで書き込めなかったデバイスをブレッド・ボードに移して、Vddを５Vにすると正しく書き込める（デバッガで動作する）ことが分かりました。ターゲット・ボードでも電源電圧を５Vにして書き込めれば良いのですが、同じVddにつながっているLCD（3.3V仕様）の最大定格（＝4.5V）が問題です。
書き込みの度にLCDを取り外したりすると、コネクタのピンを曲げてしまったり、接触不良を起こしたりしそうで、心配です。問題を起こす前にさっさと５V系のLCDに変更した方が良いかなぁ〜。
|
|
|
|
HI-TECH C で#ifdef __DEBUGを使う [PICkit3]
I2Cライブラリの開発ではDEBUGモードとRELEASEモードを切り替えて、何度もコンパイルしました。PIC18F2550はMPLAB IDEのプルダウン・メニューの操作だけで済むのですが、PIC16F887の方はmain.cの__CONFIGを毎回書き換えていたのです。
あるとき、BUILDウィンドウをスクロールするHI-TCH Cのコマンドを何気無く眺めていて”-D_DEBUG=1”という記述に気付きました。
『ん、これってシンボル定義のコンパイラ・オプション？』
試してみると・・・ビンゴ！
MPLAB IDEのプルダウン・メニューで”DEBUG”を指定するとこのオプションが指定され、”RELEASE”では指定されないことが分かりました。
つまり、以下のように記述すればモードを切り替える度に書き換えなくとも良くなるのです。
#ifdef __DEBUG
// for DEBUG
__CONFIG (FOSC_INTRC_NOCLKOUT & PWRTE_OFF & ... & DEBUG_ON );
#else
// for RELEASE
__CONFIG (FOSC_INTRC_NOCLKOUT & PWRTE_ON & ... & DEBUG_OFF );
#endif
”今頃気付いたのか！”ってお叱りを受けるかも知れませんが、HI-TECH Cのサンプル・プログラムには出てきません。また、MPLAB C18の例にも出てこない（多分ユーザの目に触れない所でやっている）ので、この機能の存在に気づかなかったのです。
まぁ、DEBUGモードとRELEASEモードの切り替えを何度も繰り返すことなど、あんまり無い（そうで有って欲しい）気もしますが、知っていて損は無い小技だと思います。
あるとき、BUILDウィンドウをスクロールするHI-TCH Cのコマンドを何気無く眺めていて”-D_DEBUG=1”という記述に気付きました。
『ん、これってシンボル定義のコンパイラ・オプション？』
試してみると・・・ビンゴ！
MPLAB IDEのプルダウン・メニューで”DEBUG”を指定するとこのオプションが指定され、”RELEASE”では指定されないことが分かりました。
つまり、以下のように記述すればモードを切り替える度に書き換えなくとも良くなるのです。
#ifdef __DEBUG
// for DEBUG
__CONFIG (FOSC_INTRC_NOCLKOUT & PWRTE_OFF & ... & DEBUG_ON );
#else
// for RELEASE
__CONFIG (FOSC_INTRC_NOCLKOUT & PWRTE_ON & ... & DEBUG_OFF );
#endif
”今頃気付いたのか！”ってお叱りを受けるかも知れませんが、HI-TECH Cのサンプル・プログラムには出てきません。また、MPLAB C18の例にも出てこない（多分ユーザの目に触れない所でやっている）ので、この機能の存在に気づかなかったのです。
まぁ、DEBUGモードとRELEASEモードの切り替えを何度も繰り返すことなど、あんまり無い（そうで有って欲しい）気もしますが、知っていて損は無い小技だと思います。
|
|
|
|
