i2c repeater

>> Well, in my case, I also wanted traffic control. Basically make subnets 
>> of
>> I2C devices with the same physical address individually addressable from
> the
>> master side.
>
> To do this, I suppose you supply a signal to the repeater to pass or to
> isolate. The PCA9515A has a control input to accomplish this.
>

Nope. I'm using a version of soft-addressing with GUID-s and I2C 
bus-arbitration to individually address my 'switches'. Something similar to 
what the 24LCS61 does.

Regards,
Andras Tantos

>>If I want to support clock-stretching from the slave-side what will be
>>the way?
>>If I want to go as high as 400kHz then what? Its of course depends on
>>the micro. speed so what speed should I use?

> The issue of clock stretching on the SCL line is in hardware the same as 
> the
> ACK-bit processing on the SDA line. Of course, that's different if you 
> look
> onto the protocol.

The problem I had was that you would need bi-directional drive on the clock 
line as well. You can't do that with digital logic (or SW operating on 
digital values) without introducing spurious edges on the wires. That's fine 
for the data lines as long as they happen when the clock is incative, but 
not acceptable for the clock line.

So, in order for this to work, you'd need:
- Analog electronics
- A/D converter (and quite fast ones)

> For 400kHz use a really fast micro! Such as Scenix. Maybe the better way 
> is
> to use a CPLD or FPGA and do it in hardware.

Since the code on a 8MHz AVR was able to go as high as about 50kHz, I would 
say you need something far more powerful than that. Yes, a CPLD is probably 
a good solution.

Regards,
Andras Tantos

>The problem I had was that you would need bi-directional drive on the clock
>line as well. You can't do that with digital logic (or SW operating on
>digital values) without introducing spurious edges on the wires. That's
fine
>for the data lines as long as they happen when the clock is incative, but
>not acceptable for the clock line.
sure.

>
>So, in order for this to work, you'd need:
>- Analog electronics
good!

>- A/D converter (and quite fast ones)
strange idea but maybe it works!

>
>> For 400kHz use a really fast micro! Such as Scenix. Maybe the better way
>> is
>> to use a CPLD or FPGA and do it in hardware.
>
>Since the code on a 8MHz AVR was able to go as high as about 50kHz, I would
>say you need something far more powerful than that. Yes, a CPLD is probably
>a good solution.
If you have any form of programmable logic device already on the board, that
is the best solution!
Unfortunately, I only have practical designs made in the area of bit-banging
as master and designing large i2c-busses across several systems (several
meters with say 30 slaves).

Use Ethernet... and low-cost Ethernet switches *lol

- Henry

--

<Schau auch mal auf meine Homepage www.ehydra.dyndns.info>
<u.a. Versand von Wasserflohzuchtansatz, Wasserpflanzen/-schnecken,
brasilianischer Sauerklee, Natron zum Backen/Baden, u.a.>
<Alternativ &#4294967295;ber http://people.freenet.de/algenkocher>

"Andras Tantos" <andras_tantos@yahoo.com> wrote in message news:<2t8645F1tih6qU1@uni-berlin.de>...
> >>If I want to support clock-stretching from the slave-side what will be
> >>the way?
> >>If I want to go as high as 400kHz then what? Its of course depends on
> >>the micro. speed so what speed should I use?
>  
> > The issue of clock stretching on the SCL line is in hardware the same as 
> > the
> > ACK-bit processing on the SDA line. Of course, that's different if you 
> > look
> > onto the protocol.
> 
> The problem I had was that you would need bi-directional drive on the clock 
> line as well. You can't do that with digital logic (or SW operating on 
> digital values) without introducing spurious edges on the wires. That's fine 
> for the data lines as long as they happen when the clock is incative, but 
> not acceptable for the clock line.
> 
> So, in order for this to work, you'd need:
> - Analog electronics
> - A/D converter (and quite fast ones)
> 
> > For 400kHz use a really fast micro! Such as Scenix. Maybe the better way 
> > is
> > to use a CPLD or FPGA and do it in hardware.
> 
> Since the code on a 8MHz AVR was able to go as high as about 50kHz, I would 
> say you need something far more powerful than that. Yes, a CPLD is probably 
> a good solution.
> 
> Regards,
> Andras Tantos
OK. but lets say I only need the simple case in which the clock goes
from the master to slave only. One direction only. Then my problem is
the data line only. And the same spurios edges problem. I thought if
I'll buffer one bit and at the 8th bit I'll stretch the SCL to the
master and wait untill the slave acknowledge and only then acknowledge
to the master. Should it work? What will be the penalty on
performance?

Regarding the frequency issue, what will be the minimum samples in
eack clock duty cycle? What is 8MHz AVR?

Thanks again!

> OK. but lets say I only need the simple case in which the clock goes
> from the master to slave only. One direction only. Then my problem is
> the data line only. And the same spurios edges problem. I thought if
> I'll buffer one bit and at the 8th bit I'll stretch the SCL to the
> master and wait untill the slave acknowledge and only then acknowledge
> to the master. Should it work? What will be the penalty on
> performance?

You basically have two ways to go:
- Understand all the protocol details and know when to switch the direction 
in the data-line. In that case you won't introduce any glitches on the 
data-line but any non-standard communication would brake your 
implementation. This is the case when you have to introduce some buffering, 
and yes, you would have to use clock-streching on the ack bit.
- Go the dumb mirroring way and accept the spurios edges on the data lines. 
Since direction change is done by monitoring the data and clock lines, ACK 
bit transmission happens automatically as well and you don't have to use 
clock-streching.

> Regarding the frequency issue, what will be the minimum samples in
> eack clock duty cycle? What is 8MHz AVR?

Well, I didn't do that exhaustive mesurements. But I run a couple of test 
runs in the simulator counting the clock-cycles it took for the CPU to 
process each phase of its statemachine and that seemed to be a reasonable 
speed. I might be off by a couple of percentages but not by an order of 
magnitude.

AVR is an 8-bit micro form Atmel. 8MHz is it's clock-rate.

Regards,
Andras Tantos 

I've made my code and documentation available here: 
http://h-storm.tantos.homedns.org/download/sys_ctrl.zip

Regards,
Andras Tantos

"Andras Tantos" <andras_tantos@yahoo.com> wrote in message news:<2tlj35F214rl3U1@uni-berlin.de>...
> I've made my code and documentation available here: 
> http://h-storm.tantos.homedns.org/download/sys_ctrl.zip
> 
> Regards,
> Andras Tantos

I saw it. You did a grate job there. I think I'll go ahead with the
one bit buffering idea. Actualy, I'm going to implement an I2C mux 2:1
which can be a good idea for your modules collection or H-Strom
component.

Regards,
Nadav.