Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

I2C interface question (AVR <-> ARM)

I2C interface question (AVR <-> ARM)

2006-04-22 by Larry Barello

I am trying to interface some AVR boards to an Arm9 board (Atmel at91RM9200
@ ~60mhz).  This worked at one point but now it isn't and I am getting
stumped.

There appears to be ~200ns of delay between the SDA and SCL when generating
the START condition.  This seems too small for the AVR @ 12mhz but I can't
tell from the data sheet.  

When running my commands (SMBus master/slave) from another AVR everything
works as expected.  When the ARM9 is the master nothing works even though
the waveforms on the bus appear correct.  The only thing I am not sure of is
the start condition as I have only an analog scope with a ~100ns or so delay
line...

So, the question: has anyone connected an ARM9 with an AVR via I2C (oh, btw
this is using Linux with our own driver) and got it to work?  Any setup or
operational gotcha's I need to know about?

-----------
Larry Barello
www.barello.net

Re: [AVR-Chat] I2C interface question (AVR <-> ARM)

2006-04-22 by Ned Konz

On Apr 22, 2006, at 10:50 AM, Larry Barello wrote:

> I am trying to interface some AVR boards to an Arm9 board (Atmel  
> at91RM9200
> @ ~60mhz).  This worked at one point but now it isn't and I am getting
> stumped.
>
> There appears to be ~200ns of delay between the SDA and SCL when  
> generating
> the START condition.  This seems too small for the AVR @ 12mhz but  
> I can't
> tell from the data sheet.
>
> When running my commands (SMBus master/slave) from another AVR  
> everything
> works as expected.  When the ARM9 is the master nothing works even  
> though
> the waveforms on the bus appear correct.  The only thing I am not  
> sure of is
> the start condition as I have only an analog scope with a ~100ns or  
> so delay
> line...
>
> So, the question: has anyone connected an ARM9 with an AVR via I2C  
> (oh, btw
> this is using Linux with our own driver) and got it to work?  Any  
> setup or
> operational gotcha's I need to know about?

I did a Linux driver for an SMBus card (using an existing parallel- 
port i2c driver as a basis); when doing this I kept referring to the  
Philips I2C specification.

The delay you're referring to is, I assume the SDA-low to SCL-low  
delay; the Philips I2C spec puts the minimum for this as

tHD;STA + tf

= 4usec + 0 (standard mode) = 4usec
= 600nsec + (20+0.1 * Cb)nsec (fast mode) = 630nsec @ 100pF capacitance
(Cb = total cap of one bus line in pF)

So you're way too fast for the standard.

You'd probably do best to stick to the standard timings.

-- 
Ned Konz
MetaMagix embedded consulting
MetaMagix@gmail.com

RE: [AVR-Chat] I2C interface question (AVR <-> ARM)

2006-04-24 by Larry Barello

Ok, I have determined that the problem has nothing to do with the ARM / AVR
interface.  It is the level shifting chip (PCA9512).  Well, at least it
appears to be that: if I remove the level shifter and power everything with
3.3v then communications work.

The symptoms are simple: On the AVR side, the peripherals never see their
address on the bus and never assert the Ack bit.  Other than that the
waveforms look identical (level shifter or not).  In fact, with a nice
500mhz DRO the waveforms look incredibly clean!

I even swapped ends on the level shifter with identical results.

Anyone familiar with those chips and have any clue to what is wrong???

The odd thing is that if I make one of the AVR's master, it can read
peripherals on the ARM board just fine.

In examining the waveforms very carefully I determined several things: 
1. The level shifter has very clean, slew rate limited signals. 
2. The SCL clock is stretched when the ARM is the master

Anyone have experience using the level shifting chips?


-----------
Larry Barello
www.barello.net


