The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
Oz, you accidentally flipped the EEPROM chip in your schematic. Additionally, if your breadboard is same as mine, there is a missing connection between bottom and top ground lines; and I would rather connect the pull-up resistors to 3.3 V (VCC).
I flipped the 8 pin one right? (4 pins each side)... Because the whole image is upside down so the 16pin chip is right I think.
Also the resistors go to the 5V because in the original schematic they do, is 3.3V better? and if so it would be better if the original schematic makes that change too, to prevent any confusions.
I flipped the 8 pin one right? (4 pins each side)...
Yes, if you look at it so the orientation notch is at the top, address lines and ground should be on the left side, VCC and data lines on the right.
Also the resistors go to the 5V because in the original schematic they do, is 3.3V better? and if so it would be better if the original schematic makes that change too, to prevent any confusions.
Well, I2C bus is not limited to a defined voltage, but its logic voltage levels depend on it - also ICs can have their logic voltage levels based on their supply voltage, so the levels will not match when the supply voltages differ. It is just easier to use single supply voltage; if it works, leave it as it is...
Oz, you accidentally flipped the EEPROM chip in your schematic. Additionally, if your breadboard is same as mine, there is a missing connection between bottom and top ground lines; and I would rather connect the pull-up resistors to 3.3 V (VCC).
The original schematic has the 5V going to the resistors, is 3.3V better? I don't think its a good Idea to change that unless the original changes it too so people don't get confused.
I have updated version of I2CDevice extension firmware that supports multi-byte Internal Address, which is required by serial EEPROMs. I have verified that the code works with 24LC64 and 24LC256 Microchip memories, I can publish it for testing if there is enough interest - I postponed it for now, because Chris Walker offered to include the workaround in official 4.1.0.6 version, that also contains PWM code.
Excellent!
So it be included in the 4.1.0.6 Beta 2 I'm assuming?
Yes, if you look at it so the orientation notch is at the top, address lines and ground should be on the left side, VCC and data lines on the right.
Well, I2C bus is not limited to a defined voltage, but its logic voltage levels depend on it - also ICs can have their logic voltage levels based on their supply voltage, so the levels will not match when the supply voltages differ. It is just easier to use single supply voltage; if it works, leave it as it is...
I'll make the changes... I posted a reply twice because the reply went to the second page and I thought it didnt go through >.> so yeah I' update that schematic, thanks for the help.
We're hoping to have the final v4.1.1 release out after the holidays. In the meantime, we're posting alphas and betas over in the Netduino (Beta) forum.
Not sure if you all are still interested, but I did get a class working for both a 24LC16B and a 24LC256 that uses the standard 4.1.0.5 firmware. It's only regular reads / writes, but I've had it write and read 10 consecutive bytes at a time without problem. I haven't tried (nor have a need for) random / sequential reads, so you're on your own for that.
If you are interested, I could post code and a fritzing diagram.
Not sure if you all are still interested, but I did get a class working for both a 24LC16B and a 24LC256 that uses the standard 4.1.0.5 firmware. It's only regular reads / writes, but I've had it write and read 10 consecutive bytes at a time without problem. I haven't tried (nor have a need for) random / sequential reads, so you're on your own for that.
If you are interested, I could post code and a fritzing diagram.
I'm interested . I'm away from home for a few days so I won't be able to provide feedback, but I sure would love to try when I get back.
I'm interested . I'm away from home for a few days so I won't be able to provide feedback, but I sure would love to try when I get back.
I will clean up the code a little and post it tomorrow. I am in the process of adding a "WriteString" / "ReadString" combination, and need to test that out too before I post it. I guess I'll put it in the projects section? Or maybe I should just post it here on this thread...
Also, I'm not using the I2CBus approach - hopefully that's not a problem.
So here is the class, fritzing diagram, and example output for the I2C EEPROM classes. There is also some extraneous code in the project for some MCP23008 and MCP23016 Digital I/O expander chips that I'm working on, so ignore those for now (they are a work-in-progress).
The example program should be relatively self-explanatory. Let me know if you've got questions or suggestions.
So here is the class, fritzing diagram, and example output for the I2C EEPROM classes. There is also some extraneous code in the project for some MCP23008 and MCP23016 Digital I/O expander chips that I'm working on, so ignore those for now (they are a work-in-progress).
The example program should be relatively self-explanatory. Let me know if you've got questions or suggestions.
Very cool. It's actually similar to my first try. I'll have to try it in a week or so when I get home. Thanks!!
It took me quite a while to get back to my Netduino... and I must say that EEPROM code works amazingly well!! Thanks for that.
No problem... glad it works for you. I recently realized the maximum address is wrong for a 24LC256 (should be 0x7FFF, not 0xFFFF). I also picked up a 24LC512 so I'll work that into the EEPROM classes as well once I've tested it out (although I don't anticipate any issues).
One thing that bugs me, though, is the amount of repeated code in the xx16 and xx256 classes.
If it where me, I'll make all the addresses an int, and then have an AddressByteCount property or something that will be 1 for the xx16 and 2 for the xx256, and have the base class handle the conversion (which is simply a loop making a >> 8 & 0xFF). All the Read and Write methods would be on the base class. Using that and the max address you can easily throw an exception if the address is wrong (which you already do anyway). Also, you can have all the overloads in the derived classes, but they'll look like this:
public int WriteString(byte writeAddress, string value)
{
return WriteString((int)writeAddress, value);
}
You can even make the base class methods protected if you don't want users of the code to have the liability of an exception (except for the high byte of the xx256, where it will happen anyway).
Anyway, thanks again!
One thing that bugs me, though, is the amount of repeated code in the xx16 and xx256 classes.
It bugs me too. I'll see if I can do something about that - I was just trying to get something functional, but it certainly could use some dressing up.