I noticed you put the part number in the original email. 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.
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. Jeff On Mon, Apr 3, 2023 at 8:42 AM Jeffrey A. Wormsley <daw...@gmail.com> 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 > > On Sun, Apr 2, 2023 at 3:30 PM Bo Berglund via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > >> On Sun, 2 Apr 2023 07:31:43 +0200, Christo Crause via fpc-pascal >> <fpc-pascal@lists.freepascal.org> wrote: >> >> >On Sat, Apr 1, 2023 at 9:57?PM Bo Berglund via fpc-pascal < >> >fpc-pascal@lists.freepascal.org> wrote: >> > >> >> Question: >> >> Can I use Linux file system commands to read/write the data on the i2c >> >> EEPROM >> >> memory device and if so how from fpc? >> >> >> > >> >To some extent it is possible to handle i2c transactions as file >> read/write >> >operations, but some ioctl calls are required to configure e.g. the >> device >> >address [1]. Take note that only a subset of i2c functionality is >> available >> >using read/write calls. Lazi2cdev [2] uses this approach. >> > >> >For finer control over the i2c transactions (for example combined >> >write/read transactions) low level ioctl calls are available in Linux. I >> >wrote an i2c class [3] using this approach. >> > >> >1. https://www.kernel.org/doc/html/latest/i2c/dev-interface.html >> >2. https://github.com/laz2wiringpi/lazI2cdev/blob/master/i2cdev_base.pas >> >3. https://github.com/ccrause/rpiplc_pas/blob/main/native/i2c.pas >> >> Hello again! >> >> I have now tested the two demos in github [3] and they seem to work OK. >> >> The i2cscan works and shows exactly the same as sudo i2cdetect -y 1 does >> from >> the i2c-tools package I installed via apt. >> >> 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, for that I need to create an >> i2c_write >> demo app first so I can write values at different locations and read them >> back. >> The EEPROM has until now not been used so it is in its factory state with >> no >> data. >> >> Is there a reason that there is no i2c_write_reg demo in the github >> package? >> >> I will try to write one so I can test that as well... >> >> >> -- >> 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
