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

[Bo Berglund]

On Sun, 02 Apr 2023 10:23:24 +0200, Bo Berglund via fpc-pascal
<fpc-pascal at lists.freepascal.org> wrote:

>On Sun, 2 Apr 2023 07:31:43 +0200, Christo Crause via fpc-pascal
><fpc-pascal at lists.freepascal.org> wrote:
>
>>On Sat, Apr 1, 2023 at 9:57?PM Bo Berglund via fpc-pascal <
>>fpc-pascal at 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/ccrause/rpiplc_pas/blob/main/native/i2c.pas
>
>Thanks for the reply and links!
>Then I need to go the low-level way, I guess...
>
>I had hoped it would be a simpler way using OS available functions on RPi.
>
>I have used these EEPROM devices on some Microchip PIC24 projects where I had to
>do the nitty-gritty low level stuff myself including bit-banging the I2C bus...
>
>With that approach I have to *read the details* on the EEPROM datasheets to see
>how they are handled, unless of course I can port my own i2c code (Ansi-C) to
>pascal...
>
>Luckily on RPi the system is built to allow users to do low-level stuff on the
>I/O lines.

After consulting my old code and the datasheet for CAT24C128 and looking at the
links you posted I have come to the following conclusion:

1) My old code for PIC24 is too close to the silicon and I don't see how I can
use that on a Linux machine...

2) Your linked FPC unit i2c.pas looks promising to mee, I will test it.

Notes:
------
The EEPROM on the board is a 128 kbit (16 kbytes) version organized as 64 256
byte pages. The datsheet says this about a write cycle:

----------------------------------------------------------------
Byte Write
Upon receiving a Slave address with the R/W bit set to ‘0’,
the CAT24C128 will interpret the next two bytes as address
bytes. These bytes are used to initialize the internal address
counter; the 2 most significant bits are ‘don’t care’, the next
8 point to one of 256 available pages and the last 6 point to
a  location  within  a  64  byte  page.  A  byte  following  the
address bytes will be interpreted as data. The data will be
loaded into the Page Write Buffer and will eventually be
written to memory at the address specified by the 14 active
address  bits  provided  earlier.  The  CAT24C128  will
acknowledge the Slave address, address bytes and data byte.
The Master then starts the internal Write cycle by issuing a
STOP condition (Figure 6). During the internal Write cycle
(tWR), the SDA output will be tri-stated and additional Read
or Write requests will be ignored (Figure 7).
------------------------------------------------------------------

So here the sequence on the bus will contain a 2-byte address rather than a
single byte address.
This needs to be taken into consideration and I believe it *is* in the i2c.pas
unit where there are overloaded functions for byte and uint16 type addresses for
read and write, one only needs to use the correct width of the address argument
and it will be correctly chosen! :-)

3) Regarding the other unit you linked to (i2cdev_base.pas):
I see it is not really relevant to me due to the type of EEPROM I have etc, so I
will go with the i2c.pas.


I have just gotten to this reply so have not yet had time to fire up my RPi4
Lazarus on the system that has the board installed in order to test it..

I will do so shortly and report back what I found.
The plan is to store the application settings on the EEPROM along with a hashed
authentication code to unlock the application itself.

AGAIN:
I AM GRATEFUL FOR THE LINK TO THIS FPC UNIT!!!!
Hopefully it will solve my problems in using the EEPROM on the board.


-- 
Bo Berglund
Developer in Sweden