On Sun, 02 Apr 2023 15:07:48 -0400, Dennis Lee Bieber via fpc-pascal <fpc-pascal@lists.freepascal.org> wrote:
>On Sun, 02 Apr 2023 16:16:46 +0200, Bo Berglund via fpc-pascal ><fpc-pascal@lists.freepascal.org> declaimed >the following: > > >> >>---------------------------------------------------------------- >>Byte Write ><SNIP> >>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 ><SNIP> >>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). >>------------------------------------------------------------------ >> > This sounds suspiciously like one is expected (or is able) to write >multiple bytes /within/ the "page" via multiple address/data operations, >and have all those bytes "burned" into the memory using a single "stop" >operation. > Exactly, you specify *start* as a 2-byte address (pageno/offset) and then you output as many sequential bytes as you need to write in the command. All will wind up in the 256 byte on-chip write buffer until the stop arrives and then it will be dumped into memory. If the buffer address increments past 0xff it will wrap back into 0x0 in the buffer for following bytes and this is probably something you must not allow... So an application using i2c must check the arguments for this page transition case and either error out or spawn a second operation for the following page in EEPROM to handle the excess bytes. I have not yet tested this case because the github project does not have an i2c_write demo... Must write one myself. -- Bo Berglund Developer in Sweden _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal