ADS7828 - bizzare A0/A1 I2C addressing scheme

[Peter]

Hi All,

I wonder if anyone has come across this... The ADS7828 is a I2C
interface converter. Like a lot of I2C devices, you send it an
addressing byte, of which 2 bits have to match the state of two
external inputs.

In that way, one can have a number of such devices on the same
data/clk bus.

The 7828 data sheet states that the device latches the A0/A1 states at
power-up. BUT this would make it unusable unless they were both tied
it GND (because of the unpredictable input thresholds while VCC is
rising) and certainly they could not be driven from any external
logic. Unless the latching was done some tens of ms after VCC has
risen... but the data sheet does not say that!

I am trying hard to get an answer from TI on this but their support
engineer doesn't appear to really know...

Can anyone offer any light on this?



Peter.

 

[Tilmann Reh]

The 7828 data sheet states that the device latches the A0/A1 states at
power-up. BUT this would make it unusable unless they were both tied
it GND (because of the unpredictable input thresholds while VCC is
rising) and certainly they could not be driven from any external
logic. Unless the latching was done some tens of ms after VCC has
risen... but the data sheet does not say that!

I think you are assumed to have these inputs tied to GND and VCC,
according to the address you want to use.
This also is the way I2C devices are normally told their addresses.

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)

 

[Peter]

There seems to be little desire to change the address on the fly, so
it is done hardwired. If you have a couple of such devices, decide what
addresses to give them, ones that don't conflict, and tie the inputs to
GND or VCC.

So, the device must wait for VCC to stabilise before it samples, and
then latches, the A0/A1 inputs.

Otherwise, this scheme could not work!


Peter.

 

[Frank Bemelman]

So, the device must wait for VCC to stabilise before it samples, and
then latches, the A0/A1 inputs.

Otherwise, this scheme could not work!

It's the same VCC as for the device, probably not critical. To be honest,
I was never aware of this power-on latching, don't know if this is common
behaviour for all I2C devices.

 

[Dana Raymond]

The other responses are correct. Yes, it would make life easier to expand
the I2C addressing scheme - I've run into problems like that myself.
However, thats not how the standard works. Each device has a fixed
addresses, established at power-up. Some manufacturers actually release
variants of their parts with different addresses (where all the pins are
used).

There are parts available that allow you to split I2C busses, or multiplex
them, etc. You could also use a latch that feeds the address pins and also
controls the power pin on the device. I2C devices are supposed to be 'sane'
when powered down. That is, they are not supposed to load down or interfere
with the clock and data lines when unpowered.

When you think about it, latching the address pins takes additional logic -
a direct use of them may make more sense. BUT The I2C master is not supposed
to NEED any other connectivity to the slave devices, hence the fixed
addressing scheme.

Need more addresses? Use those devices I mentioned, use 10-bit I2C devices,
use a repeater with enable (only one in series!), or the method I suggested
above.

Hope this helps.
Dana Frank Raymond

 

[Andrew Paule]

the only reliable way to get this thing to latch is to power it after
the Vdd that you are using for the address is up. Run into this many
times - don't know why so many chip makers still do it.

Andrew

 

[Frank Bemelman]

the only reliable way to get this thing to latch is to power it after
the Vdd that you are using for the address is up. Run into this many
times - don't know why so many chip makers still do it.

But why would you want to set the adress bits by means of another
device? I would think the adress would be fixed anyway, in a
given system.

 

[Dana Raymond]

If you need to use 2 or more of the same part on the same I2C bus.

Dana Frank Raymond

 

[Peter]

As you seem to be an I2C expert, may I ask another question...?

It is to do with the *direction* of the clock signal.

The ADS7828 is an I2C ADC. One sends it address and command bytes;
there is no doubt these are clocked in by the processor.

Then it does the conversion.

Then the result is clocked out. It would seem obvious that the clocks
for this should also come from the processor. However its data sheet
is ambiguous on this part, showing timing diagrams which imply these
clock pulses come out of the 7828. I have been waiting for 2 weeks for
TI to come up with someone who can explain this.

