● 実験テーマ120
「8x8マトリックスLEDモジュール：M7SEGX1R-7219B
"aitendo"の実験」
（7SEGコントローラ：MAX7219＋8x8マトリックスLED＋PIC18F14K50による実験です。）
※ 200130
→ 1回目の更新です。
追試として、2個カスケード接続したLEDモジュールに、より多くの文字をスクロールさせる実験をしてみました。
※ 2020年1月15日からの記事を参照してください。
※ 200210
→ 2回目の更新です。
以下、2つの、Step（Step5, Step6）の追試を行いました。
Step5： フォント・テーブルの、ASCIIコード指定で、2文字の文字列を表示する。
Step6： フォントテーブルのデータ（ASCIIコード）を元に、表示用のデータを生成し、それを循環スクロールさせる。
※ 2020年1月31日からの記事を参照してください。
■ 2019.12.28
・今回は、光物をやってみようと思います。
前から、町で見かけるマトリックスLEDモジュールを使った「電子掲示板」には興味がありました。
また、マトリックスLEDモジュールのコントローラ：MAX7219についても、大昔（約13年前）に使った経験があります。
その時は、トラ技2007年8月号に掲載の、
「特集*PICで体験するマイコンの世界- 第6章：I/O機能を使った表示モジュールの製作」著者=山口晶大（あきお）さん
の記事の中に、「7セグメント6桁LED表示モジュールの製作」という記事があり、そこでMAX7219の存在を初めて
知りました。
当時は、トラ技付録のトレーニング基板を改造した「dsPIC30F4013トレーニング基板」を使っていたので、
16x2行キャラクタ液晶：SC1602BBWBの、コネクタの所に直接接続できるガシェットとして、この製作記事の
7セグメント6桁LED表示モジュールを作って実験してました。
このモジュールのハードチェック・プログラムとして「7セグ自己診断プログラム」を作成して動作確認していました。
確か、ノーデコードモードで、6桁の7segと、個別led3個をスキャンしてたと思います。
動作中の写真を以下に示しました。
■ 2019.12.29～ 2019.12.30
・本題の、8x8マトリックスLEDモジュールですが、上記のトラ技の記事の中にも使用例がありましたが、
モジュール（MAX7219除くLED単体の型番）の型番が明記されてなかったこともあり当時は実験しませんでした。
今では、aitendoで、M7SEGX1R-7219Bの型番で販売されています。（但し'20/1/11現在、残り在庫11個で終了予定品）
よくよくweb検索すると、本家は、「PICAXE」というメーカーの、「FC-16
BOARD」というボードのようです。
ここに基板へのLEDモジュールの実装写真が大きく載っていたので、正しい実装向きの確認が出来ました。
これによると、LEDモジュール：1088Aの型番が印刷されている面（中央に凸部がある）を下側にして、
下側の左サイドが①ピンになり反時計回りに、⑧～上側に移り、➈～⑯と数えれば良いようです。（ICのピン番と同じ数え方）
・まずは、1個のみの実験なので、DIN側のコネクタランドに、付属の、5pinライトアングル・ピンヘッダを、LEDモジュール：1088AS
取付け用ランドに、5pinソケットコネクタを、実装しました。
以下に、aitendoのモジュールに、コネクタを実装した時の様子を示しました。
ボード上に、「FC-16」のシルクが確認出来ます。
・最初は、8x8用のフォント・データを作成するところからスタートです。
ASCIIコード指定で、0x20～0xDFまでの、192文字分作成しました。（const char Font8x8[192][8]）
その一例です。
既存の、7x5dotフォントを流用するのも一つの案だが、そのままでは使えない。
フォント（ドット）データの取り方が、縦割りになっているので、横割りに変換する必要があります。
このアルゴリズムを考えた人がおられるが、（「趣味を楽しむ
Enjoy your bobby」：Vividさん）
せっかく8x8ドットあるので、少し幅広のフォントにしようと思います。
作成に際しては、ここのサイト：「北摂ものずくり研究所」さんのフォントを参考にしました。
・フォント・テーブルの全ての文字を順次表示するテストプロを作成し、チェック開始です。
まずは駄目。（VCC= 5.06V）
全点灯するだけでNG。
もしかしたら、テストモードになってしまっている？
MAX7219の初期設定手順に問題があったようだ。
最初に、ノーマルオペレーションにする必要があるようだ。
続けて各レジスタの設定を行い、最後に、シャットダウンモードを解除で良いようだ。
この手順に修正したら動き出した。
・ここで動作中の、桁信号（DEG0～DEG7）のタイミングとレベルを、確認してみた。
綺麗にスキャンしている。
スキャン周期は、1.5mSで、パルス幅（シンク幅）は、0.2mSといったところ。
・SPIラインのタイミングと、CLK周波数も確認してみた。
よさそうである。
■ 2019.12.31
・STEP2として、1個でのスクロール実験を試してみる。
トラ技に載っていた、"CQ"の文字を左から右へスクロールするはずのを試してみた。
ソースは、トラ技そのままでやってみた。
結果は、正規のLEDモジュールの実装向き（型番印字側を下）にして試すと、表示方向（スクロール方向も）が変。
時計回りに90度回転して、さらに180度反転しないと向きが合わない？
スクロール方向が下から上になってしまう。
・トラ技の記事を熟読すると、幾つかの点に気付いた。
まず、フォントデータの取り方が異なる。
"CQ"文字が下向きの状態で、横割りにデータ取得している。
正規の方向（時計回りに90度回転）にすると、縦割りデータになる。
それと、COL側と、MAX7219の、SEG_DP～DEG_Gの接続が真逆になってる。
この2点の違いが原因のようだ。
多分LEDモジュールの実装向きを回転させているものと思われる。
（また、LEDモジュールの信号名と、ピン番の対応が、1088ASと違うが内部接続は同じようなので、
これは、型名不明だが互換品のようである。）
正規の方向（時計回りに90度回転）にすると、縦割りデータになるおかげで、シフト・ローテ―トが
効率良い記述で済んでいるようである。
上手に、除算を使っている。（%16）
以下に、トラ技掲載ソースの主要部分を示す。（適当に私のコメントが追加されています。）
unsigned char cq[16]={0x60, 0x90, 0x90, 0x00, 0x0C, 0x12, 0x13, 0x0D,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
void main(void) {
unsigned i, k;
init_led_port(); // initialize I/O port (RB6, RB7, RB8)
send7219(0x0f, 0x00); // set display test reg - normal operation
for (i=1; i<=8; i=i+1) {
send7219(i, 0); // clear data reg
}
send7219(0x09, 0x00); // set decode moode reg - no decode
send7219(0x0a, 0x0f); // set intensity reg - maximum brightness
send7219(0x0b, 0x07); // set scan limit reg - no limit
send7219(0x0c, 0x01); // seet shutdown reg - normal operation
k=0;
while(1) { // forever loop
for (i=0; i<8; i=i+1) send7219(i+1, cq[(k+i)%16]); // ① ※ [*]の、*が8回のシフト毎に上に循環シフトする。
// ledモジュールをボード上に置く時、90度右に回転して
// 実装しているため左シフトに見えると思われる。
// （正規の配線でなく、 colラインのセグデータビット
// に対する並びが真逆になっている）
k=(k+1)%16; // ② ※ k=0～14の時、(k+1)%16の結果は、0～15
// k=15の時、(k+1)%16の結果は、0になり、0～15を永遠に繰り返す。
for (i=0; i<20; i=i+1) wait(60000);
}
■ 2020.1.1～ 2020.1.5
・自分なりに考え直すことにした。
最初は、全面ブランク表示からスタートして、右側からドット表示が見えだし、左へ向かってシフト・ローテ―ト
し循環表示する動作仕様に決める。
ScrollBuff[8]という、16bitのRAMバッファを用意して、表示面（8bit）＋スクロール待機面（8bit）として
スクロール描画し、これの表示面8bitのみを、DispBuff[8]にコピーして、これをMAX7219に送り、LEDモジュールに
表示することにした。
つまり最初の部分の表示はこんなイメージ。
・ローテ―ト部分の記述に悩んだが、何とか動いた。
VIDEOを撮ったので御覧ください。→ video001.mp4
■ 2020.1.7～ 2020.1.8
・STEP3として、8x8LED 2個カスケード接続の、スクロール実験をしてみる。
表示文字は、相変わらず、"CQ"とする。（但しフルフォント）
STEP2と同じ考え方でやってみる。
今回は、ScrollBuff[8]という、32bitのRAMバッファを用意して、表示面（16bit）＋スクロール待機面（16bit）として
スクロール描画し、これの表示面16bitのみを、DispBuff[8]にコピーして、これをMAX7219に送り、LEDモジュールに
表示する。
つまり最初の部分の表示はこんなイメージ。
・もう一つのLEDモジュールを、ジャンパーピンを介して、カスケード接続し、これをアクリル台にセットした。
・チェック開始
VCC= 5.07V
何も表示せず。
LEDモジュール単体チェックでは、両方共OKである。
根本的に、カスケード接続した場合の、個々のMAX7219の設定（データの送り込み）の考えが間違っているようだ。
頭の中を整理してみた。
ハード的にシフトレジスタによるクロックに同期して、入力データをシフトしながら送り込む方式なので、
※1．2個の場合、16発x2=32発のクロックが必要となる。
※2．そして、LOADパルスは、32発後に立上げる必要がある。
このタイミングで、各LEDモジュール（上位桁＋下位桁）にデータ（アドレス含め16bit）が書込まれることになる。
※3．MAX7912の初期設定時には、同じパラメータを各桁のデバイスに書込む。
※4．表示させるときは、各桁に任意のデータを書込む。但しアドレスは共通でよい。
こう考えれば良さそう。
・ソースを修正して試すも、上位桁しか表示しない。下位桁はブランクか全点灯。
調べ易いように、MAX7912初期設定後、上位桁：オール0x80、下位桁：オール0x40のパターンを送って
症状を再確認したところ、上位桁はOKで、下位桁はブランクでNGだった。
念のため、SPIラインのタイミングを自作ロジアナで確認してみた。
データが正しいかは（自作なものでトリガが甘く）よくは確認出来なかったが、LOAD・CLKのタイミングは
プログラム通りで問題なさそうである。
■ 2020.1.9
・上位桁のLEDモジュールはOKで、下位桁がNGの原因が判明した。
MAX7219送信関数内での引数adrsの挙動に問題があった。
最初上位桁からアクセスするが、この時は問題なし。
桁変数での、FORループの次の実行の時、前回の、adrs変数のmsbからのレベルチェックうするために、
adrs= adrs << 1;と左シフトしてadrsに再格納。これを7回繰返すので、繰返しの時、adrsが変ってしまっていた。
なので、1回目のシフトの前に引数をテンポラリに退避しておいて、2回目の繰返しの頭で、テンポラリを
引数に渡し、それをシフトすることで解決した。
これで一応動作okになった。
VIDEOを撮ったので御覧ください。→ video002.mp4
・追試として、もっと多くの文字をスクロールする実験をこのハードでやってみる予定です。
バッファの考え方を変えないと駄目そうです。
-----＜ ここから追試：Step4の記事 ＞------------------------------------------------------------------------------
■ 2020.1.15
・追試として、2個カスケード接続したLEDモジュールに、より多くの文字をスクロールさせる実験をしてみました。
バッファの考え方等は、後閑さんhpの、PIC24Fによる「電光掲示板」の記事とソースを参考にしました。
2次元配列を使います。
後閑さんの記事では、コントローラが、MAX7912ではなく、秋月で販売されていた
ハード（32x16マトリックスで表示行指定信号が3本追加されている。）を使われていますが、基本の考え方は
一緒なのでなんとかなりそうです。
まずは、ソースの構想を練りました。
最初に行うことは、固定表示用バッファに格納するフォントデータ作成です。
"Nobosan's Electronic WorkShop "の文字列を循環スクロール表示することにしました。
■ 2020.1.16
・一応ソースを書き上げて、hexまで用意出来た。
早速、hexを書込み動作確認開始。
まずは駄目。
＜NG点＞
① 一応スクロールするが、" W"の桁の時に、Wの右端の縦方向のドットがクリアされて表示されない。
→ 最上位桁のキャリー判定の記述のところが、最上位桁のキャリーを最下位桁へ移すところ、
最上位桁に移していた。
これを直しても駄目だった。
② 1周目は、大方OKだが、2周目から文字がバラケルように目茶目茶になる。
→ はっきり原因解らずだが、1周目の後に、表示バッファの初期化（ROMからのコピー）をしてみたが、
これでも駄目。
・何とか問題解決した。
一番の原因は、l（エル変数：桁）の型宣言に問題あり。
forループを抜ける条件を、ディクリメントして行ってマイナス（-1）になったらとしてたので、char
l;
としていたが、どうもこのせいで、コンパイル時に気になるワーニングが、当該行の記述に発生していたようだ。（スルーしてたのが、いけないね・・）
l は、14maxなのでレンジ的には、符号付のchar（-128～+127）で良さそうなのだが？
Web検索して、XC8の場合の、変数型の様式を調べてみた。
※ XC8コンパイラだけ、修飾子無しのcharと書くと、unsignedとして扱われるようである。（初めて知った）
（尚、XC16は、singedとして扱ってくれる。）
つまり、XC8で符号付8bit整数と宣言するには明示的に、signed
charと書く必要がある。
■ 2020.1.17
・昨日の修正をしたら、未だ、「① "
W"の桁の時に、Wの右端の縦方向のドットがクリアされて表示されない。」
は直ってないが、「② 1周目は、大方OKだが、2周目から文字がバラケルように目茶目茶になる。」は直り、大方の
動作が良くなった。
また、スクロールスピードも指定よりかなり遅くなっていたが、指定通リに直った。（今回は速めに、0.1秒に設定した。）
たった一つのミスが、こんなにも影響があるとは思わなかった。
・残るは、「① "
W"の桁の時に、Wの右端の縦方向のドットがクリアされて表示されない。」問題だが、
"W"のフォントだけ、b0を空けてなく（b6-b0が文字幅）これが原因していると仮定してソースを見直したら、
どうもそのようだった。
LSBは空にしておかないと、スクロールした時、下位桁のMSBが、'0'なっている時にここがクリアされてしまうので、
'W'フォント（スクロール用）は、右に1bit移動して、b7-b1を使ってフォントを修正（boはオール0）することにした。
・これでようやく全ての動作がOKと思いきや、スクロール状況を注意深く見ると、あることに気付く。
文字と文字の間隔が、固定データより、1dot狭くなっている個所が少なくとも、1ヶ所（"W
o"の所）ある。
この後、他に同様の現象のところが無いかを確認したところ、下位桁と上位桁の境でみな起きていることを確認した。
未だ駄目じゃん。
■ 2020.1.18～ 2020.1.20
・追い易いように、最初の、2桁（"N o b o"）だけにして調査した。
現ソースのメインループを、以に示した。
/// MAIN LOOP：解析し易いように、2桁で考える 00118
#define MaxWord 2
while(1) {
///////// シフト＋ローテ―ト
for (l= MaxWord-1; l>=0; l--) { // 下位桁（Buff[1][8]]から左へシフト
for(m= 0; m<8; m++) { // 8行分（フォントの横8行）繰り返し
Carry= Buff[l][m] & 0x8000; // 最上位ビットをCarryへ保存
Buff[l][m]= Buff[l][m] << 1; // 下位桁のビットから左へシフト
///// 以降ローテ―ト操作
if(l != 0) { //// 最上位桁でない場合（Buff[1][*]）
/// 下位桁のキャリーを上位桁へ移動
if (Carry == 0) Buff[l-1][m] &= 0xFFFE; // キャリーが立っていなかったら上位桁の最下位ビットクリア
else Buff[l-1][m] |= 1; // キャリーが立っていたら上位桁の最下位ビットセット
}
else { /// 最上位桁の場合（Buff[0][*]）
// 最上位桁のキャリーを最下位桁の最下位ビットへ移す
if (Carry == 0)Buff[MaxWord-1][m] &= 0xFFFE;// キャリーが立っていなかったら最下位桁の最下位ビットクリア
else Buff[MaxWord-1][m] |= 1; // キャリーが立っていたら最下位桁の最下位ビットセット
}
}
}
//// 表示面にデータ転送し表示（最上位桁）
for(m= 0; m<8; m++) Send_x2_MAX7219(m+1, (unsigned char)(Buff[0][m] >> 8),(unsigned char)(Buff[0][m] & 0x00FF));
delay_ms(500); // スクロール速度調整：200116
} /// 最初に戻って繰り返す
・結果は、以下のように"N o b o"の、oとbの間の文字間隔が、1dot狭くなる。
・次のように修正すれば良さそう。
① lループ1回目（l= 1：下位桁）の左シフト結果の、上位桁LSBへのキャリー・セット
or クリアは、1回目には
行わない。
② lループ2回目（l= 2：上位桁）の左シフト後に、①のキャリー判定の結果を、上位桁LSBにキャリー・セット
or クリア
する。
（①で先に行ってしまうと時系列が狂って、既にシフトしたのを、さらにシフトするので、1つズレが発生）
これで、2桁版は、OKになった。
■ 2020.1.21
・2桁でのスクロールは、OKになったが、通常の15桁に戻したら、2周目から、おかしくなる。（ブランクになる。）
どうも、MaxWord
2の時は、
l=
0→ 上位桁（最上位桁になる）
l=
1→ 下位桁（最下位桁になる）
ので、キャリーセットの条件は、上位桁のキャリーが立っている場合は、
左シフトしてから Buff[MaxWord-1][m]
|= 1; とすれば良いし、
下位桁のキャリーが立っている場合は、
左シフトしてから Buff[ｌ][m]
|= 1; とすれば良かったが、
MaxWord 15の時は、
最下位桁：MaxWord-1の、[14]から左シフトして行くことになり、キャリーが立っている場合の、
上位桁の対象が、その都度違ってくる。
Buff[l-1]にしないといけない。以下に、現象が起きていた時のソースを示した。
そのように修正したら、2周目から、ブランクになる現象は起きなくなったが、最初の最上位桁と次の下位桁の
境の文字間隔を除いては、1dotズレる現象は変わらなかった。
/// 通常の15桁に戻したら、2周目から、おかしくなった時の、MAIN LOOP
/// この時から、下位桁のキャリーが立っていない場合の、上位桁lsbのクリアはしても変わりないにでは
/// と思い省略していた。（しかし後で、必要なことが判明）
while(1) {
///////// シフト＋ローテート
for (l= MaxWord-1; l>=0; l--) { // 下位桁（Buff[1][8]]から左へシフト
for (m= 0; m<8; m++) { // 8行分（フォントの横8行）繰り返し
if (l != 0) { /// 最上位桁でない場合（Buff[MaxWord-1][*]）
CarryL[m]= Buff[l][m] & 0x8000;
Buff[l][m]= Buff[l][m] << 1; // ビットを左へシフト
}
else { /// 最上位桁の場合（Buff[0][*]）
CarryH= Buff[l][m] & 0x8000; // 最上位ビットをCarryHへ保存
Buff[l][m]= Buff[l][m] << 1; // ビットを左へシフト
if (CarryL[m] != 0) Buff[l][m] |= 1; // 下位桁のキャリーが立っていたら上位桁の最下位ビットセット
if (CarryH != 0) Buff[MaxWord-1][m] |= 1; // 上位桁のキャリーが立っていたら最下位桁の最下位ビットセット
}
}
}
//// 表示面にデータ転送し表示（最上位桁）
for (m= 0; m<8; m++) {
Send_x2_MAX7219(m+1, (unsigned char)(Buff[0][m] >> 8),(unsigned char)(Buff[0][m] & 0x00FF));
}
}
■ 2020.1.24
・Excelシート上でも追求していたが、桁が多いと途中のシフト状況が把握し難いので、
実機に於いて、さらに4桁で実験してみた。
・下図のように、ベースになる、固定データ・テーブルを、追い易いように、4桁で考えてみる。
・現状の症状を整理。
各ペア（上・下）桁の境（例えば、'o'と's'の間とか、'a'と'nの間）の、文字間隔が、シフトして行くと、
ベースのデータ・テーブルに比べ スペースが1ドット分、少なくなるということ。
それ以外は、OK
この時のソースの一部を下に示しました。
ちょっと変えて、Carry変数を、2つ（上下桁で分けた）用意してます。
これでも動いたが、ズレは変わらず。
int CarryL[8];
int CarryH;
/// MAIN LOOP
while (1) {
///// 200123
for (l= MaxWord-1; l>=0; l--) { // 下位桁（Buff[3][*]]から左へシフト
for (m= 0; m<8; m++) { // 8行分（フォントの横8行）繰り返し
if (l != 0) { /// 最上位桁でない場合（Buff[1～3][*]）
CarryL[m]= Buff[l][m] & 0x8000; // 最上位ビットをCarryへ保存
Buff[l][m]= Buff[l][m] << 1; // ビットを左へシフト
/// 下位桁（[2]～[3]で、[1]は除く）のキャリーが立っていたら
if ((l != 1) && (CarryL[m] != 0)) {
Buff[l-1][m]= Buff[l-1][m] << 1; // まず上位桁を先に左シフトしてから
Buff[l-1][m] |= 1; // 上位桁の最下位ビットセット
}
else { /// 最上位桁の場合（Buff[0][*]）
CarryH= Buff[l][m] & 0x8000; // 最上位ビットをCarryHへ保存
Buff[l][m]= Buff[l][m] << 1; // ビットを左へシフト
if (CarryL[m] != 0) Buff[l][m] |= 1; // 下位桁[1]のキャリーが立っていたら
if (CarryH != 0) Buff[MaxWord-1][m] |= 1; // 上位桁のキャリーが立っていたら最下位桁の最下位ビットセット
}
//// 表示面にデータ転送し表示（1行毎）
Send_x2_MAX7219(m+1, (unsigned char)(Buff[0][m] >> 8),(unsigned char)(Buff[0][m] & 0x00FF));
}
}
delay_ms(1000);
}
■ 2020.1.25
・今回のケースは、if分岐だと分岐・処理の状況が把握しずらいので、昨日のソースを、case分岐に変えてみた。
まあ現象は変わらないが、私には、この方が追い易い。
■ 2020.1.26
・4桁版ズレ無し動く。
＜ソース修正・改善事項＞
① if分岐を、case分岐にして、シフトの挙動を追い易くした。
最上位桁をcase
3、最下位桁を、case
0、その途中を、case
2、case
1とした。
case
2、case
1は同じ処理なので、今は同じ記述にしているが、もっと効率良い書き方があったと記憶
している。後で直すつもり。
② 以下の点を直したら、ズレ（文字間隔が1dot少なくなる）が無く動くようになった。
・下位桁のキャリーが立っていない場合の、上位桁の最下位ビットのクリアは必要だった。追加した。
・Carry変数を、1つにした。
下位桁のキャリーとし、MaxWord：15と、行変数：m（0から7）による、2次元配列にした。
最上位桁のキャリーは、CarryL[0][m]で判別出来る。
■ 2020.1.27
・15桁版ズレ無し、ようやく動く。
＜ソース修正点＞
① 4桁版の考えを拡張して、今回の最終目標であった15桁版を書き上げた。
② 15桁の場合の、caseは、
case
14が、最下位桁、case
0が、最上位桁、
case
13～1は、その途中で処理は同じ。（但し、桁変数のl（小文字のエル）は変化する）
これを効率よく書く書き方だが、
case
13から、case
2までは、break無しで続けて書き、case
1に共通の処理（break含む）を
書けば良い。
※ VIDEOを撮ったので御覧ください。→ video003.mp4
-----＜ ここから追試：Step5の記事 ＞------------------------------------------------------------------------------
■ 2020.1.31
・フォント・テーブルの、ASCIIコード指定で、2文字の文字列を表示する関数を考える。
ポインタを使うことになる。
簡単な例を以下に示した。（主要部のみ）
/// LED Message
char LedMsg[] = "AB";
/// "AB"表示
LedMatrix2_StrDisp(LedMsg);
//===================================================
/// サブ関数
/****************************************************
* 文字列表示関数（2個カスケード接続専用）
*
*****************************************************/
void LedMatrix2_StrDisp(char *str) {
char i;
for (i=0; i<8; ++i) {
Send_x2_MAX7219(i+1, Font8x8[*str-0x20][i], Font8x8[*(str+1) - 0x20][i]);
}
}
・これで問題無く動く。
しかし、気になることが・・・
Pickit2で、HEXをインポートした時、見慣れない以下のような、ワーニングが出たのである。
まあ動いてはいるが？
・この時の、HEXサイズは、6.05kB。
これに対し、PIC18F14K50の、プログラム・エリアは、16kBなので、OKなはずなのに？？
また、この前の、15桁スクロール版の、HEXは、6.14kBで、このワーニングは出なかった？？
MPLAB X IDE上で調べても、プログラム・メモリは、13%しか使ってない。
■ 2020.2.2
・今迄、PIC18F14K50への、HEX書込みに、Pickit2を使っているのは、このデバイス選択が可能である事と、
ターゲットへの、電源供給容量が、Pickit3より多いので、ターゲットの主電源を落とした状態で気楽に、書込み
が出来るからである。
ここで、Pickit3＋MPLAB IPEで書込んだらどうなるか確認してみた。
以下に示す通リ、異なるインポート時のメッセージだが、同じ意味合いに取れる内容だった。しかし同じく動作はする。
尚、Pickit3の時は、ターゲットの主電源を、ONにして書込まないと、POWER関係のエラーになる。（今回は消費電流大）
■ 2020.2.3
・さらに、初めてだが、MPLAB IPE（HEX書込みのツール）を使わないで、MPLAB
X IDEの、メニューバーにある
「Make and Program Device Main Project」（ビルド～Pickit3接続＋HEX書込みまでやってくれる）を使って、インポート
～書込みまでやってみたが、MPLAB
IPEでインポートした時と、同じワーニングが出た。（当然と言えば当然だが・・）
しかしこれで書込んでも正常動作している？
何故だろうか？
警告内容からして、DEVICE選択の時に、誤ってPIC18F14K50以外のPICを選択したことが考えられるが、
再確認したところ、ちゃんと「PIC18F14K50」に設定されていた。
また、前にも書いた通リ、プログラムメモリは、13%しか使ってない。
無視しても良いワーニングと考え先に進めることにした。
MPLAB X IDEのバージョンが古いせもあるのかな？（V3.05使用）
この件、後々調べて進展があったら都度レポートしたいと思いますが、
どなたか、何故か解る方おられましたら、お問い合わせフォームから連絡してくだされば幸いです。
・追記：よく見たら、クリーンビルド（かなずち＋ほうきアイコン）でビルド成功後のcode
loardingの段階で
同じワーニングが出ていたが、今まで気が付かなかった。 200208
■ 2020.2.4
・という訳で、Step5はOKになる。（OKとしたと言った方が良いかな・・）
ASCIIコード：0x20～ Ox7F以降にある、半角カタカナ文字列も表示させてみました。
■ 2020.2.5
・Step6（フォントテーブルのデータを元に、表示用のデータを生成し、それを循環スクロール表示）を開始。
LEDメッセージの各文字フォントを、フォントテーブルから読出し、表示桁数分の表示バッファ・データを生成
する関数を考える。（2個カスケード接続専用）
この関数と、mainを含めた全体の流れの構想は以下の様なのを考ました。
#define MaxWord 15 // 表示桁数
unsigned int DispBuff[MaxWord][8]; // 表示バッファ
/// LED Message
char LedMsg[] = "Nobosan's Electronic WorkShop ";
/// Main
// LEDメッセージの各文字を、フォントバッファから読出し、表示桁数分の表示データを生成。
CreateDispBuff(LedMsg);
/// Sub
/************************************************************
* LEDメッセージの各文字フォントを、フォントテーブルから読出し、
* 表示桁数分の表示バッファ・データを生成
*（2個カスケード接続専用）
*************************************************************/
void CreateDispBuff(char *str) {
char l,m;
for (l=0; l<MaxWord; l++) {
for (m=0; m<8; m++) { // 8行分をMaxWord桁分
DispBuff[l][m]= (unsigned int)Font8x8[*str-0x20][m] << 8 | (unsigned int)Font8x8[*(st+1)-0x20][m] & 0x00FF;
}
}
}
■ 2020.2.6
・デバッグの結果ポインタ操作に誤りが有り、修正したところ一応、Step6もOKになる。
文字間隔も、生成した表示桁数分の表示バッファ・データと一致していました。
スクロールさせたい文字列を変えるには、その表示桁数の定義：MaxWordの数値と、LED Messageバッファ：LedMsg[]
の文字列の内容を変えるだけで出来ます。
※ VIDEOを撮ったので御覧ください。→ video004.mp4
＜回路図＞
・こちらからどうぞ→ 「8x8マトリックスLED実験」
「8x8LEDカスケード接続実験」 （ブロック接続図）
＜最終ソース・ヘッダファイル＞
・こちらから、どうぞ：
① Step1プロジェクト：アスキーコード指定で、フォント・テーブル内の全キャラクタを順次表示。
Font8x8.h
MAX7219_8x8LedMatrix_TEST.c
② Step2プロジェクト：8x8Ledモジュール1個で、スクロール実験。
MAX7219_8x8LedMatrix_Scroll_TEST.c
③ Step3プロジェクト：8x8Ledモジュール2個を、カスケード接続し、スクロール実験。
MAX7219_8x8LedMatrix2_Scroll_TEST.c
④ Step4プロジェクト：8x8Ledモジュール2個を、カスケード接続し、より多く（15桁）の文字をスクロールする実験。 200130
更新
MAX7219_8x8LedMatrix2_Scroll_TEST2.c
⑤ Step5プロジェクト：8x8Ledモジュール2個を、カスケード接続し、アスキーコード指定で、文字列（2文字）を表示する実験。 200210
更新
MAX7219_8x8LedMatrix2_TEST.c
（この他に、①の、Font8x8.hが必要です。）
⑥ Step6プロジェクト： LEDメッセージの各文字フォントを、フォントテーブルから読出し、表示桁数分の表示バッファ・データを生成し
それを循環スクロールする実験。 200210
更新
MAX7219_8x8LedMatrix2_Scroll_TEST3.c
（この他に、①の、Font8x8.hが必要です。）
