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.
> 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
Reply by Nadav●October 18, 20042004-10-18
"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!
Reply by Henry Kiefer●October 14, 20042004-10-14
>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 �ber http://people.freenet.de/algenkocher>
Reply by Andras Tantos●October 14, 20042004-10-14
>>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
Reply by Andras Tantos●October 14, 20042004-10-14
>> 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
Reply by Henry Kiefer●October 14, 20042004-10-14
>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.
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.
regards -
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 �ber http://people.freenet.de/algenkocher>
Reply by Meindert Sprang●October 14, 20042004-10-14
"Andras Tantos" <andras_tantos@yahoo.com> wrote in message
news:2t5ma6F1qrbdaU1@uni-berlin.de...
> > Why not use a Philips PCA9515A, a I2C bus repeater in a SO-8 package.
Only
> > $0.70....
> >
> > Meindert
> >
> >
>
> 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.
Meindert
Reply by Nadav●October 14, 20042004-10-14
"Andras Tantos" <andras_tantos@yahoo.com> wrote in message news:<2t38baF1ounguU1@uni-berlin.de>...
> > Hi,
> >
> > I wanted to implement an i2c repeater in software. Actually, Not a
> > complete i2c but only one master to one slave repeater. I thought I
> > can use a microcontroller and connect two I/Os to the master and 2
> > more to the slave in open drain fasion. So I need to reflect the clock
> > from the master to the slave and the data to/from the master from/to
> > the slave, depending on the direction. I thought I would use some kind
> > of buffering (1 bit or 8 bit).
> >
> > Does anyone did somthing like that? Is it possible? What tricks to
> > use?
> > I know of few problems in the way, such as:
> > 1) If I'll use one bit buffer the master will wait for Akn after the
> > 8th bit while the slave only got the 7th.
> > 2) If I'll use 8 bit buffer, what to do when the last byte of a
> > transaction was corrupted?
> > 3) What is the best way to handle slatting?
> >
> > Thank a lot for any help.
> > Nadav.
>
> I've done this and planning on making it public on my website soon. The
> limitations are:
> - No clock-stretching from the slave-side is allowed (clock is allways
> driven by the master)
> - Masters can only be on the 'master' side. (Slaves can be on either side.)
> - Speed: I could get it up to about 50kHz clock rate on an AVR. Might get
> higher if you optimize code by hand.
>
> You don't have to actually understand the protocol and know when to drive
> which way: you can write code that monitors both the master and the slave
> side data lines and reflects the correct values back and forth. That way
> there's no buffering needed.
>
> Regards,
> Andras Tantos
Andras,
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?
Thanks,
Nadav.