<div dir="ltr">I noticed you put the part number in the original email.<div><br></div><div>Interestingly, the data sheet mentions 64 byte pages, and 1,000,000 erase cycles, but does not mention the need to erase a page before writing.  So perhaps this part does not have that restriction.</div><div><br></div><div>If you're making a library specifically for this part, then I guess you don't have to worry about this.  If you're making a library for generic eeprom support, I think you might want to consider that not all parts behave this way.</div><div><br></div><div>Jeff</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 3, 2023 at 8:42 AM Jeffrey A. Wormsley <<a href="mailto:daworm@gmail.com">daworm@gmail.com</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"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>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.</div><div><br></div><div>Jeff</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 2, 2023 at 3:30 PM Bo Berglund via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">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 Sun, 2 Apr 2023 07:31:43 +0200, Christo Crause via fpc-pascal<br>
<<a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">fpc-pascal@lists.freepascal.org</a>> wrote:<br>
<br>
>On Sat, Apr 1, 2023 at 9:57?PM Bo Berglund via fpc-pascal <<br>
><a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">fpc-pascal@lists.freepascal.org</a>> wrote:<br>
><br>
>> Question:<br>
>> Can I use Linux file system commands to read/write the data on the i2c<br>
>> EEPROM<br>
>> memory device and if so how from fpc?<br>
>><br>
><br>
>To some extent it is possible to handle i2c transactions as file read/write<br>
>operations, but some ioctl calls are required to configure e.g. the device<br>
>address [1]. Take note that only a subset of i2c functionality is available<br>
>using read/write calls. Lazi2cdev [2] uses this approach.<br>
><br>
>For finer control over the i2c transactions (for example combined<br>
>write/read transactions) low level ioctl calls are available in Linux.  I<br>
>wrote an i2c class [3] using this approach.<br>
><br>
>1. <a href="https://www.kernel.org/doc/html/latest/i2c/dev-interface.html" rel="noreferrer" target="_blank">https://www.kernel.org/doc/html/latest/i2c/dev-interface.html</a><br>
>2. <a href="https://github.com/laz2wiringpi/lazI2cdev/blob/master/i2cdev_base.pas" rel="noreferrer" target="_blank">https://github.com/laz2wiringpi/lazI2cdev/blob/master/i2cdev_base.pas</a><br>
>3. <a href="https://github.com/ccrause/rpiplc_pas/blob/main/native/i2c.pas" rel="noreferrer" target="_blank">https://github.com/ccrause/rpiplc_pas/blob/main/native/i2c.pas</a><br>
<br>
Hello again!<br>
<br>
I have now tested the two demos in github [3] and they seem to work OK.<br>
<br>
The i2cscan works and shows exactly the same as sudo i2cdetect -y 1 does from<br>
the i2c-tools package I installed via apt.<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, for that I need to create an i2c_write<br>
demo app first so I can write values at different locations and read them back.<br>
The EEPROM has until now not been used so it is in its factory state with no<br>
data.<br>
<br>
Is there a reason that there is no i2c_write_reg demo in the github package?<br>
<br>
I will try to write one so I can test that as well...<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>
</blockquote></div>