Netduino home hardware projects downloads community

Jump to content


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.
Photo

Help needed with I2C EEPROM


  • Please log in to reply
41 replies to this topic

#21 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 26 November 2010 - 01:40 PM

http://www.atmel.com...nts/doc5297.pdf

And tell me if this EEPROM module would work with the stock firmware?

Random and Sequential reads will not work, because they require Repeated Start, other operations should work fine with the stock firmware.

Charles, I replied to your PM, but it seems the board messaging system might not work, as indicated by the last point in this post.

#22 Omar (OZ)

Omar (OZ)

    Advanced Member

  • Members
  • PipPipPip
  • 564 posts

Posted 26 November 2010 - 02:02 PM

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.

Thanks

#23 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 26 November 2010 - 02:31 PM

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... Posted Image

#24 Omar (OZ)

Omar (OZ)

    Advanced Member

  • Members
  • PipPipPip
  • 564 posts

Posted 26 November 2010 - 03:02 PM

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.

#25 Charles

Charles

    Advanced Member

  • Members
  • PipPipPip
  • 192 posts

Posted 27 November 2010 - 01:53 PM

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?

#26 Omar (OZ)

Omar (OZ)

    Advanced Member

  • Members
  • PipPipPip
  • 564 posts

Posted 27 November 2010 - 02:04 PM

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... Posted Image

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.

#27 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 27 November 2010 - 06:16 PM

Excellent!

So it be included in the 4.1.0.6 Beta 2 I'm assuming?


We aren't adding any new features in v4.1.0.6, so it'll be a v4.1.1 build. v4.1.1 is where all the new features are going...

Chris

#28 osno

osno

    Member

  • Members
  • PipPip
  • 17 posts

Posted 27 November 2010 - 07:01 PM

Chris, any time frame on 4.1.1? CW2, is the version that's working with the EEPROMs the one that I have? Thanks, J

#29 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 27 November 2010 - 08:29 PM

Chris, any time frame on 4.1.1?


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.

Here's the latest build (not including CW2's custom classes):
http://forums.netdui...e-v411-alpha-3/

Chris

#30 Charles

Charles

    Advanced Member

  • Members
  • PipPipPip
  • 192 posts

Posted 27 November 2010 - 08:51 PM

So 4.1.1 Alpha 4 maybe? :)

#31 Charles

Charles

    Advanced Member

  • Members
  • PipPipPip
  • 192 posts

Posted 28 November 2010 - 01:15 AM

It seems that you don't know how to change the direction of the wires in Fritzing.


If you hadn't mentioned this, I might have never come across Fritzing! Thanks soooo much. It is an AWESOME tool!!!!

#32 GDSever

GDSever

    Advanced Member

  • Members
  • PipPipPip
  • 81 posts
  • LocationNewark, DE

Posted 06 December 2010 - 05:26 PM

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.

#33 osno

osno

    Member

  • Members
  • PipPip
  • 17 posts

Posted 06 December 2010 - 06:18 PM

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.

#34 GDSever

GDSever

    Advanced Member

  • Members
  • PipPipPip
  • 81 posts
  • LocationNewark, DE

Posted 06 December 2010 - 10:16 PM

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.

#35 GDSever

GDSever

    Advanced Member

  • Members
  • PipPipPip
  • 81 posts
  • LocationNewark, DE

Posted 06 December 2010 - 11:50 PM

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.

Attached Files



#36 osno

osno

    Member

  • Members
  • PipPip
  • 17 posts

Posted 07 December 2010 - 12:05 AM

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!!

#37 osno

osno

    Member

  • Members
  • PipPip
  • 17 posts

Posted 03 January 2011 - 11:00 PM

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.

#38 GDSever

GDSever

    Advanced Member

  • Members
  • PipPipPip
  • 81 posts
  • LocationNewark, DE

Posted 04 January 2011 - 12:29 PM

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).

#39 osno

osno

    Member

  • Members
  • PipPip
  • 17 posts

Posted 04 January 2011 - 12:37 PM

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!

#40 GDSever

GDSever

    Advanced Member

  • Members
  • PipPipPip
  • 81 posts
  • LocationNewark, DE

Posted 04 January 2011 - 12:46 PM

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.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.