[fpc-pascal] FPC/Lazarus on RPi4 - How to read/write I2C connected EEPROM?

[Bo Berglund]

>On Mon, Apr 3, 2023 at 10:53?AM Bo Berglund via fpc-pascal <
>fpc-pascal at lists.freepascal.org> wrote:
>
>> On Mon, 3 Apr 2023 08:42:12 -0400, "Jeffrey A. Wormsley via fpc-pascal"
>> <fpc-pascal at 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...
>>
On Mon, 3 Apr 2023 14:26:17 -0400, "Jeffrey A. Wormsley via fpc-pascal"
<fpc-pascal at lists.freepascal.org> wrote:

>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
>
I just tested by writing four 0x00 bytes in a row, then verifying that the
memory read shows these, then writing other data and again verifying that the
data is there.

All using the i2c-tools commands:

$ i2ctransfer -y 1 w6 at 0x50 0x00 0x00 0x00 0x00 0x00 0x00
$ i2ctransfer -y 1 w2 at 0x50 0x00 0x00 r8 at 0x50
0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff

$ i2ctransfer -y 1 w6 at 0x50 0x00 0x00 0x70 0x30 0x55 0x40
$ i2ctransfer -y 1 w2 at 0x50 0x00 0x00 r8 at 0x50
0x70 0x30 0x55 0x40 0xff 0xff 0xff 0xff

The part number is: CAT24C32 by ON Semiconductor (www.onsemi.com)
It is a 128 kbit (16 kbyte) part organized as 64 pages of 256 bytes.


-- 
Bo Berglund
Developer in Sweden