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.

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.

Jeff

On Mon, Apr 3, 2023 at 10:53 AM Bo Berglund via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> On Mon, 3 Apr 2023 08:42:12 -0400, "Jeffrey A. Wormsley via fpc-pascal"
> <fpc-pascal@lists.freepascal.org> wrote:
>
> >>
> >> i2c_read_reg works too inasmuch as it does not error out, but it
> returns FF
> >> whatever addres I read like the i2c-tools command does.
> >> I am not sure that it is correct though...
> >>
> >
> >Yes this is expected, as eeproms erase to $FF.  You can write to the same
> >byte as many times as you want, as long as you only change 1 bits to 0
> >bits.  If you must change a 0 bit to a 1 bit, you have to erase back to
> $FF
> >first.  Be aware that erase means erasing the entire page, and not just a
> >single byte.  This is where things like "wear leveling" come into play,
> >because a page can only be erased a limited number of times (it used to be
> >around 10,000, but maybe newer devices have extended this).  How you
> manage
> >writes to eeprom can be tricky, best to use them for things that don't
> >change very often, such as configuration data.
> >
> >Jeff
> >
>
> This is incorrect!
> The EEPROM I am talking about is a small 8-pin chip specifically used in
> IoT
> devices to save non-volatile data and these devices are r/w on single
> bytes.
>
> I have just tested it by executing command line commands to write a set of
> data
> to a specific address and then read it back and verified that it was there.
> Then I repeated the process for the same addresses but different data.
> Readback again showed only the new data correctly.
>
> What you are talking about might be certain microcontrollers which
> simulate an
> EEPROM memory in their flash program memory data. That flash is commonly
> erasable only for full pages. Not the case here...
>
> I am working on using the FreePascal GitHub code and expanding it into a
> class I
> can use in my RPi4 project. Since I want to generalize it as much as
> possible it
> takes a few more hours than I thought...
>
>
> --
> Bo Berglund
> Developer in Sweden
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to