| -----Original Message-----
| From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
| Of Larry Barello
| Sent: Saturday, April 22, 2006 10:51 AM
| To: AVR-Chat@yahoogroups.com
| Subject: [AVR-Chat] I2C interface question (AVR <-> ARM)
| 
| I am trying to interface some AVR boards to an Arm9 board (Atmel
| at91RM9200
| @ ~60mhz).  This worked at one point but now it isn't and I am getting
| stumped.
| 
| There appears to be ~200ns of delay between the SDA and SCL when
| generating
| the START condition.  This seems too small for the AVR @ 12mhz but I can't
| tell from the data sheet.
| 
| When running my commands (SMBus master/slave) from another AVR everything
| works as expected.  When the ARM9 is the master nothing works even though
| the waveforms on the bus appear correct.  The only thing I am not sure of
| is
| the start condition as I have only an analog scope with a ~100ns or so
| delay
| line...
| 
| So, the question: has anyone connected an ARM9 with an AVR via I2C (oh,
| btw
| this is using Linux with our own driver) and got it to work?  Any setup or
| operational gotcha's I need to know about?
| 
| -----------
| Larry Barello
| www.barello.net
| 
| 
| 
| 
| 
| 
| 
| Yahoo! Groups Links
| 
| 
| 
| 
|

Re: [AVR-Chat] I2C interface question (AVR <-> ARM)

2006-04-24 by Dave Hylands

Hi Larry,

On 4/23/06, Larry Barello <yahoo@barello.net> wrote:
> Ok, I have determined that the problem has nothing to do with the ARM / AVR
> interface.  It is the level shifting chip (PCA9512).  Well, at least it
> appears to be that: if I remove the level shifter and power everything with
> 3.3v then communications work.
>
> The symptoms are simple: On the AVR side, the peripherals never see their
> address on the bus and never assert the Ack bit.  Other than that the
> waveforms look identical (level shifter or not).  In fact, with a nice
> 500mhz DRO the waveforms look incredibly clean!
>
> I even swapped ends on the level shifter with identical results.
>
> Anyone familiar with those chips and have any clue to what is wrong???
>
> The odd thing is that if I make one of the AVR's master, it can read
> peripherals on the ARM board just fine.
>
> In examining the waveforms very carefully I determined several things:
> 1. The level shifter has very clean, slew rate limited signals.
> 2. The SCL clock is stretched when the ARM is the master
>
> Anyone have experience using the level shifting chips?

Do you have pullups on both sides of the level shifter?

What speed do you have the ARM and AVR configured for?

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

RE: [AVR-Chat] I2C interface question (AVR <-> ARM)

2006-04-24 by Larry Barello

Yes, 100khz (although I have tried from 10khz -> 500khz with identical
results).

There is no "speed" configuration for the AVR since they are in slave mode
only (except when I make one a master for testing purposes...)

-----------
Larry Barello
www.barello.net


| -----Original Message-----
| From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
| Of Dave Hylands
| > In examining the waveforms very carefully I determined several things:
| > 1. The level shifter has very clean, slew rate limited signals.
| > 2. The SCL clock is stretched when the ARM is the master
| >
| > Anyone have experience using the level shifting chips?
| 
| Do you have pullups on both sides of the level shifter?
| 
| What speed do you have the ARM and AVR configured for?
| 
| --
| Dave Hylands
| Vancouver, BC, Canada
| http://www.DaveHylands.com/

Re: I2C interface question (AVR <-> ARM)

2006-04-24 by upctoys

> Dave Hylands
> Vancouver, BC, Canada
> http://www.DaveHylands.com/
>
Dave,

The standard bus speed for I2C is 100khz, fast speed is 400khz and high 
speed can go to 3.4mhz with some parts but the 200ns you suggest makes 
state changes at 5mhz. More in the realms of an SPI interface.

Part of the problem with I2C and speed is the drivers (if your using 
any) are bidirectional (like P82B715). There is a loop back path with 
delays. Add optos to that if you want isolation and you relly start 
hitting brick walls with the speed. 

Slow it down. 

Cheers
Stefan

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.