[riot-notifications] [RIOT-OS/RIOT] Driver for AT24CXXX EEPROM (#11929)

MrKevinWeiss notifications at github.com
Tue Jul 30 10:13:09 CEST 2019

MrKevinWeiss commented on this pull request.

> +
+    _position_to_address_words(buffer, pos);
+    buffer[sizeof(buffer) - 1] = data;
+    int check;
+    check = i2c_write_bytes(dev->params.i2c, dev->params.dev_addr, buffer,
+                            sizeof(buffer), 0);
+    DEBUG("write_byte check: %d\n", check);
+    if (check < 0) {
+        //check is a negative errno value
+        return check;
+    }
+    xtimer_usleep(AT24CXXX_MAX_WRITE_CYCLE * US_PER_MS);

Quite a few devices will read one byte automatically if the address is ACKed, this means you cannot reliably only poll the address.  I believe this is only for the read as I don't remember having these problems in the write address.  I also _think_ you should not be allowed to write or read regs with length 0 though.

If you wanted to only exit after everything is free (so blocking) then I think you can just  try to read one byte `i2c_read_byte()` and discard it (or even compare to make sure the bytes are written). I think it should actually give you either a address nack or a data nack...  Here is the section.

> ACKNOWLEDGE POLLING: Once the internally-timed write cycle has started and the
EEPROM inputs are disabled, acknowledge polling can be initiated. This involves sending a
start condition followed by the device address word. The read/write bit is representative of the
operation desired. Only if the internal write cycle has completed will the EEPROM respond
with a zero, allowing the read or write sequence to continue.

The other option is, in the eeprom_write_byte/s have your retry if NACKed for 5ms.  If you do this you may also need to retry the read_bytes as I think it should also NACK a read command if still writing. This would mean you only poll if it is waiting and the poll wouldn't be too power hungry anyways since it would be a max of 5 polls.

The i2c error code should not be `-ETIMEDOUT` though.  It should be a NACK.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190730/09e391e6/attachment-0001.htm>

More information about the notifications mailing list