Which is the first address index of an EEPROM?

Using Arduino Storage
1

I'm playing around with a bunch of i2c eeprom, writing my own read/write procedures using the Wire library. Everything works nice but now I wonder ... should I consider the first memory register address being 0 or 1?

Fact is, when I use a negative address the requestFrom() returns data anyway, it's like it's wrapping around to the end of the eeprom. I can't seem to find a clear definition about this detail.
So I don't know if after a Wire.send(1) the Wire.requestFrom(device_address, 1) will return the first eeprom address value or the second one.

I suppose the first eeprom register index should be 0 (like in arrays indexing), but I'd really like to be shure about that.

2

I suppose the first eeprom register index should be 0 (like in arrays indexing), but I'd really like to be shure about that.

Did you ever stop to think about why the first array index is 0? The index is an offset from the memory location where the first byte is stored. Logically, then, it follows that the first EEPROM address is 0.

Fact is, when I use a negative address the requestFrom() returns data anyway

But, you have no idea which data it returned. Because there are no negative EEPROM addresses, the functions that read/write EEPROM expect the address argument to be an unsigned int. When you specify a signed variable as an argument, the bits in that memory location are going to be interpreted as an unsigned value. When you store a negative value there, the bits are still interpreted as a (different) unsigned collection of bits. If the resulting address is outside the range of valid addresses, the code does something. What that something is depends on specifically which functions you are using to read EEPROM data.

3

PaulS:

I suppose the first eeprom register index should be 0 (like in arrays indexing), but I'd really like to be shure about that.

Did you ever stop to think about why the first array index is 0? The index is an offset from the memory location where the first byte is stored. Logically, then, it follows that the first EEPROM address is 0.

Ok. In fact, meanwhile, I did a few more attempts. Now things are clear.
No negative register indexes have any sense at all for eeproms. And yes, first eeprom register index is zero.
Using negative indexes, I was looking at garbage values taken from who knows where.

But I still get a read wrapping when I go past the last eeproms register index. I'm using a few 24C02 (2kbit = 2k x 8byte = 256byte). Everytime I try and read values behind the last byte I get the first eeproms memory value back. That's using subsequent Wire.requestFrom() calls; I set the initial reading index with Wire.send(0) and keep reading past the 32nd memory page.
That's interesting and maybe usefull. Anyway I have to take into account it can be done.

I'm still wondering how does Wire.available() cope when negative indexes are used, there's something I still have to investigate regarding this peculiar condition.

Thanks for the hint and the observation :slight_smile:

4

Have you looked at the header file and source code for the Wire library?
From the header file:

    void begin(uint8_t);
    void begin(int);
    void beginTransmission(uint8_t);
    void beginTransmission(int);

Which might lead you to believe that you could use negative values. But, from the source file:

void TwoWire::begin(uint8_t address)
{
  twi_setAddress(address);
  twi_attachSlaveTxEvent(onRequestService);
  twi_attachSlaveRxEvent(onReceiveService);
  begin();
}

void TwoWire::begin(int address)
{
  begin((uint8_t)address);
}

void TwoWire::beginTransmission(uint8_t address)
{
  // indicate that we are transmitting
  transmitting = 1;
  // set address of targeted slave
  txAddress = address;
  // reset tx buffer iterator vars
  txBufferIndex = 0;
  txBufferLength = 0;
}

void TwoWire::beginTransmission(int address)
{
  beginTransmission((uint8_t)address);
}

This shows that the int versions actually call the unsigned int versions, which causes havoc with negative values.

5

Have you looked at the header file and source code for the Wire library?

Actually ... no. But I will. That could only be helpfull.

It's nice to know there's people like you, that knows the source so much better than me :slight_smile:
Really, no sarcarsm here, I appreciate your comments a lot.