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

［第１６４回］



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

前回を書いていてその途中で突然ひらめいたのはひょっとしてＰＩＣ１８Ｆ１３Ｋ５０のＷＲＩＴＥ　ＢＵＦＦＥＲはエンドレスのリングバッファではないか、という考えです。
リングバッファなら８バイトのＷＲＩＴＥ　ＢＵＦＦＥＲに書き込む時間がそのデータをフラッシュメモリに書き込む時間よりも短ければオーバーフローすることはありません。
一旦はそのように考えて納得したのですが。
一晩寝て翌日になってからよくよく考えてみるとやっぱりおかしい。
どうにも納得できません。

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

ＦＩＧＵＲＥ　４−５にクロックパルスとともにデータを書き込む様子が示されています。
４ビットコマンド（１１１１）に続いてＷＲＩＴＥ　ＢＵＦＦＥＲにデータを送ったあとコマンド（００００）でそのデータをフラッシュメモリに書き込みます。
この図で見ると１６ビットのデータをＷＲＩＴＥ　ＢＵＦＦＥＲに送る都度、そのデータを００００コマンドでフラッシュメモリに書き込むように思ってしまいそうですが、そうではなくてＦＩＧＵＲＥ４−４の図からおそらくＷＲＩＴＥ　ＢＵＦＦＥＲバイト分のデータをＷＲＩＴＥ　ＢＵＦＦＥＲに送ったあとＳＴＡＲＴ　ＷＲＩＴＥコマンド（００００）を発行すると解釈すべきと思われます。
ここで重要なのはＰｒｏｇｒａｍｍｉｎｇ　Ｔｉｍｅ　Ｐ９とＰ１０です。
Ｄａｔａｓｈｅｅｔで確認してみるとＰ９＝１ｍｓ、Ｐ１０＝１００μｓになっています。
Ｐ５、Ｐ５Ａが４０ｎｓであることから考えるとコマンド００００のところで要求されている時間はバッファにデータを読み込む時間よりも桁違いに長いことがわかります。
ちなみにＰＧＣの１ビットクロック時間は１００ｎｓです。
この数値から考えると前回思いついたリングバッファでは駄目ということになります。
やっぱり上に書いたように書き込みデータを一旦ＷＲＩＴＥ　ＢＵＦＦＥＲに溜めてから００００コマンドでフラッシュメモリに書き込むと考えるしかありません。
ならばなぜ８バイトしかないはずのバッファなのに１６バイトのデータが正しく書き込めてしまうのか？
論理的にはありえない事象です。
悪霊のしわざでありましょうか？
そうではないとすると。
考えられることはただひとつです。
ＤＡＴＡ　ＳＨＥＥＴの記述が間違っていて本当はＰＩＣ１８Ｆ１３Ｋ５０のＷＲＩＴＥ　ＢＵＦＦＥＲも１６バイトだったとしたら？
ありえない話ではないと思います。

［出典］Ｍｉｃｒｏｃｈｉｐ　Ｔｅｃｈｎｏｌｏｇｙ　Ｉｎｃ．ＰＩＣ１８Ｆ１ＸＫ５０　ＤＡＴＡ　ＳＨＥＥＴ

ＴＡＢＬＥ１−１によるとＰＩＣ１８Ｆ１３Ｋ５０と１４Ｋ５０の相違はＩＣ　ＣＨＩＰに実装しているメモリ容量のみのようです。
ということは。
１３Ｋ５０と１４Ｋ５０のＣＰＵコアは同じなのではないか？
ＷＲＩＴＥ　ＢＵＦＦＥＲはおそらくＣＰＵコアの中にある、と考えると１３Ｋ５０のＷＲＩＴＥ　ＢＵＦＦＥＲも１６バイトであっても不思議ではありません。
ＤＡＴＡ　ＳＨＥＥＴを作成する段階では１３Ｋ５０と１４Ｋ５０は別のＣＰＵコアにするつもりだったものがその後のどこかの時点で同じコアを使うことになってしまったのではないか？
それはあくまで私の推論であります。
さもなければ。
悪霊のなせるワザであります。
あな、おそろしや。

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

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