Prev: Encryption Algorithm
Next: An OS for the AT91SAM7Sxx??
From: starfire on 18 Feb 2005 18:35
Thanks for the reply again, Paul.

The address lines are hard-wired circuit traces. I have confirmed correct
addressing on all three of them.

BTW, are you aware (or have any experience with) any SOIC, dual channel, I2C
programmable pots with non-volatile memory? These Dallas devices are OK but
they lose programming on power-down and I need to restore their values from
PIC EEPROM on power-up.

Thanks.

Dave


"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
news:20050218.0921.306810snz(a)pcserv.demon.co.uk...
> 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: Michael Lange on 19 Feb 2005 04:11
Hi starfire,

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

That looks like my problem while expand some existing code, a few weeks
ago. Are you sure, the master send a NAK after the last byte, he would
read from the slave!? Otherwise, the next read/write operation to an
other device will be impaired by _this_ slave. He is always in read mode!
In short: End Read Mode by sending NAK from the master!

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


Michael
--
Die eMail passt, und wer nicht spamt, kommt auch durch.
Gelesen wird jedoch nur ab und zu.

From: Wil Taphoorn on 19 Feb 2005 04:27
Please don't top post.

starfire wrote:
> "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).
> >
>
> I don't think it differs from what I wrote earlier.

Ok, I must have misread you then.

> The condition is consistent... [snipped]
....
> 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.

Did you verify that the driver does a NAK on the final byte of that read? I
suggested you to check that in my initial reply.

If the master does ACK on the final byte then the slave reacts by putting it
first bit of a new data byte onto the SDA line. If that bit happens to be 0
then the master is unable to reclaim the bus. If, however, the master does a
NAK on the final byte the slave will close, thereby releasing both SDA and SCL.

--
Wil
From: Paul Carpenter on 19 Feb 2005 10:27
On Friday, in article <111cuurpm51bce5(a)corp.supernews.com>
starfire151(a)cableone.net "starfire" wrote:
As others have said please reply at the BOTTOM it is getting tiring
re jigging your posts..
>"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
>news:20050218.0921.306810snz(a)pcserv.demon.co.uk...
>> 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
.....
>>>> Last time I used DS1803 I had four of them, plus several PCF8574 and
>>>> PCF8591 off a PCF8584 controller on a H8.
.....
>>>> 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.
....

>Thanks for the reply again, Paul.
>
>The address lines are hard-wired circuit traces. I have confirmed correct
>addressing on all three of them.

My issue was not the traces, but the quality of connections and shorts.
Have you checked your code against the breadboard with the breadboard
device at 000, 001 and 010.

>BTW, are you aware (or have any experience with) any SOIC, dual channel, I2C
>programmable pots with non-volatile memory? These Dallas devices are OK but
>they lose programming on power-down and I need to restore their values from
>PIC EEPROM on power-up.

In my application EEPROM was no use as the power unit had to reset, and a
startup sequence was needed, a saved value would set the wrong mode and smoke.
Without looking too hard I know that Dallas (now Maxim) and Xicor (now
Intersil) do parts with EEPROM.

A google search for "+EEPROM =pot" or "E2Pot" will turn up a lot of results.

The fact that Dallas/Maxim do parts with EEPROM and you had not found that
out worries me to how well you are looking at the problem as myself and others
have pointed out several items to check.

--
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: starfire on 19 Feb 2005 13:37

"starfire" <starfire151(a)cableone.net> wrote in message
news:1117u2aiovrobdc(a)corp.supernews.com...
> Hi all -
>
> Has anyone had any experience with using multiple I2C devices is a bus
> architecture?


.... snip ...



I just wanted to let everyone know I found the error of my ways.



The CCS compiler's i2c_read() instruction defaults to an acknowledge after
each read request. The Dallas DS1803 states it should receive no
acknowledge on the last read data transfer. There is a switch option in the
CCS read instruction to force a "no ack" after the read, which I coded after
the first read request. Since the DS1803 did not see the "no ack"
condition, it must have been fooled into thinking there would be another
read request to follow. The following command sends a bogus read request to
an invalid address, resulting in a "no ack", which apparently satisfies the
completion of the DS1803 cycle and it's ready for the next cycle.



I tried it again by forcing the ack after the first read and the no ack
after the second read. It worked perfectly.



Much thanks for all the responses. You were all instrumental in helping to
resolve this problem. Once again this newsgroup has shown itself to be one
of the most knowledgeable and responsive newsgroups on the net.



Thanks.



Dave








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