MCCに騙された [MPLABXとXC8]
（2017-11-06)
MCC（MPLAB Code Configurator）はMicrochip社が提供しているコード生成ツールです。PICのペリフェラルを制御するライブラリの自動生成、制御レジスタの初期設定、割り込みハンドラの自動生成など、プロジェクトの立ち上げ時に必要な作業の多くを代行してくれる『優れもの』です。
新しいPICデバイスを使うときは、どんな制御レジスタがあって、どんな設定が必要か、予め調べる必要がありました（今でも必要が無くなった訳ではない）が、今は先ずMCCで粗々設定することが多くなりました。タイマー割り込みでLチカ程度のプログラムなら、自動生成されたプログラムのメイン・ループにポートのON/OFFを書き足すだけで、動いてしまいます。
で、ついついMCCに頼ってしまうのですが・・・
PIC16F1788の5bitDAC（二つ）と8bitDAC（一つ）を組み合わせて12bitDACとして動作させることが出来ないか？試してみることにしました。
MCCでDAC1、DAC2,DAC4の初期設定を行い、Pic-coloで設定値を書き換えながらDACの出力をADCで計測して画面に表示してみました。しかし、何だかDAC２とDAC4の出力が変です。
ここで始めてマニュアルに目を通して、DAC制御レジスタの値を調べました。
あれ？MCCで行った設定と制御レジスタの値が対応していません。
FVR2とVccとVrefの三択
DACx Positive Source Select bitの設定は”１”でVref+の設定になっています。
レジスタはVccとVref+の二択
Vref+にはDAC2の出力を接続するので、これではDAC2もDAC4も正しく動作しません。orz
便利に使っているMCCなんですが、こういう不具合を経験するのは初めてではありません（実はちょくちょく有る）。MCCが無かった頃のことを思えば、これくらいは大目に見てあげても良いかなぁ～
MCC（MPLAB Code Configurator）はMicrochip社が提供しているコード生成ツールです。PICのペリフェラルを制御するライブラリの自動生成、制御レジスタの初期設定、割り込みハンドラの自動生成など、プロジェクトの立ち上げ時に必要な作業の多くを代行してくれる『優れもの』です。
新しいPICデバイスを使うときは、どんな制御レジスタがあって、どんな設定が必要か、予め調べる必要がありました（今でも必要が無くなった訳ではない）が、今は先ずMCCで粗々設定することが多くなりました。タイマー割り込みでLチカ程度のプログラムなら、自動生成されたプログラムのメイン・ループにポートのON/OFFを書き足すだけで、動いてしまいます。
で、ついついMCCに頼ってしまうのですが・・・
PIC16F1788の5bitDAC（二つ）と8bitDAC（一つ）を組み合わせて12bitDACとして動作させることが出来ないか？試してみることにしました。
MCCでDAC1、DAC2,DAC4の初期設定を行い、Pic-coloで設定値を書き換えながらDACの出力をADCで計測して画面に表示してみました。しかし、何だかDAC２とDAC4の出力が変です。
ここで始めてマニュアルに目を通して、DAC制御レジスタの値を調べました。
あれ？MCCで行った設定と制御レジスタの値が対応していません。
FVR2とVccとVrefの三択DACx Positive Source Select bitの設定は”１”でVref+の設定になっています。
レジスタはVccとVref+の二択Vref+にはDAC2の出力を接続するので、これではDAC2もDAC4も正しく動作しません。orz
便利に使っているMCCなんですが、こういう不具合を経験するのは初めてではありません（実はちょくちょく有る）。MCCが無かった頃のことを思えば、これくらいは大目に見てあげても良いかなぁ～
chipKIT Import プラグインを試してみた [MPLABXとXC8]
電子工作の世界で大流行しているArduinoですが、親族SNS管理人は（何となく）敬遠していました。
しかし、Microchip社がAtmel社を買収して以来AVRやArduinoにも興味を覚えるようになりました。そしてつい先日、Arduino UNO互換機（これ）とLCD-KeyPADシールド（これ）を購入し、Arduinoの世界にそろりと足を踏み入れたと言うわけです。
両方合わせて￥１２００しないという価格に、まずビックリ。そして、Arduino IDEとスケッチを使った電子工作の手軽さにまたビックリ！世界中で受け入れられ、活発なCommunityがいくつも立ち上がった理由が良く分かります。
あれこれArduinoの世界を覗き込んでいて、こんな物（↓）を見つけてしまいました。
http://chipkit.net/wiki/index.php?title=MPLABX_Importer#Locate_the_Plugin_Menu
なんと、ArduinoのスケッチをMPLAB-Xのprojectに落とし込んで、MPLAB-Xでデバッグできるようにするプラグインです。
早速、試してみた
ビルドしてHexファイルが生成される所まで確認できました。MPLAB-XのNavigate機能を使って、Arduinoのプログラム構造を自由に調べることが出来ます。
これは良いオモチャを手に入れました。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
しかし、ArduinoがここまでPICの世界に入り込んでいたなんて、全く気づいていませんでした。
chikPIT社、恐るべし！
しかし、Microchip社がAtmel社を買収して以来AVRやArduinoにも興味を覚えるようになりました。そしてつい先日、Arduino UNO互換機（これ）とLCD-KeyPADシールド（これ）を購入し、Arduinoの世界にそろりと足を踏み入れたと言うわけです。
両方合わせて￥１２００しないという価格に、まずビックリ。そして、Arduino IDEとスケッチを使った電子工作の手軽さにまたビックリ！世界中で受け入れられ、活発なCommunityがいくつも立ち上がった理由が良く分かります。
あれこれArduinoの世界を覗き込んでいて、こんな物（↓）を見つけてしまいました。
http://chipkit.net/wiki/index.php?title=MPLABX_Importer#Locate_the_Plugin_Menu
なんと、ArduinoのスケッチをMPLAB-Xのprojectに落とし込んで、MPLAB-Xでデバッグできるようにするプラグインです。
早速、試してみたビルドしてHexファイルが生成される所まで確認できました。MPLAB-XのNavigate機能を使って、Arduinoのプログラム構造を自由に調べることが出来ます。
これは良いオモチャを手に入れました。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
しかし、ArduinoがここまでPICの世界に入り込んでいたなんて、全く気づいていませんでした。
chikPIT社、恐るべし！
Local Historyを有効にした [MPLABXとXC8]
(2015.07.08)
MPLABXになってバージョン管理ソフト（SVN,GIT,CVSなど）との連携が強化されましたが、MPLABX自体にプログラムの履歴を管理する機能（Local History）が備わっていることを（最近）知りました。
Tool->Options->Teamと辿って、Versioningタブを選択すると、バージョン管理方法を選択するメニューが表示されます。そこで”Local History”を選択すれば設定完了です。
Local Historyを有効にした
ソースファイルを開き、編集画面の左上にある”History”をクリックすると、以前のファイルとの差分が表示されます。
改行を挿入して差分を表示してみた
これまでは、一旦修正した箇所を元に戻す場合に備えて、修正前のコードをコメントアウトしていたのですが、これからばそんな手間を掛けなくても良さそうです。
----------------------------------------------------------
Local Historyは、どうやらNetBeansの機能らしく、JAVAプログラムの開発環境でも使えることが判りました。
めでたし、めでたし
（これまで知らなかったのはお目出度い）
MPLABXになってバージョン管理ソフト（SVN,GIT,CVSなど）との連携が強化されましたが、MPLABX自体にプログラムの履歴を管理する機能（Local History）が備わっていることを（最近）知りました。
Tool->Options->Teamと辿って、Versioningタブを選択すると、バージョン管理方法を選択するメニューが表示されます。そこで”Local History”を選択すれば設定完了です。
Local Historyを有効にしたソースファイルを開き、編集画面の左上にある”History”をクリックすると、以前のファイルとの差分が表示されます。
改行を挿入して差分を表示してみたこれまでは、一旦修正した箇所を元に戻す場合に備えて、修正前のコードをコメントアウトしていたのですが、これからばそんな手間を掛けなくても良さそうです。
----------------------------------------------------------
Local Historyは、どうやらNetBeansの機能らしく、JAVAプログラムの開発環境でも使えることが判りました。
めでたし、めでたし
（これまで知らなかったのはお目出度い）
 |
 |
 |
