ＰＩＣＢＡＳＩＣコンパイラ
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
まるでインタプリタ。でもコンパイラです。超カンタン超シンプルです。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

［第１６３回］



●ＰＩＣ１８Ｆ１３Ｋ５０のＷＲＩＴＥ　ＢＵＦＦＥＲは８バイトのはず？

前回まで作成してきたＰＩＣ　ＷＲＩＴＥＲプログラムはＰＩＣ１８Ｆ１４Ｋ５０にプログラムを書き込むためのものでした。
ＭＰＬＡＢでプログラムを作成したときに生成されるＨＥＸファイルの１行のデータは最大１６バイトです。
ＰＩＣ１８Ｆ１４Ｋ５０のＷＲＩＴＥ　ＢＵＦＦＥＲは１６バイトなのでＨＥＸファイルの１行分のデータをそのまま書き込み用のデータとしてターゲットのＰＩＣ１８Ｆ１４Ｋ５０に送出できます。
しかしＰＩＣ１８Ｆ１３Ｋ５０のＷＲＩＴＥ　ＢＵＦＦＥＲは８バイトなので１６バイトのデータは半分の８バイトにして２回に分けて送出する必要があります。
ここからが今回のテーマに関する問題になります。
実は昨年ＮＤ８０Ｚ３．５の８２Ｃ５５を使ったＰＩＣ　ＷＲＩＴＥＲプログラムはそのこと（１８Ｆ１４Ｋ５０のＷＲＩＴＥ　ＢＵＦＦＥＲは１６バイトだが１８Ｆ１３Ｋ５０は８バイトしかないということ）を考慮して８バイト単位で書き込むようにしたプログラムでした。
そのように考慮したプログラムならＰＩＣ１８Ｆ１３Ｋ５０にもＰＩＣ１８Ｆ１４Ｋ５０にもどちらに対しても同じように書き込みができます。
そのときはあくまで試作版だったのでそのようにしたのですけれど。
今回は書き込み用のＣＰＵとしてＮＤ８０Ｚ３．５（Ｚ８０）ではなくて書き込み用のＣＰＵとしてもＰＩＣ１８Ｆ１４Ｋ５０（またはＰＩＣ１８Ｆ１３Ｋ５０）を使います。
話がややこしくなるのですがターゲットではなくて書き込み用に使うＰＩＣは１８Ｆ１３Ｋ５０でも１４Ｋ５０でもそのほかのＵＳＢ機能があるＰＩＣならなんでも構いません。
今回問題にしているのはそこに実際にプログラムを書き込むターゲットとなるＰＩＣについての話です。
ＰＩＣが２個出てきますので、どのＰＩＣの話？
と混乱してしまいそうです。
下の写真は［第１５７回］でお見せしたものですが参考までに再掲します。

ＰＩＣ　ＷＲＩＴＥＲプログラムは試作ではＮＤ８０Ｚ３．５を使いましたが今回はＰＩＣ　ＷＲＩＴＥＲ回路にＰＩＣＢＳ０１を接続して使います。
書き込みプログラムはＰＩＣＢＳ０１のＰＩＣ１８Ｆ１４Ｋ５０（１３Ｋ５０でも可）に書き込んだものを実行します。
書込みの対象となるＰＩＣは写真の上側のテストソケットにセットするＰＩＣです。
そこには前回まではＰＩＣ１８Ｆ１４Ｋ５０をセットしてそのＰＩＣに書き込みを行いました。
上にも書きましたように昨年の試作ではＰＩＣＢＳ０１の代わりにＮＤ８０Ｚ３．５を接続していました。
ＰＩＣＢＳ０１に実装する書き込みプログラムの対象はＰＩＵＣＢＳ０１上のＰＩＣではなくてあくまでテストソケットにセットするＰＩＣです。
今回問題にしているのもそのテストソケットにセットするＰＩＣについてです。
ここではテストソケットにセットするＰＩＣを「ターゲット」と表現しています。
本題に戻ります。
以前はとりあえずの試作としてデバッグが容易なＮＤ８０Ｚ３．５を使ってＰＩＣ　ＷＲＩＴＥＲプログラムを作成しましたが、今回は最終的なＰＩＣ　ＷＲＩＴＥＲを作るつもりでしたのでＰＩＣＢＳ０１に実装するＰＩＣ１８Ｆ１４Ｋ５０（１３Ｋ５０）のプログラムとしてＭＰＬＡＢを使って作成しました。
で。
上に書きましたようにもとになるＨＥＸファイルの１行のデータは最大１６バイトです。
ターゲットのＰＩＣ１８Ｆ１４Ｋ５０のＷＲＩＴＥ　ＢＵＦＦＥＲも１６バイトです。
ＨＥＸファイルの１行分のデータをそのままターゲットのＰＩＣ１８Ｆ１４Ｋ５０に送ることができます。
プログラムとしては８バイトずつ２回に分けるよりも１６バイト１回にするほうがはるかに楽なのでＷＲＩＴＥ　ＢＵＦＦＥＲが１６バイトのＰＩＣ１８Ｆ１４Ｋ５０専用の書き込みプログラムとして作成して動作テストをしてきました。
ここで読者様としては、う？８バイト？１６バイト？何じゃ、それは？
というようなもやもや感をお持ちかと思います。
こういうことです。

