EEPROMエミュレーション・ライブラリ Pack02の最大データ数が255の訳がわかりません。

訂正です。
30ブロックはとれますね。　265×30 = 7950byteで、 8192 - 7950 = 242byte の端数です。
よろしくお願いします。

わわいです
まあ、推測の話でしかないですが、データ数を保持する変数を１バイトで済ますためにそうならざるを得ない、というところなんでしょう。
まあ、この変数を２バイトにすればいいだけのはなしですが、同じサイズのバッファをRAMに確保しなければならないとかそこら辺の事情を考えると、１バイトで行きましょう、ってことではないかと。

まあ、使われない領域が出るのがキモチワルイ、とするなら、１ブロックのデータ数を２４６バイトにすれば使い切ることができますぜ。結局はユーザの使い方次第でどーとでもなることですわな。

チョコです。
単に8ビットで管理するために最大が255になっただけだと思いますよ。
実際に使うときに必要に応じて値を決めてしまうだけです。
確実なところは仕様を決めたルネサスに問い合わせてみてください。

ぴろです。どのReplyボタンを押していいのか判らないのでチョコさんのReplyで。
わいわいさん、チョコさん返事ありがとうございます。
わいわいさん＞１ブロックのデータ数を２４６バイトにすれば使い切ることができますぜ。
やはりそうですよね。ここは246byteで行きたいと思います。
もう２つ、R01US0068JJ0101 Rev.1.01をよんでも理解出来ないのが
10ページの「図 2-7 有効なEELブロックの例」です。EELが255byteまでしかサポートしていないのにこの図は1kbyteの大きさ。しかもユーザが使えるデータがどこからどこまでか判らない。まさか最後の03FBから03FFまでのってことは無いよね？と。
4ページのEEL Pack01とEEL (Pack02)の仕様の差異について記載された表の記述が難解です。
一行目の「ユーザ・データ長」が1～255までとあるのに5行目の「ユーザ･データの推奨サイズ 注1」の記述では
1014/2 バイトとあり、507byteが推奨???
推奨しているのにも拘わらずEELのユーザ・データ長が255byte?
注1の記述を読むと「ブロックの1/2以内～」とあり、結局8kbyte有っても使える範囲は4kbyteってこと？？等々
今回は500byte程度しか使わないので問題はないのですが、皆さんよくこのマニュアルでプログラム作れるなぁ？？？と感心してます。

> 10ページの「図 2-7 有効なEELブロックの例」です。EELが255byteまでしかサポートしていないのにこの図は1kbyteの大きさ。

1ページ目からこのマニュアルでの用語が解説されていますが、それを参照されると疑問も解決されると思います。

チョコです。
>EELが255byteまでしかサポートしていないのにこの図は1kbyteの大きさ。
1kbyteは物理的なデータフラッシュ（EELで使用する領域）の大きさです。
実際に格納しているデータそのものは下側から並んでいる部分です。3つのデータ（ID=0x01,0x04,0x02）を格納している例が図2-7です。ひろさんが，気にしている個々のデータはID=0x01が4バイト，ID=-0x04が2バイト，ID=0x02が1バイトです（全て255バイト以下です）。

>5行目の「ユーザ･データの推奨サイズ 注1」の記述では1014/2 バイトとあり、507byteが推奨???。
EELは1ブロック（1kbyte）に2つ以上のデータを書き込めるように考えているので，こうなります。
単純に大きいデータを書き込むのであれば，EELではなく，データ・フラッシュ・ライブラリを使ってください。
基本的な使い方は短いデータをブロックの中に入る範囲でデータを書き換えるのではなく（フラッシュは書き換えはできない），新たに追加で書き込んでいき，もう書けなくなったら次のブロックに移るものです。新たに書かれたデータが有効であることを示すために参照領域を使って管理しています。おそらく，次にID=0x01に新たなデータを書き込むと，相対アドレス0x000Eに0x01が，0x000Fに0xFEが書き込まれることになります。新しいデータは0x03F5～0x03F8に書き込まれるはずです。

>皆さんよくこのマニュアルでプログラム作れるなぁ？？？と感心
別に図2-7を理解しておく必要はなく，単にライブラリで準備された関数を介して使用するだけです。中の構造は知らなくても使いこなせますよ。

ぴろです。
文字数制限があるようで長々書いたReplyがエラーになりました。
１／３位に分割してReplyします。
その１です。
ぴろです。
皆さんのいろいろな見方を拝見して、曲解・誤解していた点が解消しました。
誤解点：EELブロックはEELブロックヘッダデータ部でのみ構成されていて、ヘッダ+データで263byte/ブロック。
－＞　EELブロックはEELブロックヘッダ＋複数のSoR+EoR+セパレータ+データ領域で1024byte/ブロック。
ブロックヘッダ＋参照領域＋セパレータ=16byteで、残り1008byteをデータ領域として使えるが、データ長が255なので
255 x 3 = 765byte、　255 x 4=　1020　から使えるのは3データ長分のみで、1008-765 = 243byteが端数となり無駄になる。
誤解点：データはアドレスの小さいほうからデータを格納していくの？
－＞アドレスの大きいほうから書いていく。

その２です。
疑問点：EELブロックのどこからどこまでにどのくらいのbyte数で書かれているかを管理するデータはどこ？
－＞eel_descriptor.hの#define EEL_VAR_NO 8　の記述から
__far const eel_u08 eel_descriptor[EEL_VAR_NO+2] =　テーブルを参照し、
(eel_u08)(sizeof(type_Z)), /* id=8 */ \
を引っぱってくるからデータは255byte毎であることが判る。

その３です。
実際EELを使って書き込んだDATAFLASH領域を確認すると
0xf1000 　01 FE 00 FF FF FF FF FF 08 F7 08 F7 08 F7 FF FF　←ブロックヘッダと3個のSoR,EoRとセパレータ
マニュアル8ページの表の記載から、ブロックヘッダの状態は無効ブロックになっている。
0xf1010 - 0xf1102までがすべて0xFFで此処が端数部分
0xf1013から0xf13FFまでに255byte毎のデータが並んでいました。
0xf1400から次ぎのEELブロックを示す
02 FD 00 FF FF FF FF FF 08 F7 08 F7 08 F7 FF FF
となっていました。
このブロックもすでに無効ブロックになっています。
0xf1800からは　EELブロックヘッダが03 FC FF FFとあり、此処が現在使用中のブロックだということが判りました。　

ここまでは理解出来ました。
皆さん、どうもありがとうございました。

わわいです
まずはフラッシュメモリというのがどういうものかを勉強しましょう。
そして、そのライブラリは、フラッシュメモリを使ってなにを実現しようとしているのか、というのを読み取りましょう。

フラッシュメモリには大きな欠点があります。　それをなんとか回避／緩和するためにいろいろ面倒なことをしていたりします。
それがなにか、また、それをどうやって回避させようとしているのか、を理解する必要があります