I suspect there are various errors in the data sheet... but my I2C
experience is limited to serial eeproms and RTC chips. None of those
ever emitted any clock.


Peter.

 

[Frank Bemelman]

If you need to use 2 or more of the same part on the same I2C bus.

Yes, but for that you have 2 adresslines, which you can hardwire,
so you can put 4 of them on the same I2C bus. So I repeat the
question, why would you want to set the adress through some external
device?

 

[Dana Raymond]

Sheesh! If you need to use 5 or more of the same part on the same I2C bus.

I've used I2C and HAVE run into this limitation before. Got it?

Dana Frank Raymond

 

[Andrew Paule]

Hi Frank -

On the first question, I would never tie anything like this direct to
Vdd, you lack a test point that is valid for board test, and if the
part fails on the pin, you may take down others (been there done that in
my younger days). Use of a pullup may not be "required', and use of a
divider may not be "required", but it is good practice - I worked in
ATE, and reliability and testability were the top two requirements
beyond simple functionality. I still believe in the philosophy, and
doing it cheap and easy leads to problems down the road.

Problem is in either the data sheet or the part - there is no note on
when the address is latched, or how they do it. They (TI) say that an
active TTL or CMOS gate can set the address, and you may be able to do
this after power up by a power up/power down cycle on the chip, but the
data sheet does not tell you if you can. this information is lacking in
the data sheet/app notes for the part, and unless I am willing to guess
at the funcionality (with my references as noted), I could not tell you
for certain what the behavior would be. I would either find out from
TI, or would not use thepart in this manner. I've used tons of I2C
parts in the past, but that does not make one bit of difference in my
point here, unlesss TI coughs up the answer, it is not a known, and
designing with an unknown when you can get so many knowns from so many
places is not a good idea.

Andrew

 

[James Beck]

No, not yet If you set the address through some external port,
and you have 5 of them on the same bus, 2 of them will still get
the same address. How do you deal with that?

Please don't toppost.

You set all devices to one address. They are all in conflict right?
Wrong, they aren't in conflict until you try to get them to talk back to
you. You then take the device you want to address and pull its address
lines to a unique state and talk to it. When done you revert it back to
the common unused address and do the same for the next device. That way
you are kinda' using the address lines as chip selects. That is 1 way
to do it and I'm sure others have done other things. You can only talk
to one device at a time, so as long as the device you are talking to is
the only one at that address there is no conflict. Can hand a lot of
I2C devices off a CPU using just a few lines and a decoder or lines from
an under utilized port.
What is important is WHEN the device gets its address info. If the unit
latches the A0, A1 values on power up then the scheme won't work. I
have some EEPROMs that specifically state that they don't do the compare
until after the address info has been latched, so they would be useful
in that case.
Any questions?

Jim

 

[Frank Bemelman]

You set all devices to one address. They are all in conflict right?
Wrong, they aren't in conflict until you try to get them to talk back to
you. You then take the device you want to address and pull its address
lines to a unique state and talk to it. When done you revert it back to
the common unused address and do the same for the next device. That way
you are kinda' using the address lines as chip selects. That is 1 way
to do it and I'm sure others have done other things. You can only talk
to one device at a time, so as long as the device you are talking to is
the only one at that address there is no conflict. Can hand a lot of
I2C devices off a CPU using just a few lines and a decoder or lines from
an under utilized port.
What is important is WHEN the device gets its address info. If the unit
latches the A0, A1 values on power up then the scheme won't work. I
have some EEPROMs that specifically state that they don't do the compare
until after the address info has been latched, so they would be useful
in that case.
Any questions?

No, no more questions Thanks for explaining.

 

[Arie de Muynck]

See, that's one way I didn't even think of, and it's a good one.
No clock, no tranfer, no conflict. Just as long as the device you are
talking to isn't capable of a cycle stretch. The "master" wouldn't be
able to do a read of the clock line.

Sometimes analog tinkering can resolve digital problems.
Use an analog 2x4 MUX with Ron below 100E (like a good HC4052) in the SCL
and SDA lines. Use 4K7 pullups on each side of the mux as the I2C pullups.
Result: four busses selected using one chip, with binary bus selection.
Clock stretching supported.

