Go Down

Topic: External EEPROM library for 2k bits - 2M bits (Read 696 times) previous topic - next topic

Jack Christensen

I updated my external EEPROM library to work with any size EEPROM between 2k bits and 2M bits. Another user on the forum was able to test it with a 1M bit EEPROM. I've tested it with 2kb, 256kb and 2Mb. If anyone has other size EEPROMs and is so inclined, additional testing is always appreciated.

The library will write across block, page and device boundaries, it treats all EEPROMs on the bus as a single address space. I added methods to write and read single bytes and even wrote some documentation (!)

https://github.com/JChristensen/extEEPROM

robtillaart

Quick look, => decent piece of work.

Two reamrks.4
1)  the code assumes that the wire speed (TWBR) stays the same over multiple writes.
If another I2C device (e.g LCD) / library resets the bus speed, the EEPROM will be affected.

possible way to solve
Code: (dummy) [Select]

write(address, value)
{
  int prevTWBR= TWBR;
  TWBR = _TWBR;  // private var in the class

  ... // do your thing

  TWBR = prevTWBR;
}


same for other functions.

To be honest I did not implement in my own eeprom lib
- https://github.com/RobTillaart/Arduino/tree/master/libraries/I2C_EEPROM - ;)

2)
I remember the last Write in micros() to minimize write latency in a different way than you do.
You might take a look at it. - void waitEEReady(); -

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Jack Christensen

#2
Jul 22, 2014, 09:55 pm Last Edit: Jul 22, 2014, 09:57 pm by Jack Christensen Reason: 1
Thanks Rob!

My assumption regarding the bus speed was that once all I2C devices were initialized, it would not change. Is it possible/advisable to mix different speed devices on the same bus, and then change the speed on the fly to communicate with different devices? For example, a DS1307 that can only do 100kHz and an EEPROM capable of 400kHz. I would think there is some risk of confusing the slower device while the bus is running at the higher speed, even though it's not being addressed. I wonder if it might try to respond which would then result in garbage on the bus.

I do warn in the ReadMe file to place the extEEPROM.begin() call after all other I2C devices are initialized to ensure the desired bus speed is set. But the worst case scenario is just that the bus runs slower, so I didn't feel a need to do anything more.

While running at 400kHz can be a significant improvement, you're probably aware that it's nowhere near even twice as fast with EEPROMs, due to the small block sizes (Wire library 32 byte limit) and the wait times for writes.

Page write times vary between EEPROM part numbers. Datasheets for EEPROMs I have say 3, 5, and 10ms. So I used the polled method as opposed to hardcoding a delay. Still I didn't want to bombard the device with continuous polls so I poll every 0.5ms. I've also observed that page write times are often better than the datasheet specs (no real surprise there). I suppose I could drop my interval to maybe 100┬Ás. I might run some tests and also try your technique.

robtillaart

Quote
For example, a DS1307 that can only do 100kHz and an EEPROM capable of 400kHz. I would think there is some risk of confusing the slower device while the bus is running at the higher speed, even though it's not being addressed. I wonder if it might try to respond which would then result in garbage on the bus.


That is one reason why I developed the multi speed I2C scanner - http://forum.arduino.cc/index.php?topic=197360.0 - to see at what bus speed all devices still react as expected and of course if over-clocking is possible .

I never saw multiple devices react on an I2C bus (as long as addresses are unique). Think that is because the bus both has a clock and a data line. Expect the hardware in the device will just follow the clock as slave, when listening, but it is not able to respond in the right clock.  But I never did an explicit disruptive test to see what happens if I2C addresses collide.

One thing I did notice with I2C is that it seems sensitive for interrupts disturbing the clock/data lines (might be because the wire lib does not disable them?)

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)


Go Up