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

［第１７３回］



●ＰＩＣ１８Ｆ１４Ｋ２２でまさかのエラー（３）

前回からの続きです。
今回はやっと解決編です。
余りにもおかしいベリファイエラー。
ところが繰り返してテストをしているうちに。
おお。
見えてきましたよ。
ひょっとしたら。

運鈍根という言葉があります。
私は運には恵まれているほうだと思います。
鈍はその通りだと思います。
とにかく鈍い。
気が付くのが人一倍遅いです。
若い頃は気が短かった。
まだアマチュアのころは回路がうまく動かないと、腹が立って放り投げてしまうことがよくありました。
ま。でも。２〜３日経つとだんだん落ち着いてきて、放り投げてしまった基板をまた取り出してあれこれいじくりだしたりしていました。
今はトシのせいかずいぶん気が長くなったように思います。
どこかにおかしなところがあるはず。
まま。
コーヒーでも飲みながら、とか。
今日のところは一杯飲んで寝てしまって、明日また考えてみようとか。
余談でありますが。
以前はそういうときはもっぱら金麦でありましたが。
メーカーが苦労して安いものを作って売り出してそれが売れてくるとすぐに課税基準の見直しだとか。
はやい話が増税じゃありませんか。
もう悪代官でありますね。
おぬしもワルじゃのう。
しかし。
庶民はしたたかでありますよ。
金麦はやめました。
黒霧島の１．８Ｌパックなんざコスパがよくてなかなかにいけるじゃありませんか。
そいつをオンザロックでチビチビやるとか。
私はもともとアルコールには弱いほうなのでそんなに飲めません。
ですからウィスキーだってコスパよく飲めてしまいます。
最近は凛を飲んでいます。
ネーミングが良いじゃありませんか。
こいつも安くてそれなりにいけます。
オンザロックでストレートで飲めるようになってしまいました。
えっと。
余談になってしまいました。
とにかく途中で諦めたりしないで根気よくしつこく続けることが肝要かと。
それで。
繰り返しテストをしているうちに。
何回目かのテストで比較データの異常表示と思われたところにある規則があることに気が付きました。

２行目を見ると本来の書き込みデータ４バイトの後ろが全部００になっています。
そしてその次の行は本来はアドレス０００８からの４バイトに値が書き込まれるはずなのですが、そこが００１８からの４バイトになっていて、その前後はやはり００が書き込まれています。
それからその下のブロックのアドレス０５８０を見ると最後のＦＦであるはずのところがＦ０になっています。
それからその下のアドレス０５９０は８バイトしか書き込んでいないのですが、その後ろまで全部値が書き込まれています。
残りの８バイトの値はその上の値と同じです！
そういうことだったのか！
実はテストをしていく過程でＦＦだけの行は送信しないでパスするようにしたのですがそれと同時に１６バイトに満たないデータや後ろがＦＦであるようなデータは実際に値がある分だけのバイト数を送るようにしました。
うーん。
確かそれはＰＩＣ１８Ｆ４５５０でもそのようにしたはずだったのですが…。
そこはよく確認していません。
とにかく原因らしきものがわかった以上前に戻ったりしないでその対策をすべきです。
１６バイトに満たないデータを送ると書き込み先のＰＩＣのバッファに前の値が残っていてそれを全部書き込んでしまうのが原因だったようです。
もうひとつ。
アドレス０００８の値がアドレス００１８に書かれてしまうことについてはＰＩＣの書き込みプログラムに問題があったのに加えてＰＩＣ１８Ｆ１４Ｋ２２だけかもしれませんが１６バイト分の書き込みを行なうとバッファの書き込みアドレスが自動的に次のアドレスにインクリメントしてしまうらしいことがわかりました。
自分ではわかっているのですがうまく説明ができません。
とにかくそういうことのようです。
下の方の何行かはＣＯＮＦＩＧです。
ＣＯＮＦＩＧは１バイトずつ書き込みますからそういう問題はありません。
ちょっと見ると左右が違って見えますがアドレスとバイト数を見ながら確認していくと正しく書き込まれていることがわかります。

さて。
同じ書き込みプログラムなのにＰＩＣ１８Ｆ４５５０以前は正しく書き込みができていたのになぜＰＩＣ１８Ｆ１４Ｋ２２では上記の問題が出てしまうのか？
そしてそれにもかかわらずＮＤ８０Ｚ３．５版の書き込みプログラムではＰＩＣ１８Ｆ１４Ｋ２２も正しく書き込みできるのか？
ということなのですが。
実はＮＤ８０Ｚ３．５版とＰＩＣプログラム版には大きく異なっているところがありました。
ＮＤ８０Ｚ３．５版を作るときにＰＩＣ１８Ｆ１３Ｋ５０のバッファが８バイトであることを意識して書き込みデータは１６バイトを８バイトに分割して送出していたのでした。
そのようにするとアドレス００１８に誤書き込みされることがないことが確認できました。
そこでＰＩＣプログラムもそこを変更して８バイト以下の行については８バイトデータとして処理するようにしたところ上記の異常書き込みは起こらなくなりました。

うむむむむ。
こういうところがいかにもＭＩＣＲＯＣＨＩＰなのですよねえ。
ＰＩＣ１８Ｆ１３Ｋ５０もＰＩＣ１８Ｆ１４Ｋ５０も同じような書き込みデータなのに何の問題も起きなくて、それがＰＩＣ１８Ｆ１４Ｋ２２だとそういうことになってしまうなんて。
どうやらＰＩＣ１８Ｆ１４Ｋ２２は中のロジックをちょいと手直しなさったようであります。
できればそういうことはやってほしくないのですけれどねえ。

年の暮れの貴重な２日間を潰してしまいましたが、なんとかやっとクリアできたようです。
これにて一件落着。
今夜は凛のオンザロックで乾杯です。
悪代官くそくらえ。
であります。

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

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