<div dir="ltr">I've been using i2c and SPI eeproms for almost two decades.  All of them can read/write a single byte if that's what you want to do, but the write/erase restrictions I noted are there for any parts I've ever used.  If you write a byte to $00, you cannot write it to $01 without first erasing the entire block that it is located in (usually 128 to 256 bytes).  You can write $FF to $F0, then $F0 to $80, then $80 to $00, as these all only involve turning 1 bits into 0 bits, but if you try to write from a $00 to a $01, then it will not work, at least not on any part I've ever used, as that involves turning a 0 bit into a 1 bit.   All of the parts I've seen, if you want to modify a single memory location (if the write involves turning a 0 bit into a 1 bit), they require you to read the block of data into your CPU, modify it there, erase the block, then write the entire block data back into the chip.  I've seen some parts that have an on-chip RAM buffer that would let you read the block into this RAM buffer with one command, modify the RAM buffer with a single byte write, erase the block, then write the RAM buffer back to the chip, which is a lot faster than having to do this yourself with your CPU memory, but it still required the block erase and that block erase still counted towards your maximum number of erase cycles.  I have not seen a chip that allowed completely random writes at the byte level before short of a static ram with battery backup.<div><br></div><div>If you have an i2c part that doesn't work like this, then I would be very interested in knowing the part number and seeing a link to the data sheet.  Such a part would make using these sorts of devices much easier, but to date I have never seen one.</div><div><br></div><div>Jeff</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 3, 2023 at 10:53 AM Bo Berglund via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org">fpc-pascal@lists.freepascal.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 3 Apr 2023 08:42:12 -0400, "Jeffrey A. Wormsley via fpc-pascal"<br>
<<a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">fpc-pascal@lists.freepascal.org</a>> wrote:<br>
<br>
>><br>
>> i2c_read_reg works too inasmuch as it does not error out, but it returns FF<br>
>> whatever addres I read like the i2c-tools command does.<br>
>> I am not sure that it is correct though...<br>
>><br>
><br>
>Yes this is expected, as eeproms erase to $FF.  You can write to the same<br>
>byte as many times as you want, as long as you only change 1 bits to 0<br>
>bits.  If you must change a 0 bit to a 1 bit, you have to erase back to $FF<br>
>first.  Be aware that erase means erasing the entire page, and not just a<br>
>single byte.  This is where things like "wear leveling" come into play,<br>
>because a page can only be erased a limited number of times (it used to be<br>
>around 10,000, but maybe newer devices have extended this).  How you manage<br>
>writes to eeprom can be tricky, best to use them for things that don't<br>
>change very often, such as configuration data.<br>
><br>
>Jeff<br>
><br>
<br>
This is incorrect!<br>
The EEPROM I am talking about is a small 8-pin chip specifically used in IoT<br>
devices to save non-volatile data and these devices are r/w on single bytes.<br>
<br>
I have just tested it by executing command line commands to write a set of data<br>
to a specific address and then read it back and verified that it was there.<br>
Then I repeated the process for the same addresses but different data.<br>
Readback again showed only the new data correctly.<br>
<br>
What you are talking about might be certain microcontrollers which simulate an<br>
EEPROM memory in their flash program memory data. That flash is commonly<br>
erasable only for full pages. Not the case here...<br>
<br>
I am working on using the FreePascal GitHub code and expanding it into a class I<br>
can use in my RPi4 project. Since I want to generalize it as much as possible it<br>
takes a few more hours than I thought...<br>
<br>
<br>
-- <br>
Bo Berglund<br>
Developer in Sweden<br>
<br>
_______________________________________________<br>
fpc-pascal maillist  -  <a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">fpc-pascal@lists.freepascal.org</a><br>
<a href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal" rel="noreferrer" target="_blank">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal</a><br>
</blockquote></div>