Regards,
Arie de Muynck

 

[James Beck]

Sometimes analog tinkering can resolve digital problems.
Use an analog 2x4 MUX with Ron below 100E (like a good HC4052) in the SCL
and SDA lines. Use 4K7 pullups on each side of the mux as the I2C pullups.
Result: four busses selected using one chip, with binary bus selection.
Clock stretching supported.

Regards,
Arie de Muynck

That's even mo' better, and the list grows......

Jim

 

[Peter]

Problem is in either the data sheet or the part - there is no note on
when the address is latched, or how they do it. They (TI) say that an
active TTL or CMOS gate can set the address, and you may be able to do
this after power up by a power up/power down cycle on the chip, but the
data sheet does not tell you if you can. this information is lacking in
the data sheet/app notes for the part, and unless I am willing to guess
at the funcionality (with my references as noted), I could not tell you
for certain what the behavior would be. I would either find out from
TI, or would not use thepart in this manner. I've used tons of I2C
parts in the past, but that does not make one bit of difference in my
point here, unlesss TI coughs up the answer, it is not a known, and
designing with an unknown when you can get so many knowns from so many
places is not a good idea.

I heard from TI today.

There is a mistake in the data sheet; the A0/A1 pins cannot be
(usefully) driven from external logic. They are internally latched at
power up (must be "after power up" or "after VCC is defined" otherwise
the only scheme which would be reliable would be A0=A1=GND) and cannot
be changed afterwards unless you drive the ADC's VCC via a MOSFET and
cycle it

So I have to mod my PCB and ground both of them directly.

The ADC can also apparently stretch the clock (it shorts it to GND
with an open-drain FET); apparently this is a standard I2C feature. I
will have a lot of fun bit-bashing this interface with an H8/325...

I wish the data sheet was clearer on the details, rather than assuming
somebody knows the whole I2C protocol. There are also other errors in
it which are misleading, e.g. in the timing diagram where you are
reading the data out of it (there is no apparent alignment between the
clock and the data changing; in reality the data changes on the
falling clock edge.


Peter.

 

[Dana Raymond]

Peter... Did you get my post about clock stretching, switching VDD, and
including the I2C specification attached?

BTW if you do feed the address bits while the chip is powered down you need
to prevent current being injected into those pins, which will end up on
VDDdue to their catch diodes.

The 'safest' way of doing this is to drive an address line with a pullup
resistor to VDD and the drain of an 2N7002 fet. No current will be sourced
while VDD is off, and the address pin will 'see' VDD while powering up.

Yes, you bank all 'unselected' parts to the same address and don't use that
address. You remove the part or group of parts from the unselected bank by
assigning a specific address(s) to it/them.

The I2C spec is easy to read. Did you receive it?

Dana Frank Raymond

 

[Peter]

Peter... Did you get my post about clock stretching, switching VDD, and
including the I2C specification attached?

No, I didn't.

BTW if you do feed the address bits while the chip is powered down you need
to prevent current being injected into those pins, which will end up on
VDDdue to their catch diodes.
Certainly.

The 'safest' way of doing this is to drive an address line with a pullup
resistor to VDD and the drain of an 2N7002 fet. No current will be sourced
while VDD is off, and the address pin will 'see' VDD while powering up.

Yes, you bank all 'unselected' parts to the same address and don't use that
address. You remove the part or group of parts from the unselected bank by
assigning a specific address(s) to it/them.

The I2C spec is easy to read. Did you receive it?

No, haven't seen it. The problem is that I am trying to bit-bash this
in the simplest possible way... the whole spec is probably too much to
implement.


Peter.

 

[Dana Raymond]

I've done bit bashing of the I2C spec, including clock stretching. Its not
that difficult so long as you understand the signalling events. Send me your
email and I'll be happy to send the spec to you. Believe me, its worth it. I
did send it to the newsgroup along with my message, and received it here.
Perhaps not all ISPs allow for storage of attachments?

Dana Frank Raymond