Which I2C library

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

for the ATmega32 would people recommend? Using WinAVR.

Thanks
davef

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But what has mega32 to do with I2C lib?
And if you are only going to select a complier based on its I2C lib what is going through your mind?

Keep it simple it will not bite as hard

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the question is which I2c library for an ATmege32 that compiles using winAVR would people recomend, like avr-lib or something.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have struggled with AVRlib for the past month (on and off), trying to talk to a AT24C64 consistently.

I can talk to the DS1307 RTC OK, but appear to have problems with "timing issues" or ?? when doing multiple writes to an external EEPROM.

Have people generally had good results using Peter Fleury's I2C library or is there something else around that is reasonably "bulletproof"??

I only mentioned the ATmega32 because that is what I am using . . . so looking for a HW I2C implementation.

Thank you

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are using I2C hardware then why the need for a "library"? Just program the registers as documented in the datasheet. You only really need library support if you are going to bit-bang pins to do a soft-I2C where it's probably easier to inherit pre-written stuff like AVRlib than to re-invent the wheel.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff,

I thought these I2C libraries (AVRlib and Peter Fleury's) were there to help relatively inexperienced programmers like me deal with complex issues, like I2C communication.

Don't these libraries just make it easier to talk to the TWI hardware in the uP? Also, I understood that "software I2C libraries" were for parts that did not have the in-built TWI hardware.

I am trying to talk to a AT24C64 (2 byte memory addressing). I have only just "discovered" the twi library in AVRlibc, which seems to deal with the apparently complex issue of talking to I2C EEPROMS with 2 byte addressing.

Would you still suggest that I just figure it out from the datasheets? At least, I might end up with a better idea of what is going on in the hardware.

Thanks for your response,
Cheers

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davef wrote:
Would you still suggest that I just figure it out from the datasheets? At least, I might end up with a better idea of what is going on in the hardware.

That's exactly why I'd figure it out from the datasheets but if I was in a real hurry to get something implemented I guess I would consider using a 3rd party library - but only once I'd got guarantees from three other people that it works just fine on the chip I intend to use (and I can always go back and ask them the "why isn't it working?" question when it doesn't! ;) )

I'm sure AVRlib works just fine but you might spend as long working out how to use it in your application as you would doing the thing from the ground up in which case you'd understand every last bit and byte of the implementation.

Cliff ("the luddite")

BTW in AVRlib I guess you already studied avrlib\examples\i2c\i2ctest.c ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Cliff.

Have tried i2ctest.c and it works OK. Problem seems to be doing a lot of I2C communication.

That was my main aim was to find "3 people who had success using some library to talk to the 64K EEPROMS". Then I would know for sure the problems I am having were all due to my use of them!

I'll read more and try to get to the bottom of this.

Cheers,
davef

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi davef et al.
You are correct that there is an issue in the AVR-lib I2C support that sometimes causes a bus lockup or CPU hang. The problem seems related to bus errors and unexpected result codes showing up in the HW I2C state machine. I don't mean to say that I think the problem is HW related, but rather that the AVR-lib i2c.c library does an insufficient job of handling (unexpected) bus errors.

The problem has remained hidden for some time because it shows up only when communicating in certain patterns, and when sending lots of back-to-back I2C transmissions.

Anyway, I have a few improvements (better error handling) that eliminate the problem in many cases. I'll try to get them into AVR-lib very soon (next week or two). Despite the fix, we still don't understand why the I2C hardware is indicating bus errors at a frequent rate during busy single-master communication. Everything looks good when watching the bus with a passive I2C sniffer and/or and oscilloscope.

If I figure out what's really going on, I'll mention it in the AVR-lib release notes.

cheers,
-Pascal

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pascal,

Wasn't aware there was a problem with the AVRlib I2C library.

I swapped in Peter Fleury's I2C library and got it performing OK. Seem to be able to do 8192 individual requests to the EEPROM without any problems. I will move to doing sequencial 32 byte page writes later.

I'll keep an eye on the AVR-lib release notes.

Thanks for coming back to me and for the work you have done on AVR-lib.

Cheers,
davef

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why has the origonal question been changed to remove the I2C part?????? Or have I lost the plot?

Keep it simple it will not bite as hard