Hi Everyone,
i am trying to learn the basics of I2C communications.
So i bought an eeprom 24LC512 and connected it to the arduino uno r3.
First i used the resistors and then i tried to leave them out...
I didnt had 4k7 resistors so i used 2 10k instead and put them parallel => 5k...
So far so good, but the i tried to access the eeprom, didnt work!
The i used the following I2C Scanner and it didnt even find one i2c device!
#include <Wire.h>
void setup()
{
Wire.begin();
Serial.begin(9600);
while (!Serial); // Leonardo: wait for serial monitor
Serial.println("\nI2C Scanner");
}
void loop()
{
byte error, address;
int nDevices;
Serial.println("Scanning...");
nDevices = 0;
for(address = 1; address < 255; address++ )
{
// The i2c_scanner uses the return value of
// the Write.endTransmisstion to see if
// a device did acknowledge to the address.
Wire.beginTransmission(address);
error = Wire.endTransmission();
if (error == 0)
{
Serial.print("I2C device found at address 0x");
if (address<16)
Serial.print("0");
Serial.print(address,HEX);
Serial.println(" !");
nDevices++;
}
else if (error==4)
{
Serial.print("Unknow error at address 0x");
if (address<16)
Serial.print("0");
Serial.println(address,HEX);
}
delay(100);
}
if (nDevices == 0)
Serial.println("No I2C devices found\n");
else
Serial.println("done\n");
delay(5000); // wait 5 seconds for next scan
}
But i am doing wrong? I googled a litte bit, it seems that the Wire Library does has a few issues sometimes!? Is this the reason or am i doing something else wrong?
Thanks 
Surely you must include the I2_EEPROM library
Thanks for your reply 
But isnt the I2C Scanner independet of the client device type.
I mean it should find....
It's quite a while since I used the 24LC512 but take a look at this website - I hope this helps
Hey, I use the 24Cxxx family EEPROMs very extensively in my projects.
Give me a few minutes and I'll happily draw up a quick schematic.
Edit: there you go. I use 2.2k, but 5k should do it, as well.
There is be no need for a dedicated library. In fact, I recommend not using one until you understand what you're actually up to with the device so you can understand what the library is simplifying for you.
Okay i reassembled my curcuit the way you showed it
I went a little bit lower and used a 2k Ohm now, but the result does stay the same 
I dont have an oszilioskop just a multimeter for finding a mistake....
Is it a software issues in the libraries or is the chip broken?
It's not likely to be a software issue, as I've run the i2c scanner on one of my projects just to see if I was going insane.
If you don't mind, take some pictures of your wiring, including breadboard. The LC series from microchip is a pretty robust chip, so I'd also have a hard time believing it's blown (though it is possible.)
I attached a few pictures of my circuit from different angles.
I think i wired everything correct and i had a second eeprom so i replaced it with a new one, but still not working
I have a rush repair on my bench and two engineering projects that just got approved, so I can't go in to too much detail looking at what's going on. We can continue this in PM, though.
That said, are you sure that breadboard's power rails carry right through? Have you measured that you actually get a resting 5 on both the SDA and SCL pins? In the interest of "because why not" have you tried swapping the SDA and SCL lines on the Ardy?
Keep trying. In the meantime, I'll also try to find some time to write some test sketches for you, maybe we can verify what's going on.
I'd be willing to guess that it's a wiring problem before a hardware, but we'll see.
I tested a different I2C library with native scan function. It also didnt found a device, but when i removed the pull ups, the library scan function wrote "There is a problem with the bus, could not complete scan" so i think we can assume that the pull up part is assembled in the right way! Which als could confirm with my multimeter
The Power rails are also ok and carrying the right level..
Also the whole left side is set to ground and on the right side of the chip v and gnd are also right, i tested this with my multimeter.
I am a beginner it also can be a very stupid mistake of which no one has thought about yet 
The chip is also in the right direction, i checked the datasheet for it...
Swapping SDL and SCL also didnt help
Concentrate on your engineeering projekt
Concentrate? Why would I do that? It's just work...
Removing the pull ups would cause it to fail because the bus would float a bit and wouldn't snap back to a voltage high when released, for lack of wanting to get in to a full on explanation.
If you're certain that it's wired properly, it's certainly possible that the chip is pooched. I'd recommend trying a different chip. It doesn't have to be a microchip version, or even an EEPROM, just any 5V i2c compatible device.
I tried an IO Port Expander MCP23017 with the same pull ups, it does work perfectly!
As i mentioned above i tried two eeproms, both broken? I mean can be possible, but two!?, which are brand new
greets and all the best from germany
Well, assuming they weren't accidentally wired in with reverse polarity on Vdd and Vss, then they shouldn't be damaged. They could also have been static shocked, but that doesn't have to result in destruction.
Wire it up with all three address pins to ground and run this code:
#include <Wire.h>
void setup(){
Wire.begin();
Serial.begin(9600);
Serial.print("Wire response on 0x50: ");
Wire.beginTransmission(0x50);
Serial.println(Wire.endTransmission());
}
void loop(){
}
Then let me know what the exit code is.
I complety reassembled it with new cables etc.
And it does work now! Even both eeproms do there job but, one thing is weird it does find two adresses for each chip:
The First is 0x50 which i expect and the second ist 0xD0. Both adresses have in common that one bit is different, what does it mean?
And what is the highest byte i can adress of the 24LC512, first of all i am not sure of the capacity is it 512 kb = 512000bytes or 512kbit = 64000 bytes?
Do i need a uint32_t do adress all bytes?
Thanks so far for your patience and help
I2C addresses are 7-bit plus a R/W bit. The R/W bit is handled via registers, so we don't worry about it.
The 4-bit device address code for the EEPROMs is 1010 and then we put the three hardware address bits, resulting in 1010(A2)(A1)(A0). When they're all tied to GND, that becomes 0b1010000. Translated to 8-bit, that's 0101 0000. 0101 is a 5 in hex and 0000 is... well, 0. So when we tie A0 to Vcc, it becomes a 1, and we turn in to 0101 0001, or 0x51. When the micro adds in the R/W bit, the address is shifted 1 bit to the left, which turns it back in to (device code)(3-bit address)(R/W).
The upshot of all that is addresses really can implement by 1.
As for the peculiarity of why it would find 0xD0, that's likely because it's scanning too high a number and the highest bit is being rejected when it shifts the bits. The highest legal 7-bit i2c address possible is 0x7F. 0x50 and 0xD0 are the same after shifting the bits.
As for the 512 version of that chip, you have 65,536 bytes accessible. You can either do this with an unsigned integer (being certain to send the high byte first) or my personal favourite of two chars, which are actually uint8_t types. It makes it easier for me to handle, as I arbitrarily split up the memory in to 256 pages of 256 bytes. (Worth remembering, here, is you can't write more than 128 bytes at time, but I've only had that problem once, since 128 bytes is a lot of SRAM to take up in the micro.)
