PICBASICコンパイラ
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
まるでインタプリタ。でもコンパイラです。超カンタン超シンプルです。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
[第163回]
●PIC18F13K50のWRITE BUFFERは8バイトのはず?
前回まで作成してきたPIC WRITERプログラムはPIC18F14K50にプログラムを書き込むためのものでした。
MPLABでプログラムを作成したときに生成されるHEXファイルの1行のデータは最大16バイトです。
PIC18F14K50のWRITE BUFFERは16バイトなのでHEXファイルの1行分のデータをそのまま書き込み用のデータとしてターゲットのPIC18F14K50に送出できます。
しかしPIC18F13K50のWRITE BUFFERは8バイトなので16バイトのデータは半分の8バイトにして2回に分けて送出する必要があります。
ここからが今回のテーマに関する問題になります。
実は昨年ND80Z3.5の82C55を使ったPIC WRITERプログラムはそのこと(18F14K50のWRITE BUFFERは16バイトだが18F13K50は8バイトしかないということ)を考慮して8バイト単位で書き込むようにしたプログラムでした。
そのように考慮したプログラムならPIC18F13K50にもPIC18F14K50にもどちらに対しても同じように書き込みができます。
そのときはあくまで試作版だったのでそのようにしたのですけれど。
今回は書き込み用のCPUとしてND80Z3.5(Z80)ではなくて書き込み用のCPUとしてもPIC18F14K50(またはPIC18F13K50)を使います。
話がややこしくなるのですがターゲットではなくて書き込み用に使うPICは18F13K50でも14K50でもそのほかのUSB機能があるPICならなんでも構いません。
今回問題にしているのはそこに実際にプログラムを書き込むターゲットとなるPICについての話です。
PICが2個出てきますので、どのPICの話?
と混乱してしまいそうです。
下の写真は[第157回]でお見せしたものですが参考までに再掲します。
PIC WRITERプログラムは試作ではND80Z3.5を使いましたが今回はPIC WRITER回路にPICBS01を接続して使います。
書き込みプログラムはPICBS01のPIC18F14K50(13K50でも可)に書き込んだものを実行します。
書込みの対象となるPICは写真の上側のテストソケットにセットするPICです。
そこには前回まではPIC18F14K50をセットしてそのPICに書き込みを行いました。
上にも書きましたように昨年の試作ではPICBS01の代わりにND80Z3.5を接続していました。
PICBS01に実装する書き込みプログラムの対象はPIUCBS01上のPICではなくてあくまでテストソケットにセットするPICです。
今回問題にしているのもそのテストソケットにセットするPICについてです。
ここではテストソケットにセットするPICを「ターゲット」と表現しています。
本題に戻ります。
以前はとりあえずの試作としてデバッグが容易なND80Z3.5を使ってPIC WRITERプログラムを作成しましたが、今回は最終的なPIC WRITERを作るつもりでしたのでPICBS01に実装するPIC18F14K50(13K50)のプログラムとしてMPLABを使って作成しました。
で。
上に書きましたようにもとになるHEXファイルの1行のデータは最大16バイトです。
ターゲットのPIC18F14K50のWRITE BUFFERも16バイトです。
HEXファイルの1行分のデータをそのままターゲットのPIC18F14K50に送ることができます。
プログラムとしては8バイトずつ2回に分けるよりも16バイト1回にするほうがはるかに楽なのでWRITE BUFFERが16バイトのPIC18F14K50専用の書き込みプログラムとして作成して動作テストをしてきました。
ここで読者様としては、う?8バイト?16バイト?何じゃ、それは?
というようなもやもや感をお持ちかと思います。
こういうことです。
[出典]Microchip Technology Inc.PIC18F1XK50 Flash Memory Programming Specification
TABLE 4−4にそれが示されています。
例えで言いますと。
水道の蛇口の水を16リットルのバケツに汲んでそれを風呂桶に入れる場合と8リットルのバケツでそれを入れる場合を考えてみます。
当然8リットルのバケツでは一度に8リットルしか運べません。
そこに16リットルを入れようとすれば8リットル分が溢れてしまいます。
それが当然の理屈です。
[出典]Microchip Technology Inc.PIC18F1XK50 Flash Memory Programming Specification
FIGURE 4−4のNがバケツの容量を量るカウンタです。
一度に2バイトずつバッファからFLASH MEMORYにデータを移しますからNはバッファサイズの1/2でフルカウントになります。
あっ。ひょっとしたら。ここか?
突然わかってしまったように思います。
何を言うとるんじゃ。お前は?
さっぱりわからんぞう。
なんだか突然わかってしまった気がしますがそれについては次回書くことにします。
以下はわかってしまう前の私の認識で書きます。
つまり。
もしもWRITE BUFFERのサイズが上の例えのバケツの容量だとしますとPIC18F13K50に対して一度に16バイトのデータを送ったならば、後半の8バイトがこぼれてしまうではないかと考えたわけです。
そこで一度に16バイトを送るようになっていたプログラムをPIC18F13K50用に16バイトを2回に分けて8バイトずつ送るようにしたプログラムを追加しました。
それを/PICWR8コマンドとしたのですが。
念のために。
今までの16バイト一括書き込みの/PICWRコマンドをそのままPIC18F13K50に対して書き込み実行してみました。
当然1行16バイトのデータの内の後半の8バイトは書き込まれないと思ったのですが。
ぬあんと。
しっかり書き込まれてしまいました。
左がもとになったHEXファイルで右がそれを書き込んだあとで秋月のPICプログラマにかけて読み出してHEXファイルにしたファイルです。
右側は1行のうち前半の8バイトのみが正しく書けて、後半の8パイトは全く書けない(FF)と思ったのですが。
しっかり1行16バイト全部が正しく書かれてしまいました。
ありえない!
むむ。
さては悪霊のしわざか?
かくてまるっと一日悪霊退散を唱えながら過ごしたのであります。
次回に続きます。
PICBASICコンパイラ[第163回]
2024.11.23 upload
前へ
次へ
ホームページトップへ戻る