［出典］Ｍｉｃｒｏｃｈｉｐ　Ｔｅｃｈｎｏｌｏｇｙ　Ｉｎｃ．ＰＩＣ１８Ｆ１ＸＫ５０　Ｆｌａｓｈ　Ｍｅｍｏｒｙ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ

ＴＡＢＬＥ　４−４にそれが示されています。
例えで言いますと。
水道の蛇口の水を１６リットルのバケツに汲んでそれを風呂桶に入れる場合と８リットルのバケツでそれを入れる場合を考えてみます。
当然８リットルのバケツでは一度に８リットルしか運べません。
そこに１６リットルを入れようとすれば８リットル分が溢れてしまいます。
それが当然の理屈です。

［出典］Ｍｉｃｒｏｃｈｉｐ　Ｔｅｃｈｎｏｌｏｇｙ　Ｉｎｃ．ＰＩＣ１８Ｆ１ＸＫ５０　Ｆｌａｓｈ　Ｍｅｍｏｒｙ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ

ＦＩＧＵＲＥ　４−４のＮがバケツの容量を量るカウンタです。
一度に２バイトずつバッファからＦＬＡＳＨ　ＭＥＭＯＲＹにデータを移しますからＮはバッファサイズの１／２でフルカウントになります。
あっ。ひょっとしたら。ここか？
突然わかってしまったように思います。

何を言うとるんじゃ。お前は？
さっぱりわからんぞう。
なんだか突然わかってしまった気がしますがそれについては次回書くことにします。
以下はわかってしまう前の私の認識で書きます。

つまり。
もしもＷＲＩＴＥ　ＢＵＦＦＥＲのサイズが上の例えのバケツの容量だとしますとＰＩＣ１８Ｆ１３Ｋ５０に対して一度に１６バイトのデータを送ったならば、後半の８バイトがこぼれてしまうではないかと考えたわけです。
そこで一度に１６バイトを送るようになっていたプログラムをＰＩＣ１８Ｆ１３Ｋ５０用に１６バイトを２回に分けて８バイトずつ送るようにしたプログラムを追加しました。
それを／ＰＩＣＷＲ８コマンドとしたのですが。
念のために。
今までの１６バイト一括書き込みの／ＰＩＣＷＲコマンドをそのままＰＩＣ１８Ｆ１３Ｋ５０に対して書き込み実行してみました。
当然１行１６バイトのデータの内の後半の８バイトは書き込まれないと思ったのですが。
ぬあんと。
しっかり書き込まれてしまいました。

左がもとになったＨＥＸファイルで右がそれを書き込んだあとで秋月のＰＩＣプログラマにかけて読み出してＨＥＸファイルにしたファイルです。
右側は１行のうち前半の８バイトのみが正しく書けて、後半の８パイトは全く書けない（ＦＦ）と思ったのですが。
しっかり１行１６バイト全部が正しく書かれてしまいました。
ありえない！
むむ。
さては悪霊のしわざか？
かくてまるっと一日悪霊退散を唱えながら過ごしたのであります。
次回に続きます。

ＰＩＣＢＡＳＩＣコンパイラ［第１６３回］
２０２４．１１．２３　ｕｐｌｏａｄ

前へ
次へ
ホームページトップへ戻る