MPLAB-XでStopWatchを使ってみた [MPLABXとXC8]
(2015.04.18)
PIC16F1705を使ったアプリケーションの開発を続けています。10mSインターバルで行う処理の中でlongデータの乗除算を行うのですが、その演算処理時間が気になり、MPLAB-XのStopWatch（シミュレータの機能）を使って確認することにしました。
StopWatchウィンドウを開く
ところが、最初のディレイ処理で変なことに気づきました。1msのディレイ・ループの処理時間が2msと表示されるのです。
1msのディレイに2ms掛かっている
？？？
調べてみると、シミュレータのプロパティにInstruction Frequency（1MHｚになっていた）があり、プログラムで設定したOSCCONレジスタの値（2MHzになる筈）はシミュレーション・クロックに反映されないらしいのです。
Instruction Frequencyが1MHｚになっていた
Instruction Frequencyを実機に合わせれば、正しい処理時間を計測出来る筈ですが、プロパティを変更する方法が直ぐには判りませんでした。orz
暫くジタバタして、ようやく”unlockボタンをクリックすれば設定変更が可能になる”ということに気づきました。
unlockボタンをクリックすると設定変更できる
ヤレヤレ
===================================
ちなみに、PIC16F1705の演算処理時間はこんな感じでした。
（Instruction Frequencyが1MHｚの場合）
unsigned int ix,iy;
unsigned long lx,ly;
__delay_ms(1); // 2.024ms
ix = 0x100;
iy = 0x0ff;
ix *= iy; // 192us
ix /= iy; // 352us
lx = 0x7fff;
ly = 0x7fff;
lx *= ly; // 511us
lx /= ly; // 968us
実機のInstruction Frequencyは2MHｚですが、longの乗除算は多用しない方が良さそうです。
制御方式の見直しが必要だなぁ
PIC16F1705を使ったアプリケーションの開発を続けています。10mSインターバルで行う処理の中でlongデータの乗除算を行うのですが、その演算処理時間が気になり、MPLAB-XのStopWatch（シミュレータの機能）を使って確認することにしました。
StopWatchウィンドウを開くところが、最初のディレイ処理で変なことに気づきました。1msのディレイ・ループの処理時間が2msと表示されるのです。
1msのディレイに2ms掛かっている？？？
調べてみると、シミュレータのプロパティにInstruction Frequency（1MHｚになっていた）があり、プログラムで設定したOSCCONレジスタの値（2MHzになる筈）はシミュレーション・クロックに反映されないらしいのです。
Instruction Frequencyが1MHｚになっていたInstruction Frequencyを実機に合わせれば、正しい処理時間を計測出来る筈ですが、プロパティを変更する方法が直ぐには判りませんでした。orz
暫くジタバタして、ようやく”unlockボタンをクリックすれば設定変更が可能になる”ということに気づきました。
unlockボタンをクリックすると設定変更できるヤレヤレ
===================================
ちなみに、PIC16F1705の演算処理時間はこんな感じでした。
（Instruction Frequencyが1MHｚの場合）
unsigned int ix,iy;
unsigned long lx,ly;
__delay_ms(1); // 2.024ms
ix = 0x100;
iy = 0x0ff;
ix *= iy; // 192us
ix /= iy; // 352us
lx = 0x7fff;
ly = 0x7fff;
lx *= ly; // 511us
lx /= ly; // 968us
実機のInstruction Frequencyは2MHｚですが、longの乗除算は多用しない方が良さそうです。
制御方式の見直しが必要だなぁ
|
|
|
|
PICの開発環境を更新した [MPLABXとXC8]
(2014.02.05)
久しぶりにMicrochip社のサイトを眺めていたところ、MPLABX（2.0）、XC8（1.30）、Application Library（2013_12_20）などが新しくなっていたので、インストールすることにしました。
http://www.microchip.com/pagehandler/en-us/devtools/mla/
http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/
http://www.microchip.com/pagehandler/en-us/family/mplabx/
XC8とApplication Libraryはインストール時に新たなディレクトリを作るので問題ありません（現在使っているものに影響しない）。しかし、MPLABX2.0は同じディレクトリ（￥MPLABX）に上書きしようとするので注意が必要です。親族SNS管理人はインストール先を”MPLABX2”に変え、従来のMPLABXも残すことにしました。
MPLABX（2.0）は対応デバイスが増えていて、PIC32MZシリーズ（330 DMIPS 12bit 28Msps A/D）も試せる（ただしシミュレータで）のはちょっとゾクゾクします。
嬉しかったのは、Application Libraryが漸くXC8対応になったことです。
（パチパチパチ～）
これで、2013年の暮れにXC8対応で苦労したことも昔話になりそうです。リリースがもう少し早ければ、あんな苦労する必要もなかったと思うと少し恨めしい気もします。
不思議なのは、最新のXC8（v1.30）が新しいライブラリに対応出来ていないということです。
調べたところ、以下のライブラリでエラー終了するようになっていました。
framework/crypto/crypto.h:54:#error XC8 v1.30 is not compatible
framework/crypto_hash/crypto_hash.h:54:#error XC8 v1.30 is not
framework/driver/spi/drv_spi.h:59:#error XC8 v1.30 is not
framework/driver/uart/drv_uart1.h:45:#error XC8 v1.30 is not
framework/driver/uart/drv_uart2.h:45:#error XC8 v1.30 is not
framework/driver/uart/drv_uart3.h:45:#error XC8 v1.30 is not
framework/driver/uart/drv_uart4.h:45:#error XC8 v1.30 is not
framework/fileio/fileio.h:49:#error XC8 v1.30 is not compatible
framework/fileio/fileio_lfn.h:49:#error XC8 v1.30 is not compatible
framework/usb/usb.h:32:#error XC8 v1.30 is not compatible
XC8 v1.21ならコンパイル出来るので、大きな問題ではありません。
しかし、何故こんなことになっているのか？
XC8 v1.31になれば大丈夫なのか？
今後の推移が気になります。
久しぶりにMicrochip社のサイトを眺めていたところ、MPLABX（2.0）、XC8（1.30）、Application Library（2013_12_20）などが新しくなっていたので、インストールすることにしました。
http://www.microchip.com/pagehandler/en-us/devtools/mla/
http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/
http://www.microchip.com/pagehandler/en-us/family/mplabx/
XC8とApplication Libraryはインストール時に新たなディレクトリを作るので問題ありません（現在使っているものに影響しない）。しかし、MPLABX2.0は同じディレクトリ（￥MPLABX）に上書きしようとするので注意が必要です。親族SNS管理人はインストール先を”MPLABX2”に変え、従来のMPLABXも残すことにしました。
MPLABX（2.0）は対応デバイスが増えていて、PIC32MZシリーズ（330 DMIPS 12bit 28Msps A/D）も試せる（ただしシミュレータで）のはちょっとゾクゾクします。
嬉しかったのは、Application Libraryが漸くXC8対応になったことです。
（パチパチパチ～）
これで、2013年の暮れにXC8対応で苦労したことも昔話になりそうです。リリースがもう少し早ければ、あんな苦労する必要もなかったと思うと少し恨めしい気もします。
不思議なのは、最新のXC8（v1.30）が新しいライブラリに対応出来ていないということです。
＜XC8 v1.30でコンパイルするとエラー終了する＞ make[2]: Leaving directory `C:/microchip/mla/v2013_12_20/apps/usb/device/hid_mouse/firmware/MPLAB.X' (908) exit status = 1 make[1]: Leaving directory `C:/microchip/mla/v2013_12_20/apps/usb/device/hid_mouse/firmware/MPLAB.X' make[2]: *** [build/LPCUSBDK_18F14K50/production/_ext/1360937237/app_device_mouse.p1] Error 1 make[1]: *** [.build-conf] Error 2 make: *** [.build-impl] Error 2 BUILD FAILED (exit value 2, total time: 8s)
調べたところ、以下のライブラリでエラー終了するようになっていました。
framework/crypto/crypto.h:54:#error XC8 v1.30 is not compatible
framework/crypto_hash/crypto_hash.h:54:#error XC8 v1.30 is not
framework/driver/spi/drv_spi.h:59:#error XC8 v1.30 is not
framework/driver/uart/drv_uart1.h:45:#error XC8 v1.30 is not
framework/driver/uart/drv_uart2.h:45:#error XC8 v1.30 is not
framework/driver/uart/drv_uart3.h:45:#error XC8 v1.30 is not
framework/driver/uart/drv_uart4.h:45:#error XC8 v1.30 is not
framework/fileio/fileio.h:49:#error XC8 v1.30 is not compatible
framework/fileio/fileio_lfn.h:49:#error XC8 v1.30 is not compatible
framework/usb/usb.h:32:#error XC8 v1.30 is not compatible
XC8 v1.21ならコンパイル出来るので、大きな問題ではありません。
しかし、何故こんなことになっているのか？
XC8 v1.31になれば大丈夫なのか？
今後の推移が気になります。
|
|
|
|
PIC18のEEPROMはややこしい [MPLABXとXC8]
(2014.01.30)
CTMUチャネルごとに微妙に異なる計測値を正規化（値域を０～８０００に揃える）しようと考えました。
＜計算式＞
normalize_ratio = 8000 *（current - min）/ （max - min）
計測値の最大／最小をEEPROMに記録し、再起動時にそれを読み出すことにして、その初期値をEEPROMに書き込もうとしたのですが・・・
以下のコードで上手く行くものと思っていましたが、XC8コンパイラにeeprom qualifierを無視されてしまいました。orz
＜駄目なコード＞
__eeprom UINT16 eeprom_ctmu_max[MTOUCH_SENSORS_NUMBER] = { 6000, 6000, 6000, 6000, 6000, 6000, 6000, 6000};
__eeprom UINT16 eeprom_ctmu_min[MTOUCH_SENSORS_NUMBER] = { 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000};
＜XC8コンパイラのメッセージ＞
SRC/ctmu_main.c:80: warning: qualifier "eeprom" ignored
SRC/ctmu_main.c:81: warning: qualifier "eeprom" ignored
？？？
『XC8のマニュアルを読む限り、これで良さそうなのに何故？』と思ったら、後ろの方にこんな記述がありました。
-----------------
2.5.9.4 CAVEATS
XC8 does not implement the __eeprom qualifiers for any PIC18 devices; this qualifier will work as expected for other 8-bit devices.
-----------------
『__eeprom qualifiersがPIC18では使えない！』
『それじゃ、どうすれば良いんだ？』
”pic18 eeprom”でWEB検索を掛けて、後閑さんの（このページ）を見つけました。
”PIC18Fシリーズの場合には、この開始アドレスが「0xF00000」
となっています。各PICデバイスごとの、Programming Specification
の中に記述があります”
と言うことなので、PIC18(L)F2X/4XK50のFlash Memory Programming Specification（これ）を拾ってきて、調べてみると・・・
-----------------
When embedding data EEPROM information in the hex file, it should start at
address F00000h.
-----------------
という事で、先のコードを次のように変更し、なんとかEEPROMを初期化することが出来ました。
＜動くコード＞
const UINT16 eeprom_ctmu_max[MTOUCH_SENSORS_NUMBER] @0xf00000 = { 6000, 6000, 6000, 6000, 6000, 6000, 6000, 6000};
const UINT16 eeprom_ctmu_min[MTOUCH_SENSORS_NUMBER] @0xf00010 = { 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000};
お試しでこんなコードを書いてみると、コンパイルは通りますがEEPROM上のデータは読めませんでした。
＜コンパイルは通るけど動かないコード＞
ctmu_log[0].max = eeprom_max_data[0];
ctmu_log[0].min = eeprom_min_data[0];
プログラムを走らせた後、EEPROMの値をデバッガで見ようとしたのですが、それも上手く出来ません。（<==やり方が悪い？）
どうも、PIC18のEEPROMは色々ややこしいようです。
CTMUチャネルごとに微妙に異なる計測値を正規化（値域を０～８０００に揃える）しようと考えました。
＜計算式＞
normalize_ratio = 8000 *（current - min）/ （max - min）
計測値の最大／最小をEEPROMに記録し、再起動時にそれを読み出すことにして、その初期値をEEPROMに書き込もうとしたのですが・・・
以下のコードで上手く行くものと思っていましたが、XC8コンパイラにeeprom qualifierを無視されてしまいました。orz
＜駄目なコード＞
__eeprom UINT16 eeprom_ctmu_max[MTOUCH_SENSORS_NUMBER] = { 6000, 6000, 6000, 6000, 6000, 6000, 6000, 6000};
__eeprom UINT16 eeprom_ctmu_min[MTOUCH_SENSORS_NUMBER] = { 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000};
＜XC8コンパイラのメッセージ＞
SRC/ctmu_main.c:80: warning: qualifier "eeprom" ignored
SRC/ctmu_main.c:81: warning: qualifier "eeprom" ignored
？？？
『XC8のマニュアルを読む限り、これで良さそうなのに何故？』と思ったら、後ろの方にこんな記述がありました。
-----------------
2.5.9.4 CAVEATS
XC8 does not implement the __eeprom qualifiers for any PIC18 devices; this qualifier will work as expected for other 8-bit devices.
-----------------
『__eeprom qualifiersがPIC18では使えない！』
『それじゃ、どうすれば良いんだ？』
”pic18 eeprom”でWEB検索を掛けて、後閑さんの（このページ）を見つけました。
”PIC18Fシリーズの場合には、この開始アドレスが「0xF00000」
となっています。各PICデバイスごとの、Programming Specification
の中に記述があります”
と言うことなので、PIC18(L)F2X/4XK50のFlash Memory Programming Specification（これ）を拾ってきて、調べてみると・・・
-----------------
When embedding data EEPROM information in the hex file, it should start at
address F00000h.
-----------------
という事で、先のコードを次のように変更し、なんとかEEPROMを初期化することが出来ました。
＜動くコード＞
const UINT16 eeprom_ctmu_max[MTOUCH_SENSORS_NUMBER] @0xf00000 = { 6000, 6000, 6000, 6000, 6000, 6000, 6000, 6000};
const UINT16 eeprom_ctmu_min[MTOUCH_SENSORS_NUMBER] @0xf00010 = { 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000};
お試しでこんなコードを書いてみると、コンパイルは通りますがEEPROM上のデータは読めませんでした。
＜コンパイルは通るけど動かないコード＞
ctmu_log[0].max = eeprom_max_data[0];
ctmu_log[0].min = eeprom_min_data[0];
プログラムを走らせた後、EEPROMの値をデバッガで見ようとしたのですが、それも上手く出来ません。（<==やり方が悪い？）
どうも、PIC18のEEPROMは色々ややこしいようです。
|
|
|
|
MPLAB-Xにこんな機能があることを知らなかった [MPLABXとXC8]
(2014.01.27)
MPLAB-Xを使い始めて１年以上経つのですが、デバッグにとても役立つ重要な機能の存在に初めて気付きました。
何気なく、ブレーク行の上にマウス・カーソルを置いてプログラムを眺めていたら・・・
構造体メンバーの値がポップ・アップ表示された
変数の上にマウス・カーソルを置いて少し待つ必だけで現在の変数値を表示してくれる、こんな機能があることを知らなかったのでびっくりしました。
MPLAB-XのUSER'S GUIDEを見ると、ちゃんと書いてありました。(^_^;)
マニュアルに書いてあった
グローバル変数だけでなく、ポインタ参照している構造体メンバーもちゃんと表示してくれる辺りは、なかなかの優れものです。
パチパチパチ～
もしかして、知っておくべき重要な機能が他にもあるかもしれません。MPLAB-XのUSER'S GUIDEを今一度（じっくり）眺めてみようかなぁ～
MPLAB-Xを使い始めて１年以上経つのですが、デバッグにとても役立つ重要な機能の存在に初めて気付きました。
何気なく、ブレーク行の上にマウス・カーソルを置いてプログラムを眺めていたら・・・
構造体メンバーの値がポップ・アップ表示された変数の上にマウス・カーソルを置いて少し待つ必だけで現在の変数値を表示してくれる、こんな機能があることを知らなかったのでびっくりしました。
MPLAB-XのUSER'S GUIDEを見ると、ちゃんと書いてありました。(^_^;)
マニュアルに書いてあったグローバル変数だけでなく、ポインタ参照している構造体メンバーもちゃんと表示してくれる辺りは、なかなかの優れものです。
パチパチパチ～
もしかして、知っておくべき重要な機能が他にもあるかもしれません。MPLAB-XのUSER'S GUIDEを今一度（じっくり）眺めてみようかなぁ～
|
|
|
|
"Broken Breakpoint"って何だ？ [MPLABXとXC8]
(2014.01.24)
MPLABXでタッチ・スイッチのプログラムをデバッグしていて、ブレーク・ポイントが上手く設定できない箇所があることに気付きました。設定は受け付けるのですが実際に走らせるとブレークが掛かりません。
設定操作は受け付ける
最初は自分のプログラムを疑いましたが、そうでは無いことが判りました。直前のif文ではブレークするのですが、STEP実行するとifブロックの下の（ブレーク・ポイントを設定した）行には行かず、別のcase文の中に入るのです。
白い帯に変わりBroken Breakpointと表示される
アセンブル・リストを見ると、こんなコードになっていました。
”Broken Breakpoint”というのは、ライン・ブレークに対応するアセンブラ行が見つからないときに発生するようです。それにしても不思議なコード展開です。Cプログラム通りにアセンブルしてくれれば良いんだけどなぁ～
Optimizeのチェックを外しても変わらない
この処理を止めさせる方法はあるんでしょうか？
MPLABXでタッチ・スイッチのプログラムをデバッグしていて、ブレーク・ポイントが上手く設定できない箇所があることに気付きました。設定は受け付けるのですが実際に走らせるとブレークが掛かりません。
設定操作は受け付ける最初は自分のプログラムを疑いましたが、そうでは無いことが判りました。直前のif文ではブレークするのですが、STEP実行するとifブロックの下の（ブレーク・ポイントを設定した）行には行かず、別のcase文の中に入るのです。
白い帯に変わりBroken Breakpointと表示される
＜Ｃプログラム（抜粋）＞
switch( sw->sw_state )
{
case OFF_STATE:
if( sw_condition == SW_ON )
{
sw->sw_state = T_ON_STATE;
sw->prev_sw_state = OFF_STATE;
}
sw->delay_count = 0; <== ここに来る(3)
break;
case ON_STATE:
if( sw_condition == SW_OFF ) <== ここでBraek (1)
{
sw->sw_state = T_OFF_STATE;
sw->prev_sw_state = ON_STATE;
}
sw->delay_count = 0; <== STEP実行するとここに来ないで (2)
break;
}
アセンブル・リストを見ると、こんなコードになっていました。
＜アセンブル・リスト（抜粋）＞ 2759 00121E l9245: <== ここに来る（４） 2762 ;sw_operation.c: 158: } 2763 ;sw_operation.c: 159: sw->delay_count = 0; 2764 00121E C1B6 FFD9 movff update_sw_common@sw,fsr2l 2765 001222 C1B7 FFDA movff update_sw_common@sw+1,fsr2h 2766 001226 0E00 movlw 0 2767 001228 6EDF movwf indf2,c 2769 ;sw_operation.c: 160: break; 2770 00122A D137 goto l9311 2780 001236 L9: <==ここを経由して（３） 2781 001236 6EDF movwf indf2,c 2782 001238 D7F2 goto l9245 3089 ;sw_operation.c: 248: if( sw_condition == 0 ) 3094 00141A 67B5 tstfsz update_sw_common@sw_condition& (0+255),b 3095 00141C D700 goto l9245 <== ifブロックに入らない時（１） 3098 ;sw_operation.c: 249: { 3099 ;sw_operation.c: 250: sw->sw_state = 1; 3111 ;sw_operation.c: 251: sw->prev_sw_state = 5; 3120 001446 0E05 movlw 5 3121 001448 D6F6 goto L9 <== ifブロックを抜ける時（２） 3122 00144A l9305:
”Broken Breakpoint”というのは、ライン・ブレークに対応するアセンブラ行が見つからないときに発生するようです。それにしても不思議なコード展開です。Cプログラム通りにアセンブルしてくれれば良いんだけどなぁ～
Optimizeのチェックを外しても変わらないこの処理を止めさせる方法はあるんでしょうか？
|
|
|
|
XC8 V1.20をインストールした [MPLABXとXC8]
(2013.08.05)
たまたまこちらのページを拝見して、Freeでも最適化機能（の一部）が使えることを知り、早速遅まきながらXC8 V1.20をインストールしてみました。
リリース・ノートによると、”ジャンプ to ジャンプの最適化”以外に”ハードウェア乗算命令の利用”などもコンパイラが面倒を見てくれるようです。
（パチパチパチ～）
Bluetooth_Interface基板のプログラムで試してみると・・・
ささやかではありますが、効果がはっきり現われています。
以前（V1.12）のこんなコードを見て、Cコンパイラの利用をためらった方も多いのではないでしょうか？
でも、もう大丈夫。これからはこんな感じです。
V1.20のコード
2472 0252 3A01 xorlw 1
2473 0253 1D03 skipz
2474 0254 2A75 goto l2947
これで”Cコンパイラ アレルギーの患者”が少しは減るかな？
たまたまこちらのページを拝見して、Freeでも最適化機能（の一部）が使えることを知り、
リリース・ノートによると、”ジャンプ to ジャンプの最適化”以外に”ハードウェア乗算命令の利用”などもコンパイラが面倒を見てくれるようです。
（パチパチパチ～）
Bluetooth_Interface基板のプログラムで試してみると・・・
### Memory Usage ### V1.12 V1.20 0h - 5h 0h - 5h 8h - 1015h 8h - F8Dh
ささやかではありますが、効果がはっきり現われています。
V1.12のコード 5361 0309 3A01 xorlw 01h&0ffh 5362 030A 1D03 skipz 5363 030B 2B0D goto u1891 5364 030C 2B0E goto u1890 5365 030D u1891: 5366 030D 2B37 goto l2901 5367 030E u1890:
以前（V1.12）のこんなコードを見て、Cコンパイラの利用をためらった方も多いのではないでしょうか？
でも、もう大丈夫。これからはこんな感じです。
V1.20のコード
2472 0252 3A01 xorlw 1
2473 0253 1D03 skipz
2474 0254 2A75 goto l2947
これで”Cコンパイラ アレルギーの患者”が少しは減るかな？
|
|
|
|
Addressブレークの新しい掛け方を習得した [MPLABXとXC8]
(2013.08.04)
ＰＩＣデバッガには、ブレークをプログラムの行に掛ける”lineブレーク”と特定（プログラム・メモリ）アドレスに掛ける”addressブレーク”があります。
”lineブレーク”の方はプログラム・ソースの行番号を左クリックして設定します。しかし、”addressブレーク”はDisassemble表示（Window->Debugging->Disassembly）の行番号を左クリックしても設定できません。
やむを得ず、Disassemble表示でアドレスを確認したあと、New Breakpoint（Debug->new Breakpoint->Address）で設定していました。
Break設定のメニュー
先日、デバッガの初期化コード内でプログラムが止まった件（こちらです）を調べたときに、暫くProgram Memory（Window->PIC Memory Views->Program Memory ）を眺めていました。そして、ふと思いついて左端のセルをクリックしてみると・・・
Program MemoryウィンドウでAddress Breakが設定できる
”ビンゴ～”
Addressブレークが設定されました。
Program Memoryウィンドウには、現在のプログラム・カウンタを中心にコードが表示されていて、”addressブレーク”を掛ける場所も簡単に探せます。
Program Memoryウィンドウで設定した”addressブレーク”はDisassemble表示にも表示され、その編集（別のaddressに変えるとか）と削除が出来るようになります。
Disassemble表示でも編集／削除は出来る
設定された”addressブレーク”の編集／削除は出来るのに、設定だけ出来ないというのは仕様としてアンバランスです。
Disassemble表示の行番号を左クリックしても”addressブレーク”が設定できないのは、MPLAB Xのバグじゃないでしょうか？
ＰＩＣデバッガには、ブレークをプログラムの行に掛ける”lineブレーク”と特定（プログラム・メモリ）アドレスに掛ける”addressブレーク”があります。
”lineブレーク”の方はプログラム・ソースの行番号を左クリックして設定します。しかし、”addressブレーク”はDisassemble表示（Window->Debugging->Disassembly）の行番号を左クリックしても設定できません。
やむを得ず、Disassemble表示でアドレスを確認したあと、New Breakpoint（Debug->new Breakpoint->Address）で設定していました。
Break設定のメニュー先日、デバッガの初期化コード内でプログラムが止まった件（こちらです）を調べたときに、暫くProgram Memory（Window->PIC Memory Views->Program Memory ）を眺めていました。そして、ふと思いついて左端のセルをクリックしてみると・・・
Program MemoryウィンドウでAddress Breakが設定できる”ビンゴ～”
Addressブレークが設定されました。
Program Memoryウィンドウには、現在のプログラム・カウンタを中心にコードが表示されていて、”addressブレーク”を掛ける場所も簡単に探せます。
Program Memoryウィンドウで設定した”addressブレーク”はDisassemble表示にも表示され、その編集（別のaddressに変えるとか）と削除が出来るようになります。
Disassemble表示でも編集／削除は出来る設定された”addressブレーク”の編集／削除は出来るのに、設定だけ出来ないというのは仕様としてアンバランスです。
Disassemble表示の行番号を左クリックしても”addressブレーク”が設定できないのは、MPLAB Xのバグじゃないでしょうか？
|
|
|
|
