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

Marian Buschsieweke notifications at github.com
Mon Jul 29 23:34:07 CEST 2019


maribu 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);

This seems to be a power consumption vs access time tradeoff to me. Continuously polling the I2C bus for up to 5 ms will keep the bus and the MCU busy, but could potentially lead to faster access times (when the write cycle is completed faster than the 5ms).

Also, I remeber from writing the `i2c_scan` shell command that "pinging" the device does not work reliable on all I2C hardware implementations. (If I remeber correctly, some MCUs required to actually read or write one byte of data, as the subsequent transfer always failed when only the address but now data was transferred.) So just waiting might also be more reliable? @MrKevinWeiss has superior insight into all the gory details due to his testing effort (afaik), maybe he can confirm or dismiss my doubt?

If waiting without polling will "win", I'd suggest to release the bus before the wait and acquire it again afterwards. That should allow the MCU to power down the bus or let other drivers access the potentially shared bus. (E.g. in I2C standard speed (100kbps) about 60 bytes of data could be transferred within the 5ms, so this can be considered as rather long.)

I'd personally prefer the worst case wait (with bus powered down / available for other tasks) over faster access time.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/11929#discussion_r308447561
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190729/95559f30/attachment.htm>


More information about the notifications mailing list