I²C interface

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

I am trying to drive the character LCD through I²C interface. I have problem initializing the I²C in ATMEG64L. I am using CodeVisionAVR(HPinfotec) compiler . Does somebody has any initialization code. Any other help!!!

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

Have you checked out Atmel application notes?
http://www.atmel.com/dyn/products/app_notes.asp?family_id=607

AVR155: Accessing I2C LCD Display Using the AVR 2-Wire Serial Interface
AVR315: Using the TWI module as I2C master

Thomas

pycrc -- a free CRC calculator and C source code generator

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

After you've checked the app notes, check to be sure you have external pull-up resistors on the TWI bus lines. They're important.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

I am sure that the CV library code will drive your display using any port pins. You must have the external 4k7 pull-up resistors.

Any initialisation commands required are going to be in the device data sheet. You do not say which display.

David.

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

I have TWI working using the example code from avr-libc:
http://www.nongnu.org/avr-libc/u...

Due to a PCB error we have no pullups, didn't expect it to work but I found it works fine at over 300kbps using the ATmega644p internal pullups - that's on a sample of about 10 boards. I'm hoping that means at 100kbps it will be reliable.

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

Check it over temperature!

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

ka7ehk wrote:
Check it over temperature!

Hmmm, good point Jim!

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

grummund wrote:
I have TWI working using the example code from avr-libc:
http://www.nongnu.org/avr-libc/u...

Due to a PCB error we have no pullups, didn't expect it to work but I found it works fine at over 300kbps using the ATmega644p internal pullups - that's on a sample of about 10 boards. I'm hoping that means at 100kbps it will be reliable.

There have been several threads on this. You are simply flouting the i2c specification. Whether it works or not is irrelevant.

You will just have to hand-work your PCBs.

David.

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

Generally I agree that there should be external pullup resistors. However ATmega32 and ATmega324P datasheets have these lines:

Quote:
Overview of the TWI Module:
SCL and SDA Pins:
Note that the internal pull-ups in the AVR pads can be enabled by setting the PORT bits corresponding to the SCL and SDA pins, as explained in the I/O Port section. The internal pull-ups can in some systems eliminate the need for external ones.

Assuming the worst case values from the electrical characteristics: pullup resistance = 50kOhm, pin capacitance = 10pF.
If communication speed is <= 100kHz, then bus capacitance can be at most 1000ns/50kOhm = 20pF. This means that if wiring capacitance is negligible, there can be two devices connected to the bus.

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

Would you sell a product that depends on 10pF AVR pin capacitance and zero PCB track capacitance and device 10pF pin capacitance ?

David.

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

No. For that I would need rev. B of the layout. But those calculations show that it probably would do as a proto.

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

I am trying to use the built-in routine for I²C codevision. I initialize the display for ATMEG64L as
#asm
.equ __i2c_port=0x12 ;PORTD
.equ __sda_bit=1
.equ __scl_bit=0
#endasm
#include

when I use i2c_init() routine my SCL signal goes low and SDA still high. Then I use the routine i2c_start() then SCL signal still low and SDA signal goes from High to low that violates the start condition of I2c initialization. Is there anybody who has gone through such kind of situation? My bit setting of SCL&SDA is okay when I look at the datasheet of ATMEG64.

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

I'm not an I2C protocol expert, so I cannot comment directly on the "violation". I can only say that I've used the CV system on a couple of apps to interface to different devices, and it communicates reliably.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I just interface the device with CV system and its working perfectly.

Thanks everybody for the valuable comments.

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

And for extra margin, just run the SPI a bit slower. Sheesh; why's everyone in such a hurry anyway? It's just a "few lines by few characters" display; I bet you could drop your transfer rate to 20Kbits/sec and still have a comfortable update rate (4 lines x 40 chars x 10bits/char x 10refreshes/sec ~= 16Kbits/sec).

Here at work, we have several products that take some pretty big liberties with IIC communications (large line capacitances, hot-plugged components, weak pullups, etc), with (knock cellulose) no ill effect

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

a_farhan1 wrote:
I am trying to use the built-in routine for I²C codevision. I initialize the display for ATMEG64L as
#asm
.equ __i2c_port=0x12 ;PORTD
.equ __sda_bit=1
.equ __scl_bit=0
#endasm
#include

when I use i2c_init() routine my SCL signal goes low and SDA still high. Then I use the routine i2c_start() then SCL signal still low and SDA signal goes from High to low that violates the start condition of I2c initialization. Is there anybody who has gone through such kind of situation? My bit setting of SCL&SDA is okay when I look at the datasheet of ATMEG64.

Are you sure about this ?

When you call i2c_init() it sets up the bus, but does not do anything until you call i2c_start().

I suspect that you have chosen to write directly to the the DDRx of your i2c PORTx.

Please post your call sequence.

David.