denshikobo’s blog

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

break_conditionとbreak_statusの操作は混乱気味

PIC側に設定されているbreak_conditionとbreak_statusをホスト側で読み取り、break_statusをクリアして書き戻したり、break_conditionに”THRU”または”BREAK”を設定して書き戻したりする操作を組み込もうとしています。

 

break_conditionとbreak_statusを反復して読み取り、それをホストのウィンドウに表示する機能は動きました。読み取ったbreak_conditionやbreak_statusをTextFieldに設定して、クリアしたり”THRU”または”BREAK”を設定する機能も動いています。試してはいませんが、Sendボタンの操作でPIC側に書き戻す操作も(多分)動く筈です。

 

TextFieldの編集中はPIC側からの読み取りを停止して、Sendボタンの操作で読み取りを再開しようと考えていたのですが・・・

 

Sendボタンを操作しないで別の操作に移ると、ホスト側の表示が混乱してしまいます。

 

問題点

(1)操作中を表すハイライト表示が複数個所に出てしまう。

(2)書き換えていないのに編集中の値が画面に表示されてしまう。

 

フラグを追加して状況を改善しようとしたのですが、フラグ操作が混乱しています。orz

 

ここは、一旦引き下がって取り組みの見直しが必要です。

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

目指す姿は・・・

(1)ホストのウィンドウにPIC側の現在値が表示される

(2)選択項目がハイライト表示され、現在値がTextFieldに読み取られる

(3)TextFieldを編集したり、ボタン操作でクリア(または設定)する

(4)TextFieldの値をSendボタン操作でPIC側に書き戻す

(5)書き戻した値(現在値)が読み取られてホストの表示が更新される

 

多分、PIC側から読み取った値を格納する場所と編集中の値を格納する場所が両方とも同じ配列であることが混乱の原因で、それを分ければ問題は解決するのではないか?と考えています。

 

あと、もう少し・・・(多分)

 

 

秋月電子からPIC32を実装した基板が売り出された

秋月電子からPIC32を実装した変換基板二種(PIC32MX370F512HとPIC32MZ2048EFH144)が売り出されました。

akizukidenshi.com

akizukidenshi.com

PIC32MX370はMCCが使えるので気軽に開発を始められるものと思いますが、PIC32MZはHARMONYで開発することになるので、腹を決めて取り掛からなければなりません。<==英文のマニュアル2000~3000ページを斜め読みすることになります(^_^;)

(Ver1.0では8300ページあったHelp ファイルが、Ver2.0では分割されて少しスリムになったような・・・)

 

Microchip Directに注文しても1個6ドルするPIC32MX370F512Hが変換基板に実装されて¥700というのは破格の値段です。

 

PIC32が電子工作のデバイスとして、広く利用されるようになると良いなぁ~
(<==参考になる邦文の情報が増えることを期待している)

function_listにcinitを追加した

mapファイルを解析してcinitのアドレスを取得するのは簡単でした。それをfunction_listの末尾に表示させるところで、手間取ってしまいました。

f:id:denshikobo:20170815122115p:plain

function_listはelf(dwarf)ファイルの解析結果をリスト形式で記録しています。そこにcinitのアドレスを追加すれば良いと考えたのですが・・・

 

デバッガで確認するとcinitの情報はfunction_listに追加されているのですが、画面には表示されません。orz

 

調べてみると、elfファイルを解析した直後に関数リストをファイルに書き出していて、それを読み出して表示していました。cinitの情報を追加したのがファイルに書き出した後だったので、cinitが表示されなかったのです。

 

やれやれ

(ボチボチ、ボチボチ。開発を進めて行きます)

次はBreak StatusとBreak Conditionを扱います。

cinitのことを忘れていた

PICのProgram Memoryを眺めていて、リセットからMain関数が呼び出される前に、何か処理していることに気が付きました。

リスト・ファイルを調べて見ると・・・Cプログラムの初期化処理(cinit)です!

 

ユーザ・プログラムの起動は、単純にmain関数を呼び出せば良いと考えていました。しかし、それでは初期化変数に値が設定されません。ユーザ・プログラムの起動は、main関数ではなくcinitを呼び出さなくてはならなかったのです。orz

 

関数リストにはcinit(<==Cプログラムではない)は含まれていません。mapファイルに記されているのでcinitの先頭アドレスを得ることは出来そうです。

 

こりゃ、まだまだ抜けが有りそうだ。

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

xc32の方はどうなっているのか気になりますが、先ずはxc8を仕上げることに専念します。

 

PIC側の機能はほぼ揃った

Break ConditionがTHROUGHならBreak StatusはTHROUGH(またはNULL)、Break ConditionがBREAKならBreak StatusをBREAKにしてBreak_Loopを呼び出す。RESTARTコマンドでBreak_Loopを抜けて、元の関数に戻る。これがBreakの動作仕様です。

 

Break ConditionにTHROUGHやBREAKを設定するのはMEMORY_WRITEコマンドで、Break StatusがNULLなのかTHROUGHなのかBREAKなのか調べるのはMEMORY_READコマンドで行います。ホスト側の操作をPICkit3で代行して、仕様の確認を済ませました。

 

Break_Loopの実行制御はBREAKコマンドとRESTARTコマンドでテスト済みです。

どうやらPIC側の機能はほぼ揃いました。

 

