Prev: Encryption Algorithm
Next: An OS for the AT91SAM7Sxx??
From: Stef on 17 Feb 2005 16:35
In comp.arch.embedded,
starfire <starfire151(a)cableone.net> wrote:
>
>I looked at the SDA and SCL on a logic analyzer and found out why it was
>erratic. Every other time I executed a read instruction, the SDA line

Did you also check the signals with a scope? The analyzer will only tell
you when it thinks the lines are high and low, but gives you little
information on the actual levels and rise- and falltimes.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

A good supervisor can step on your toes without messing up your shine.
From: starfire on 17 Feb 2005 20:29
Yes, actually I used a 16-channel Logic Scope from Tektronix. It shows all
the transitions on the lines like a scope but has a larger data capture
buffer so you can scroll through the capture history to see all the
transitions of the command.

The problem seems to be related to the data line not being shut off (left to
be pulled back up to +5V after a complete transmission).

Dave

"Stef" <stef33d(a)yahooI-N-V-A-L-I-D.com.invalid> wrote in message
news:77802$42150e3a$54f63171$21540(a)publishnet.news-service.com...
> In comp.arch.embedded,
> starfire <starfire151(a)cableone.net> wrote:
>>
>>I looked at the SDA and SCL on a logic analyzer and found out why it was
>>erratic. Every other time I executed a read instruction, the SDA line
>
> Did you also check the signals with a scope? The analyzer will only tell
> you when it thinks the lines are high and low, but gives you little
> information on the actual levels and rise- and falltimes.
>
> --
> Stef (remove caps, dashes and .invalid from e-mail address to reply by
> mail)
>
> A good supervisor can step on your toes without messing up your shine.


From: Paul Carpenter on 18 Feb 2005 04:21
On Thursday, in article <11195fvbv8h9l33(a)corp.supernews.com>
starfire151(a)cableone.net "starfire" wrote:
>"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
>news:20050217.0937.306771snz(a)pcserv.demon.co.uk...
>> On Wednesday, in article
>> <1117u2aiovrobdc(a)corp.supernews.com>
>> starfire151(a)cableone.net "starfire" wrote:
>>>Hi all -
>>>
>>>Has anyone had any experience with using multiple I2C devices is a bus
>>>architecture?
....
>>>I am using a PIC18LF252 uC, a 24LC256 serial EEPROM, and three Dallas
>>>DS1803
>>>dual 100K programmable pots in a bus. The circuit is on a printed circuit
>>>board (not wire-wrapped or breadboarded). The total length of SDA and SCL
>>>lines is about 3 inches.
>>
>> Last time I used DS1803 I had four of them, plus several PCF8574 and
>> PCF8591 off a PCF8584 controller on a H8.

In other setups I have used I2C down 9 feet of twisted pair + shield cable.

>>>I'm using the CCS C compiler with built-in I2C functions for I2C start,
>>>stop, write, and read. I had to write my own routines to handle the
>>>DS1803
>>>device specifics. I breadboarded a single DS1803 with some test code
>>>using
>>>the routines to verify correct operation. It seemed to work well. When I
>>>put the three DS1803 chips in the circuit, along with the memory chip
>>>though, it gives erratic results.
>>
>> The DS1803 is not too difficult to write for. Are you sure you are putting
>> the correct addresses out for all devices. Single unit has base address
>> (0x50) however adding extra unit addresses tends to be where most people
>> screw up on creating I2C addresses.
>>
>> What sub-addresses (unit numbers) are you using for the DS1803 devices?
>>
>>>I looked at the SDA and SCL on a logic analyzer and found out why it was
>>>erratic. Every other time I executed a read instruction, the SDA line
>>>stayed low (did not output the stop condition). The following command
>>>fails
>>>but resets the SDA line high again so the next instruction following works
>>>again. This repeats indefinitely. Every other read works. The write
>>>cycles seem to be OK so I thought it must be timing related. The DS1803
>>>reads both pot values sequentially and I thought the data on the second
>>>read
....
>> The first thing I would check is that your are addressing the devices
>> correctly as getting the addresses wrong in I2C causes a difference
>> between read and write mode.
....

>Thanks for the reply, Paul.
>
>The addressing is correct for the three devices. I've checked it several
>times. The device addresses that are flaky are the 000 and 001. Address
>010 seems to work fairly consistently. I've confirmed the addressing with
>the logic analyzer.

There is of course the other thing, you have checked that all three
address selection lines on ALL the DS1803 devices with a meter so that you
have not got a floating input causing one device to be recognised at
TWO addresses.

On your breadboard setup if it still exists can you test a single device
at the same addresses as your three device setup, to check the code for
multiple devices.

>I've downloaded the example you referred to from your web page and will
>examine it. I haven't had a chance to take a look at it yet. I will
>probably get a chance today or tomorrow.
>
>Thanks, again.
>
>Dave
>

--
Paul Carpenter | paul(a)pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate

From: Wil Taphoorn on 18 Feb 2005 08:23
starfire wrote:

> The problem seems to be related to the data line not being shut off (left to
> be pulled back up to +5V after a complete transmission).

This differs from what you wrote the first time:
| Every other time I executed a read instruction, the SDA line
| stayed low (did not output the stop condition).

If the line is high than the master can generate a STOP or any
other condition. If the lien stays low (as you reported earlier)
the the master can do nothing.

--
Wil
From: starfire on 18 Feb 2005 18:28
I don't think it differs from what I wrote earlier. The condition is
consistent. When monitoring the SDA and SCL lines, the initial condition
after power-up is that both lines are high (pulled up). When I execute any
write instruction to any device on the bus, the final condition of the lines
are left both high again. If I execute any read instruction to either the
pot at address 000 or the pot at address 001, the read completes
successfully (at least I see the data returned from the pots that was
programmed into them) but the status of lines is left with the clock line
high and the data line low. The next attempt at a read (or a write) fails
because the start condition is not sent on the bus. At the end of the that
instruction, though, the data line is high again so the following
instruction is executed correctly again. Reads to the pot at address 010
were OK and left the data line high.

I'm sorry if I wasn't clear in my original posting.

Dave

BTW: As an interesting note, I had to complete the population of the
remainder of the components on the board so the remainder of the testing
could continue. The pots were in the circuits of the other components as
resistor elements only. The problem identified above continued but the two
failing pots are at addresses 001 and 010 now. The pot at address 000 seems
to work OK now. Wierd.


"Wil Taphoorn" <wil(a)nogo.wtms.nl> wrote in message
news:4215EC59.764798ED(a)nogo.wtms.nl...
> starfire wrote:
>
>> The problem seems to be related to the data line not being shut off (left
>> to
>> be pulled back up to +5V after a complete transmission).
>
> This differs from what you wrote the first time:
> | Every other time I executed a read instruction, the SDA line
> | stayed low (did not output the stop condition).
>
> If the line is high than the master can generate a STOP or any
> other condition. If the lien stays low (as you reported earlier)
> the the master can do nothing.
>
> --
> Wil


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Encryption Algorithm
Next: An OS for the AT91SAM7Sxx??