User_Frameが良い感じに動き出した
先日、User_FrameからPICのメモリやレジスタに直接アクセスできるように仕様変更したのですが、良い感じに動き出しました。
（DAC_ADC用のUser Frame）
以下のコマンドを中段のText_Areaに書き込み、Sendボタンをクリックすると、結果が下段のText_Areaに表示されます。
get_var 変数名
set_var 変数名 書き込みデータ
get_reg レジスタ名
set_reg レジスタ名 書き込みデータ
TextAreaを介さずコマンド・バッファに直接コマンドを書き込めば、ユーザ・アプリケーションから簡単にPICを操作できます。
配列なども扱えるともっと使いやすくなりますが、Pic_coloコンソールで行う変数の表示／編集機能との使い分けが課題になりそうです。
Pic_coloの仕様を変更することにした
Pic_coloには自由にカスタマイズできるユーザ・フレームが用意されています。
ユーザ・フレーム表示のON/OFFは、Setting==>Other==>CustomWindowをクリックして切り替えます。
（背景が水色のウィンドウがデフォールトのユーザ・フレームです）
ユーザ・アプリケーションは、ユーザ・フレームとPICプログラム間でデータを送受することになるのですが・・・
このデータ送受を、Pic_coloコンソール（JAVAプログラム）とPic_coloデバッガ（PICプログラム）間で行うUART通信で、カプセル化して中継しようと考えて（<==未だ実装していなかった）いました。いよいよ、ユーザ・フレームとPICプログラム間のデータ送受を組み込もうとして、ユーザ・アプリケーションにとってデータ通信というのは手段にすぎないということに気付きました。
通信文字列を組み立て、それを解釈実行して、応答文字列を組み立て・・・
そんなことをやるよりも、データはPICのメモリやレジスタ上にあるのですから、それを直接読み書きする方がずっと簡単です。Pic_coloに組み込んであるPICの変数やレジスタをRead／Writeする機能をユーザ・フレームから呼び出せれば良いのです。
これは良いことを思いつきました。
新年、最初のヒットです！
XC8コンパイラは賢い
タイマー割り込みのインターバルをどこまで早く出来るか？が問題になって、割り込みハンドラの中を覗いてみました。
プログラム・コードはこんな感じ
void TMR1_ISR(void)
{
PIR1bits.TMR1IF = 0;
TMR1H = (timer1ReloadVal >> 8); <==これが
TMR1L = timer1ReloadVal;
}
1749 0020 movlb 0 ; select bank0
174A 1011 bcf 17,0 ;volatile
174B 0879 movf _timer1ReloadVal+1,w ;volatile <==こうなっている！
174C 0097 movwf 23 ;volatile
174D 0878 movf _timer1ReloadVal,w ;volatile
174E 0096 movwf 22 ;volatile
1759 0008 return
timer1ReloadValを右に８bit-shiftした値をTMR1Hレジスタに書き込む処理ですが、_timer1ReloadValの一つ先のアドレスを読み取って、23番地（<==多分TMR1H）に書き込んでいます。
こうしたいと思うことを先に（黙って）やってくれています。
なかなか、賢いコンパイラです。
自分自身の機能を変更する方法を考えてみた
Pic_coloはユーザ・プログラムを書き換えて実行することができます。ユーザ・プログラムをあれこれ書き換えて、動作を確認するのにとても重宝しています。
Pic_colo_1788本体を変更するときにPicKIT3を接続して書き換えるのが、段々面倒になってきました。（<==すぐに横着したがる奴）
ユーザ・プログラムの書き換えと、同じようにPic_colo_1788本体を自分自身で書き換えることは出来ないものでしょうか？
暫し黙考・・・・・・・・・・・・・・・・・
実行中のコードさえ書き換えなければ良い訳だから・・・・・
基本的な機能（割り込みetc.）と、コマンド処理機能に分割して・・・ん！
行けるんじゃない？
Pic_colo_1788本体を書き換える機能だけに絞ったコマンド処理モジュールを追加して、従来のコマンド処理モジュールと切り替えるようにすれば良さそうです。
『Pic_colo_1788自身の機能変更が出来る』っていうのも良いんじゃないでしょうか？
これは是非実現しなければなりません！
変数領域についても考慮が必要です。しかし、Pic_colo_1788本体が元々自動変数を使わないように書かれているので簡単に分割できる筈です。多分・・・
PWMの動作をどうやって確認するか？
PIc-colo単体で動作する以下のプログラムをサンプル提供しようと考えています。
Lチカプログラム
SW操作プログラム
PWMプログラム
DAC－ADCプログラム
プログラム動作を確認しようとして、大きな欠陥に気づきました。
LチカプログラムはPic-colo基板に搭載されたLEDが１秒間隔で点滅します。SW操作プログラムはLEDの点滅パターンがSW操作によって変化します。DAC－ADCプログラムは３ｃｈのDAC出力をAD変換した結果を画面に表示します。何れもプログラム動作の確認はPic-colo単体で出来そうです。
問題はPWMプログラムで、PWMの出力をPic-colo単体でどうやって確認すれば良いのでしょうか？
PWM出力をLEDに接続してPWMの設定値を変えても、LEDの明るさは殆ど変化しません。出力ポートの電圧をテスターで計っても、計測分解能が不足してPWMの評価には使えません。orz
オシロ（またはロジアナ）が使えれば簡単なのですが・・・
オシロジで計測した
Pic-colo単体でPWMのdutyを確認する方法は・・・・・・・・・・・・・・・ ん！
PWMの出力ポートのHi-Lowをメインループでモニタして、そのdutyを計算して求めるっていうのは？
早速試してみました。
１秒インターバルでモニタしたduty値は僅かにオフセットしますが、PWM設定値の１LSBの変化をしっかり捉えています。
パチパチパチ～
大雑把な変化をLEDで確認（明るいとか暗いとか）して、PWM設定値の細かい変化は計算で求めたduty値で確認してもらうのが良さそうです。
これにて一件落着～
CCP3の出力pinの設定で戸惑った
便利に使っているMPLAB® Code Configurator (MCC) ですが、時々『あれ？』と戸惑うことがあります。
Pic-coloのPWM機能のサンプル・プログラムを書いていたときのことです。CCP3のデフォールト出力（RC6）がUARTのTXピンと重なっていたので、RB5に割り当てようとしたのですが・・・
Pin Managerが管理するModuleにCCPが有りません。orz
CCP3をRB5に割り当てるためにはAFPCON2は0x01で初期化しなければならないのですが、MCCが生成したプログラムはAFPCONレジスタを0x00で初期化しています。orz
MCCが生成したプログラムを書き換えることは簡単ですが、果たしてそれは正しい手順なのでしょうか？一体どうすれば良いのか？
・・・・・・
ふと思いついて、Registersタブをクリックして設定リストを調べてみると・・・
ビンゴ～
AFPCON1、AFPCON2の設定メニューを見つけることが出来ました。
やれやれ
Pic-colo試作基板が動いた
５枚のPic-colo試作基板を組み立てたのは１０日以上前です。
基本モデルを２枚、WiFiモデルを２枚、LCDシールドモデルを１枚、計５枚を組み立てました。
早速動かしてみたのですが、Pic-coloコンソールとPic-coloデバッガ間の通信が動いたり動かなかったり・・・
FT231XSの半田付けの手直しを繰り返しながら暫くジタバタした挙げ句、基本に立ち返ってLOOPBACKテストの実施を決めました。
USBシリアル変換IC（FT231XS）単独のLOOPBACKテストで、これまで重宝していたJAVAのCOMMライブラリ（<==自作）にバグが見つかりました。結局、試作基板（5枚）がLOOPBACKテストに通るまで二日掛かりました。
しかし、相変わらずPic-coloコンソールとPic-coloデバッガ間の通信が動いたり動かなかったり・・・orz
USBシリアル変換ICとPICを合わせたLOOPBACKテストに試作基板が全て通るまで、さらに三日掛かりました。
まさかUSBシリアルのLOOPBACKテストにこれ程時間が掛かるとは思いませんでしたが、ようやくPic-coloの開発を先に進めることが出来るようになりました。
やれやれ。
