On Sun, 02 Apr 2023 10:23:24 +0200, 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/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 dont 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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