残っているのは、PICから読み出したVarやRegの値を編集して、PICに書き戻す処理です。PIC側はMEMORY_READとMEMORY_WRITEの動作なので、ホスト側で行うデータ操作が課題になります。

 

また、ゴリゴリ、ゴリゴリ、プログラムを書いていきます。

 

PICkit3の夏バテ対策を見つけた

現在の気温は27度。久しぶりに涼しい朝を迎えています。お陰様でPICkit3も好調です。

 

気温が30度を越すとPICkit3の調子がおかしくなる(<==夏バテと呼んでる)のですが、最近頻発するのが”A tool request has been waiting for・・・”というエラーです。

デバッグの最中にPICkit3の不具合で作業を中断するのは、(『精神の鍛練を心掛ける』とは言え)やっぱり効率が悪く、なかなかデバッグが進みません(<==言い訳)。

 

調べてみると、これはMPLABXのバグらしく、Versionを3.55に戻すと良くなるのだそうです。MPLABXのArchive(ここ↓)から3.55を持ってきて早速試してみました。

Downloads Archive | Microchip Technology Inc. | Microchip Technology Inc.

 

昨日の午後から3.55に替えたのですが、”A tool request has been waiting for・・・”というエラーは出なくなりました。

 (パチパチパチ~ )

 

先達の知恵、おそるべし!(同様に、このblogの情報が少しでも皆さんのお役に立つことを願います。)

 

デバッグ作業がようやく進みだしました。

RUNコマンドを送ると、指定した関数が走り出す・・・よし

BREAKコマンドを送ると、指定した関数を抜けてBreak_Loopが走り出す・・・よし

RESTARTコマンドを送ると、再び指定した関数が走り出す・・・よし

STOPコマンドを送ると、Main_Loopに戻る・・・よし

 

実は、関数の実行に問題が見つかって、BREAKコマンドを送っていないのにBreak_Loopが走ったり、STOPコマンドを送っていないのにMain_Loopに戻ってしまったり・・・その不具合のデバッグをしていました。原因は、『割り込み発生時に行われるレジスタ退避』に関して私の理解が不足していたことです。

以下マニュアルの抜粋

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

4.5 内容保存機能

割り込み動作に遷移する際、復帰時の PC アドレス値がスタックに保存されます。また、次に示すレジスタ値も自動的にシャドウ レジスタに保存されます。
• W レジスタ
• ステータス レジスタ (TO および PD を除く)
• BSR レジスタ
FSR レジスタ
• PCLATH レジスタ
割り込みサービス ルーチンから通常動作に戻るとき、自動的にこれらのレジスタ値が回復されます。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー

割り込みから戻るときに、comm_main関数を呼び出したため、 ユーザ・プログラムへ戻ったときに上記レジスタの値が変化していました。ユーザ・プログラムの実行中もコマンド操作を可能にするための処置だったのですが・・・

 

少し不便ですが、ループ処理を伴うユーザ・プログラムは『ループ処理に所定の関数呼び出し(break関数)を加える』という条件を付けて、この問題の解決を図ることにしました。(<==ちょっと残念!)

 

次は、ユーザ・プログラムにBREAKポイントを設定してみます。

 

PICkit3が夏バテした

昨日(8/9)は関東地方も38度を超える猛暑日でした。

エアコンの無い(扇風機だけ  ^_^; )部屋で開発しているので、室温もぐんぐん上がっていきます。

 

昨年も経験しているのですが、猛暑日になるとPICkit3がおかしくなります。昨日も3時過ぎに変なメッセージ(debug toolから1秒以上返事がないとかなんとか)が出て、デバッグできなくなってしまいました。orz

肝心かなめの関数呼び出しが上手く行かなくてカリカリしていた時だったので、当方の不快指数も一気に上昇して・・・

 

USBケーブルを引き抜きました。(<==怒りに任せてではありません)

PICkit3への通電を止めて、しばらく休憩です。

夕方まで待って再挑戦したのですが、直ぐにデバッグできなくなったので諦めました。

 

今朝は気温も低く(<==29度  ^_^;)、PICkit3も快調です。

ring_bufferを使ったデバッグ・ログでプログラムの動作を追いかけてみると・・・

 

80    01    8A    10    01    11    12    13    14    21    15    18    19    16    17    1A

01    8B    20    01    8A    10    01    11    12    01    8C    21   

御覧の皆様には意味不明のログ出力だと分かっていますが、開発の大きなステップをクリアした記録なので、うれしくてつい貼ってしまいました。

 

RUNコマンドを受け取って(8A)、コマンド処理を始めて(10~13)、スタックを保存して(14~19)、呼ばれた関数が走って(16~17)、ブレークして(8B)、再スタート(8A)して、ストップ(8C)した様子が、記されています。

(パチパチパチ~)

 

PICkit3を冷やしている間、当方も頭を冷やしていて思いつきました。

『そうか、スタック操作中は割り込み禁止にしないといけないんだ!』

 

昨日動かなかった原因は、スタック操作中の割り込みだったのではないか?と考えています。

 

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

見つけた不具合をデバッグしている最中に今日も出てしまいました。

これが出ると、作業できません。

 

”Programming/Verify complete

Running

A tool request has been waiting for more than a second. The debug tool will try to service the request within another second. After that the request will be rejected.

A tool request has been rejected because it could not be serviced within the two second timeout period.

 

う~む、昨日より早く出るようになった。やっぱり夏バテだな。orz

 

今年の夏は『精神の鍛練』に努めます。