L
Lasse Langwadt Christense
Guest
lørdag den 11. maj 2019 kl. 00.00.31 UTC+2 skrev Winfield Hill:
the STM have programmable slewrate on the IOs
the STM have programmable slewrate on the IOs
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
J
Jan Panteltje
Guest
On a sunny day (10 May 2019 07:09:13 -0700) it happened Winfield Hill
<hill@rowland.harvard.edu> wrote in <qb40m902842@drn.newsguy.com>:
I have used i2c to drive announcement displays in an office building over hundreds of
meters, using unshielded cable, ONE WAY,
cable measured about 100 Ohm, used a fast able driver chip
(was in the eighties cannot remember what chip)
and drove clock and data with 100 Ohm.
At home I had i2c bus coming from a 8052 micro 'as is'
using 4 core individual shielded audio cable and 180 degrees DIN connectors.
No problem even when I was running a 150W watts radio transmitters that would
upset everything else around from TV to VHS recorder.
Bus speed is not critical, normally you can slow down i2c if there is a lot of capacitance,
But I would not, for a bidirectional setup with those simple pull-up resistors
in the open, use unshielded cable, nearby cellphones can do bad things.
Lightning..
<hill@rowland.harvard.edu> wrote in <qb40m902842@drn.newsguy.com>:
We need a 1-meter length of 100kHz (or slower)
I2C onnection. It'd be nice to use a pre-made
cable: micro-USB, 4-wire RJ11, or RJ45 ethernet.
Some considerations: SCL and SDA crosstalk(?),
high ground capacitance. Also need 3.3V, Gnd.
Micro-USB: SCL and SDA twisted together, bad?
RJ11: flat, SCL and SDA on outside lines?
RJ45: SCL and SDA shielded from each other.
I have used i2c to drive announcement displays in an office building over hundreds of
meters, using unshielded cable, ONE WAY,
cable measured about 100 Ohm, used a fast able driver chip
(was in the eighties cannot remember what chip)
and drove clock and data with 100 Ohm.
At home I had i2c bus coming from a 8052 micro 'as is'
using 4 core individual shielded audio cable and 180 degrees DIN connectors.
No problem even when I was running a 150W watts radio transmitters that would
upset everything else around from TV to VHS recorder.
Bus speed is not critical, normally you can slow down i2c if there is a lot of capacitance,
But I would not, for a bidirectional setup with those simple pull-up resistors
in the open, use unshielded cable, nearby cellphones can do bad things.
Lightning..
W
Winfield Hill
Guest
Lasse Langwadt Christensen wrote...
Aha! I'll see if our programmer can activate that.
--
Thanks,
- Win
the STM have programmable slewrate on the IOs
Aha! I'll see if our programmer can activate that.
--
Thanks,
- Win
R
Rick C
Guest
On Saturday, May 11, 2019 at 3:10:59 AM UTC-4, Tim Williams wrote:
Yeah, I didn't think the standard had any such filtering specified. Originally the I2C spec was for connecting devices on a single PCB, so no filtering should be required. The signals need to be given the standard integrity attention you would give any of the other clock and data signals running around the board. This sensitivity to noise is why you need to take more care in distributing the signals to other boards or more so, other chassis. You can add whatever type of filtering you wish to your own implementations, but don't expect other devices to have the same degree of noise immunity.
--
Rick C.
-- Get a 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
"Rick C" <gnuarm.deletethisbit@gmail.com> wrote in message
news:0be3e775-67ce-4a39-891a-a2b9330fd7a5@googlegroups.com...
I thought I had read the standard once some time ago and don't recall that
it is intended to be sampled like a UART. Is that literally in the spec
or does it say some amount of noise is to be rejected and not seen as a
start condition or clock edge?
It's been so long since I looked at the standard in that much detail. But
some kind of minor filtering is required. A digital filter would be a
typical implementation.
If you have, say, MCU peripherals that require fairly high clocks relative
to the data rate (i.e., "400kHz"), say a 16x or higher prescaler, that's
probably what's being done.
In a correct implementation, the "400kHz" isn't, it's just the average when
everything is behaving as it should, activating and releasing SCK in a
timely manner, and with pull-up, capacitance and rise time in spec.
Yeah, I didn't think the standard had any such filtering specified. Originally the I2C spec was for connecting devices on a single PCB, so no filtering should be required. The signals need to be given the standard integrity attention you would give any of the other clock and data signals running around the board. This sensitivity to noise is why you need to take more care in distributing the signals to other boards or more so, other chassis. You can add whatever type of filtering you wish to your own implementations, but don't expect other devices to have the same degree of noise immunity.
--
Rick C.
-- Get a 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
M
Martin Riddle
Guest
On 11 May 2019 05:08:24 -0700, Winfield Hill
<hill@rowland.harvard.edu> wrote:
There is plenum rated cable, it does not outgass when burning eg; low
smoke.
PVC is not too good for outdoor use.
Might want to check for RoHS/REACH compliance, that way you will not
get the phthalates.
Cheer
<hill@rowland.harvard.edu> wrote:
Jasen Betts wrote...
On 2019-05-10, Winfield Hill wrote:
We need a 1-meter length of 100kHz (or slower)
I2C onnection. It'd be nice to use a pre-made
cable: micro-USB, 4-wire RJ11, or RJ45 ethernet.
Some considerations: SCL and SDA crosstalk(?),
high ground capacitance. Also need 3.3V, Gnd.
do you need UV resistant? weatherproof?
It'd be nice, but otherwise I'll wrap everything
with rubber mastic electrical tape, or some such.
Micro-USB: SCL and SDA twisted together, bad?
yes bad, maybe put SDA on white as SCL on red
and +3 on green
RJ11: flat, SCL and SDA on outside lines?
or SDA-0-scl-3.3
or RJ12: 0-SDA-0-3.3-SCL-0
This is my choice: RJ12 6P6C connector, except
3.3-SDA-3.3-0-SCL-0 (3.3 and 0 are equivalent)
Flat 6P6C cables from Amazon, $4 each. An RJ12
connector at each end, series damping resistors.
A bit of a kludge, but beehive clock is ticking.
RJ45: SCL and SDA shielded from each other.
meh.
Mounted RJ45 connector, but too big, cable too
stiff, unsure of how the shielded variant works.
Went to smaller, simpler RJ12 instead.
There is plenum rated cable, it does not outgass when burning eg; low
smoke.
PVC is not too good for outdoor use.
Might want to check for RoHS/REACH compliance, that way you will not
get the phthalates.
Cheer
W
Winfield Hill
Guest
Winfield Hill wrote...
I miss-spoke, we're using an Atmel ARM SAM D21.
Not sure if they have programmable slew rate,
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load. Well, anyway, I've added a
resistor (100-ohm) in series with the I2C lines.
--
Thanks,
- Win
Lasse Langwadt Christensen wrote...
the STM have programmable slewrate on the IOs
Aha! I'll see if our programmer can activate that.
I miss-spoke, we're using an Atmel ARM SAM D21.
Not sure if they have programmable slew rate,
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load. Well, anyway, I've added a
resistor (100-ohm) in series with the I2C lines.
--
Thanks,
- Win
R
Rick C
Guest
On Saturday, May 11, 2019 at 6:19:01 PM UTC-4, Winfield Hill wrote:
20 ns is already an inordinately slow rise time. I can assure you it will not create measurable crosstalk in a 1 meter cable. Especially if you use twisted pair.
Sorry, I misread the numbers you posted. Still, the 6:1 is a rule of thumb for ignoring any further consideration. Your rise time will be slow enough that it is highly unlikely to result in significant reflections.
--
Rick C.
-+ Get a 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209
Rick C wrote...
Winfield Hill wrote:
Winfield Hill wrote...
Lasse Langwadt Christensen wrote...
the STM have programmable slewrate on the IOs
Aha! I'll see if our programmer can activate that.
I miss-spoke, we're using an Atmel ARM SAM D21.
Not sure if they have programmable slew rate,
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load. Well, anyway, I've added a
resistor (100-ohm) in series with the I2C lines.
That seems excessive. Even with a 20 ns rise time
the round trip on a 1 meter cable is around half
the rise time. I think the magic number to ignore
reflections is for the rise time to be 6 times the
round trip delay. The capacitance you can expect
on this run would very likely put the rise time
higher than this threshold so no further actions
would be needed to prevent reflections.
Yes, I agree, but my worry isn't so much about
reflections, as about crosstalk. If a fast SCL
falltime induces an SDA signal, apparently this
can cause trouble. Fix with slow falltimes.
20 ns is already an inordinately slow rise time. I can assure you it will not create measurable crosstalk in a 1 meter cable. Especially if you use twisted pair.
Do you think your rise time will be less than
60 ns?
Yes, according to the spec, without the resistor.
Well, OK, I do have an 74HC4052 channel switch
in series; it may be about 100 ohms at 3.3 volts.
Sorry, I misread the numbers you posted. Still, the 6:1 is a rule of thumb for ignoring any further consideration. Your rise time will be slow enough that it is highly unlikely to result in significant reflections.
--
Rick C.
-+ Get a 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209
R
Rick C
Guest
On Saturday, May 11, 2019 at 5:23:35 PM UTC-4, Winfield Hill wrote:
That seems excessive. Even with a 20 ns rise time the round trip on a 1 meter cable is around half the rise time. I think the magic number to ignore reflections is for the rise time to be 6 times the round trip delay. The capacitance you can expect on this run would very likely put the rise time higher than this threshold so no further actions would be needed to prevent reflections.
Do you think your rise time will be less than 60 ns?
--
Rick C.
-- Get a 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
Winfield Hill wrote...
Lasse Langwadt Christensen wrote...
the STM have programmable slewrate on the IOs
Aha! I'll see if our programmer can activate that.
I miss-spoke, we're using an Atmel ARM SAM D21.
Not sure if they have programmable slew rate,
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load. Well, anyway, I've added a
resistor (100-ohm) in series with the I2C lines.
That seems excessive. Even with a 20 ns rise time the round trip on a 1 meter cable is around half the rise time. I think the magic number to ignore reflections is for the rise time to be 6 times the round trip delay. The capacitance you can expect on this run would very likely put the rise time higher than this threshold so no further actions would be needed to prevent reflections.
Do you think your rise time will be less than 60 ns?
--
Rick C.
-- Get a 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
W
Winfield Hill
Guest
Rick C wrote...
Yes, I agree, but my worry isn't so much about
reflections, as about crosstalk. If a fast SCL
falltime induces an SDA signal, apparently this
can cause trouble. Fix with slow falltimes.
Yes, according to the spec, without the resistor.
Well, OK, I do have an 74HC4052 channel switch
in series; it may be about 100 ohms at 3.3 volts.
--
Thanks,
- Win
Winfield Hill wrote:
Winfield Hill wrote...
Lasse Langwadt Christensen wrote...
the STM have programmable slewrate on the IOs
Aha! I'll see if our programmer can activate that.
I miss-spoke, we're using an Atmel ARM SAM D21.
Not sure if they have programmable slew rate,
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load. Well, anyway, I've added a
resistor (100-ohm) in series with the I2C lines.
That seems excessive. Even with a 20 ns rise time
the round trip on a 1 meter cable is around half
the rise time. I think the magic number to ignore
reflections is for the rise time to be 6 times the
round trip delay. The capacitance you can expect
on this run would very likely put the rise time
higher than this threshold so no further actions
would be needed to prevent reflections.
Yes, I agree, but my worry isn't so much about
reflections, as about crosstalk. If a fast SCL
falltime induces an SDA signal, apparently this
can cause trouble. Fix with slow falltimes.
Do you think your rise time will be less than
60 ns?
Yes, according to the spec, without the resistor.
Well, OK, I do have an 74HC4052 channel switch
in series; it may be about 100 ohms at 3.3 volts.
--
Thanks,
- Win
C
Clifford Heath
Guest
On 12/5/19 7:23 am, Winfield Hill wrote:
Not the D21, not on GPIO pins. Pullup/down but not drive strength/slew rate.
Presumably the slew-rate limiting depends on the selected data rate, but
the data sheet is pretty quiet on that.
Winfield Hill wrote...
Lasse Langwadt Christensen wrote...
the STM have programmable slewrate on the IOs
Aha! I'll see if our programmer can activate that.
I miss-spoke, we're using an Atmel ARM SAM D21.
Not sure if they have programmable slew rate,
Not the D21, not on GPIO pins. Pullup/down but not drive strength/slew rate.
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load. Well, anyway, I've added a
resistor (100-ohm) in series with the I2C lines.
Presumably the slew-rate limiting depends on the selected data rate, but
the data sheet is pretty quiet on that.
W
Winfield Hill
Guest
Clifford Heath wrote...
Here's their spec, fall time, for 0.7 to 0.3 Vdd:
typ max
Standard/Fast 20 50 ns
Fast Mode + 15 50
High Speed Mode 10 40
Yes, it changes with speed setting, but not much.
Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns.
I = C dV/dt, with 75pF, that's i = 5mA, during
a 50ns transition. This is what can kill using
twisted-pair wires in a short USB cable. If we
have 75pF crosstalk with a 200pF load, that's
still a 28% Vdd interference signal, which is
smack on the 30% trouble threshold. Why only
slow to a fast 50ns transition with a 10us bit
interval? That's only 0.5%. That's why I made
more changes and added extra stuff.
--
Thanks,
- Win
Winfield Hill wrote:
I miss-spoke, we're using an Atmel ARM SAM D21.
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load.
Presumably the slew-rate limiting depends on the
selected data rate, but the data sheet is pretty
quiet on that.
Here's their spec, fall time, for 0.7 to 0.3 Vdd:
typ max
Standard/Fast 20 50 ns
Fast Mode + 15 50
High Speed Mode 10 40
Yes, it changes with speed setting, but not much.
Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns.
I = C dV/dt, with 75pF, that's i = 5mA, during
a 50ns transition. This is what can kill using
twisted-pair wires in a short USB cable. If we
have 75pF crosstalk with a 200pF load, that's
still a 28% Vdd interference signal, which is
smack on the 30% trouble threshold. Why only
slow to a fast 50ns transition with a 10us bit
interval? That's only 0.5%. That's why I made
more changes and added extra stuff.
--
Thanks,
- Win
C
Clifford Heath
Guest
On 12/5/19 12:13 pm, Winfield Hill wrote:
Hmm, good numbers. I guess it was a cost justification. Slow slew would
need a bigger capacitor, and/or paralleled strong and weak output
devices - but they're probably just re-using some pin driver from
elsewhere. I wonder if any variable-slew chip parallels output devices,
using the weak ones to slew and (time delayed) the strong ones to
drive/clamp the line.
Clifford Heath wrote...
Winfield Hill wrote:
I miss-spoke, we're using an Atmel ARM SAM D21.
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load.
Presumably the slew-rate limiting depends on the
selected data rate, but the data sheet is pretty
quiet on that.
Here's their spec, fall time, for 0.7 to 0.3 Vdd:
typ max
Standard/Fast 20 50 ns
Fast Mode + 15 50
High Speed Mode 10 40
Yes, it changes with speed setting, but not much.
Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns.
I = C dV/dt, with 75pF, that's i = 5mA, during
a 50ns transition. This is what can kill using
twisted-pair wires in a short USB cable. If we
have 75pF crosstalk with a 200pF load, that's
still a 28% Vdd interference signal, which is
smack on the 30% trouble threshold. Why only
slow to a fast 50ns transition with a 10us bit
interval? That's only 0.5%.
Hmm, good numbers. I guess it was a cost justification. Slow slew would
need a bigger capacitor, and/or paralleled strong and weak output
devices - but they're probably just re-using some pin driver from
elsewhere. I wonder if any variable-slew chip parallels output devices,
using the weak ones to slew and (time delayed) the strong ones to
drive/clamp the line.
R
Rick C
Guest
On Saturday, May 11, 2019 at 10:14:01 PM UTC-4, Winfield Hill wrote:
I don't follow your crosstalk analysis. You are assuming your load is purely capacitive. But your load includes resistance as well. That means you need to factor in the frequency aspect of your signal slew rate so the total effect of capacitance and resistance can be understood. Or are you sure your resistive load is of no consequence? With such slow edge rates I'm not sure that would be valid.
I suppose a simulation would be easy enough.
--
Rick C.
+- Get a 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209
Clifford Heath wrote...
Winfield Hill wrote:
I miss-spoke, we're using an Atmel ARM SAM D21.
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load.
Presumably the slew-rate limiting depends on the
selected data rate, but the data sheet is pretty
quiet on that.
Here's their spec, fall time, for 0.7 to 0.3 Vdd:
typ max
Standard/Fast 20 50 ns
Fast Mode + 15 50
High Speed Mode 10 40
Yes, it changes with speed setting, but not much.
Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns.
I = C dV/dt, with 75pF, that's i = 5mA, during
a 50ns transition. This is what can kill using
twisted-pair wires in a short USB cable. If we
have 75pF crosstalk with a 200pF load, that's
still a 28% Vdd interference signal, which is
smack on the 30% trouble threshold. Why only
slow to a fast 50ns transition with a 10us bit
interval? That's only 0.5%. That's why I made
more changes and added extra stuff.
I don't follow your crosstalk analysis. You are assuming your load is purely capacitive. But your load includes resistance as well. That means you need to factor in the frequency aspect of your signal slew rate so the total effect of capacitance and resistance can be understood. Or are you sure your resistive load is of no consequence? With such slow edge rates I'm not sure that would be valid.
I suppose a simulation would be easy enough.
--
Rick C.
+- Get a 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209
J
Jan Panteltje
Guest
On a sunny day (11 May 2019 19:13:48 -0700) it happened Winfield Hill
<hill@rowland.harvard.edu> wrote in <qb7vgs02cif@drn.newsguy.com>:
The rise - and falltime spec has little meaning, because the i2c system works differently.
Data is sampled by the clock.
As long as you wait long enough after each transition, data will be stable,
and toggling the clock during stable data a million times due to oscillations in the transient will still read that data in correctly.
I always do i2c in software.
Some years ago I had this chip with a hardware i2c interface (was it a PIC? do not remember, yes I think it was),
and a datasheet that sounded really funny to me.
So did it in software as always and it worked perfectly
Sure enough in the chip errata the i2c hardware interface was mentioned as erratic, and fixed.
So here a 'shot' from a 2 channel i2c driver:
http://www.panteltje.com/pub/iiclib.c
Note the IIC_BUS_DELAY, it is defined in iiclib.h:
#define IIC_BUS_DELAY 1
But you can make it as long as you want (in case of lots of cable capacitance),
as long as transient oscillations are gone by the time you toggle the next I/O.
That is why
busdly(IIC_BUS_DELAY);
is called afer each I/O pin change.
In fact on a Linux multitasker usleep() can change a lot....
man usleep
On embedded use a loop, example PIC 18F code, iicbus delay:
iicdly: ; iic bus delay
movlw D'225'
movwf iic_delay_cnt
iicdly_loop:
decfsz iic_delay_cnt
bra iicdly_loop
return
<hill@rowland.harvard.edu> wrote in <qb7vgs02cif@drn.newsguy.com>:
Clifford Heath wrote...
Winfield Hill wrote:
I miss-spoke, we're using an Atmel ARM SAM D21.
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load.
Presumably the slew-rate limiting depends on the
selected data rate, but the data sheet is pretty
quiet on that.
Here's their spec, fall time, for 0.7 to 0.3 Vdd:
typ max
Standard/Fast 20 50 ns
Fast Mode + 15 50
High Speed Mode 10 40
Yes, it changes with speed setting, but not much.
Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns.
I = C dV/dt, with 75pF, that's i = 5mA, during
a 50ns transition. This is what can kill using
twisted-pair wires in a short USB cable. If we
have 75pF crosstalk with a 200pF load, that's
still a 28% Vdd interference signal, which is
smack on the 30% trouble threshold. Why only
slow to a fast 50ns transition with a 10us bit
interval? That's only 0.5%. That's why I made
more changes and added extra stuff.
The rise - and falltime spec has little meaning, because the i2c system works differently.
Data is sampled by the clock.
As long as you wait long enough after each transition, data will be stable,
and toggling the clock during stable data a million times due to oscillations in the transient will still read that data in correctly.
I always do i2c in software.
Some years ago I had this chip with a hardware i2c interface (was it a PIC? do not remember, yes I think it was),
and a datasheet that sounded really funny to me.
So did it in software as always and it worked perfectly
Sure enough in the chip errata the i2c hardware interface was mentioned as erratic, and fixed.
So here a 'shot' from a 2 channel i2c driver:
http://www.panteltje.com/pub/iiclib.c
Note the IIC_BUS_DELAY, it is defined in iiclib.h:
#define IIC_BUS_DELAY 1
But you can make it as long as you want (in case of lots of cable capacitance),
as long as transient oscillations are gone by the time you toggle the next I/O.
That is why
busdly(IIC_BUS_DELAY);
is called afer each I/O pin change.
In fact on a Linux multitasker usleep() can change a lot....
man usleep
On embedded use a loop, example PIC 18F code, iicbus delay:
iicdly: ; iic bus delay
movlw D'225'
movwf iic_delay_cnt
iicdly_loop:
decfsz iic_delay_cnt
bra iicdly_loop
return
J
Jan Panteltje
Guest
On a sunny day (Sun, 12 May 2019 07:10:51 GMT) it happened Jan Panteltje
<pNaOnStPeAlMtje@yahoo.com> wrote in <qb8gu6$lpf$1@dont-email.me>:
Correction, maybe I spoke too soon, clock oscillations on edges may an have effect,
but it never seems to happen with capacitive loads or any loads I have tried.
<pNaOnStPeAlMtje@yahoo.com> wrote in <qb8gu6$lpf$1@dont-email.me>:
On a sunny day (11 May 2019 19:13:48 -0700) it happened Winfield Hill
hill@rowland.harvard.edu> wrote in <qb7vgs02cif@drn.newsguy.com>:
Clifford Heath wrote...
Winfield Hill wrote:
I miss-spoke, we're using an Atmel ARM SAM D21.
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load.
Presumably the slew-rate limiting depends on the
selected data rate, but the data sheet is pretty
quiet on that.
Here's their spec, fall time, for 0.7 to 0.3 Vdd:
typ max
Standard/Fast 20 50 ns
Fast Mode + 15 50
High Speed Mode 10 40
Yes, it changes with speed setting, but not much.
Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns.
I = C dV/dt, with 75pF, that's i = 5mA, during
a 50ns transition. This is what can kill using
twisted-pair wires in a short USB cable. If we
have 75pF crosstalk with a 200pF load, that's
still a 28% Vdd interference signal, which is
smack on the 30% trouble threshold. Why only
slow to a fast 50ns transition with a 10us bit
interval? That's only 0.5%. That's why I made
more changes and added extra stuff.
The rise - and falltime spec has little meaning, because the i2c system works differently.
Data is sampled by the clock.
As long as you wait long enough after each transition, data will be stable,
and toggling the clock during stable data a million times due to oscillations in the transient will still read that data in
correctly.
Correction, maybe I spoke too soon, clock oscillations on edges may an have effect,
but it never seems to happen with capacitive loads or any loads I have tried.
Guest
On 11 May 2019 15:18:46 -0700, Winfield Hill
<hill@rowland.harvard.edu> wrote:
A twisted pair typically has an impedance of 100-120 ohs and since the
transmitter has some output impedance, a smaller resistor should be
sufficient to match to the line impedance.
A 100 ohm resistor in the transmitter line will also reduce the low
state noise margin. If the current through the open drain pull-up
resistot(s) is more than 4 mA, this will reduce the low state noise
margin by 400 mV, so if a conventional TTL receiver is used, this will
kill the noise margin completely. Using 47 ohm series resistor and
limiting the drain resistor current to 2 mA and the loss of noise
margin would be only 100 mV.
I do not understand this crosstalk objections if CAT5/6 cables are
used, with one pair for SCL and other pair for SDA. After all in
100/1000BasetT Ethernet, the whole symbol time is 10 or 8 ns (not just
rise/fall time) and these cables are specified for up to 100 m.
Of course, i you have split pairs, such as running SDA and SCL in the
same twisted pair, there are going to be problems.
<hill@rowland.harvard.edu> wrote:
Rick C wrote...
Winfield Hill wrote:
Winfield Hill wrote...
Lasse Langwadt Christensen wrote...
the STM have programmable slewrate on the IOs
Aha! I'll see if our programmer can activate that.
I miss-spoke, we're using an Atmel ARM SAM D21.
Not sure if they have programmable slew rate,
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load. Well, anyway, I've added a
resistor (100-ohm) in series with the I2C lines.
A twisted pair typically has an impedance of 100-120 ohs and since the
transmitter has some output impedance, a smaller resistor should be
sufficient to match to the line impedance.
A 100 ohm resistor in the transmitter line will also reduce the low
state noise margin. If the current through the open drain pull-up
resistot(s) is more than 4 mA, this will reduce the low state noise
margin by 400 mV, so if a conventional TTL receiver is used, this will
kill the noise margin completely. Using 47 ohm series resistor and
limiting the drain resistor current to 2 mA and the loss of noise
margin would be only 100 mV.
That seems excessive. Even with a 20 ns rise time
the round trip on a 1 meter cable is around half
the rise time. I think the magic number to ignore
reflections is for the rise time to be 6 times the
round trip delay. The capacitance you can expect
on this run would very likely put the rise time
higher than this threshold so no further actions
would be needed to prevent reflections.
Yes, I agree, but my worry isn't so much about
reflections, as about crosstalk. If a fast SCL
falltime induces an SDA signal, apparently this
can cause trouble. Fix with slow falltimes.
I do not understand this crosstalk objections if CAT5/6 cables are
used, with one pair for SCL and other pair for SDA. After all in
100/1000BasetT Ethernet, the whole symbol time is 10 or 8 ns (not just
rise/fall time) and these cables are specified for up to 100 m.
Of course, i you have split pairs, such as running SDA and SCL in the
same twisted pair, there are going to be problems.
Do you think your rise time will be less than
60 ns?
Yes, according to the spec, without the resistor.
Well, OK, I do have an 74HC4052 channel switch
in series; it may be about 100 ohms at 3.3 volts.
W
Winfield Hill
Guest
upsidedown@downunder.com wrote...
Thanks for your calculations, thoughts and comments.
I had to decide against CAT5 and twisted pair. I'm
not trying to match impedances at my slow speeds, the
100-ohms is to slow falltime against 200pF of load.
The pullup resistors are 10k to 3.3V and 10k to 1.8V,
or about 0.5mA. So with 100 ohms that's 50mV, and
adding my analog switch, that's 100mV. [Actually,
the switch may be enough resistance, scope meas on
Monday may show I can skip the 100-ohms.]
> ... so if a conventional TTL receiver is used ...
The drivers and receivers are all proper I2C, with
(lousy) thresholds spec'd at 0.3 to 0.7 Vdd. For
3.3V that's 1.0V, for 1.8-volt devices, it's 540mV.
Sorry, I've been forced away from CAT5, and have
selected flat six-wire cables on RJ12. But, yes,
on opposite sides and separated by ground wires,
there likely won't be any crosstalk. I'll make
scope meas on Monday. If I leave a spot for 100
ohms on the PCB, it may be best to be 0 ohms.
--
Thanks,
- Win
Winfield Hill wrote:
Rick C wrote...
Winfield Hill wrote:
Winfield Hill wrote...
Lasse Langwadt Christensen wrote...
the STM have programmable slewrate on the IOs
Aha! I'll see if our programmer can activate that.
I miss-spoke, we're using an Atmel ARM SAM D21.
Not sure if they have programmable slew rate,
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load. Well, anyway, I've added a
resistor (100-ohm) in series with the I2C lines.
A twisted pair typically has an impedance of 100-120
ohms and since the transmitter has some output
impedance, a smaller resistor should be sufficient
to match to the line impedance.
Thanks for your calculations, thoughts and comments.
I had to decide against CAT5 and twisted pair. I'm
not trying to match impedances at my slow speeds, the
100-ohms is to slow falltime against 200pF of load.
If the current through the open drain pull-up
resistor(s) is more than 4 mA, this will reduce the
low state noise margin by 400 mV ...
The pullup resistors are 10k to 3.3V and 10k to 1.8V,
or about 0.5mA. So with 100 ohms that's 50mV, and
adding my analog switch, that's 100mV. [Actually,
the switch may be enough resistance, scope meas on
Monday may show I can skip the 100-ohms.]
> ... so if a conventional TTL receiver is used ...
The drivers and receivers are all proper I2C, with
(lousy) thresholds spec'd at 0.3 to 0.7 Vdd. For
3.3V that's 1.0V, for 1.8-volt devices, it's 540mV.
Yes, I agree, but my worry isn't so much about
reflections, as about crosstalk. If a fast SCL
falltime induces an SDA signal, apparently this
can cause trouble. Fix with slow falltimes.
I do not understand this crosstalk objections if
CAT5/6 cables are used ...
Sorry, I've been forced away from CAT5, and have
selected flat six-wire cables on RJ12. But, yes,
on opposite sides and separated by ground wires,
there likely won't be any crosstalk. I'll make
scope meas on Monday. If I leave a spot for 100
ohms on the PCB, it may be best to be 0 ohms.
--
Thanks,
- Win
C
Clifford Heath
Guest
On 12/5/19 5:16 pm, Jan Panteltje wrote:
Reflections from inductive and/or delay-line loads, i.e. not properly
terminated?
On a sunny day (Sun, 12 May 2019 07:10:51 GMT) it happened Jan Panteltje
pNaOnStPeAlMtje@yahoo.com> wrote in <qb8gu6$lpf$1@dont-email.me>:
On a sunny day (11 May 2019 19:13:48 -0700) it happened Winfield Hill
hill@rowland.harvard.edu> wrote in <qb7vgs02cif@drn.newsguy.com>:
Clifford Heath wrote...
Winfield Hill wrote:
I miss-spoke, we're using an Atmel ARM SAM D21.
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load.
Presumably the slew-rate limiting depends on the
selected data rate, but the data sheet is pretty
quiet on that.
Here's their spec, fall time, for 0.7 to 0.3 Vdd:
typ max
Standard/Fast 20 50 ns
Fast Mode + 15 50
High Speed Mode 10 40
Yes, it changes with speed setting, but not much.
Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns.
I = C dV/dt, with 75pF, that's i = 5mA, during
a 50ns transition. This is what can kill using
twisted-pair wires in a short USB cable. If we
have 75pF crosstalk with a 200pF load, that's
still a 28% Vdd interference signal, which is
smack on the 30% trouble threshold. Why only
slow to a fast 50ns transition with a 10us bit
interval? That's only 0.5%. That's why I made
more changes and added extra stuff.
The rise - and falltime spec has little meaning, because the i2c system works differently.
Data is sampled by the clock.
As long as you wait long enough after each transition, data will be stable,
and toggling the clock during stable data a million times due to oscillations in the transient will still read that data in
correctly.
Correction, maybe I spoke too soon, clock oscillations on edges may an have effect,
but it never seems to happen with capacitive loads or any loads I have tried.
Reflections from inductive and/or delay-line loads, i.e. not properly
terminated?
J
Jan Panteltje
Guest
On a sunny day (Sun, 12 May 2019 19:38:40 +1000) it happened Clifford Heath
<no.spam@please.net> wrote in <AQRBE.46022$8B4.29667@fx02.iad>:
Unless those take round the world trips those will be sufficiently attenuated
after some short time.
How fast can bees fly? Why be in a hurry?
A fly is differrent those can be really fast ;-)
But seriously, just use cable with individually screened pairs, like I used audio cable,
if you want to cover a few meters.
For more use special drivers if unidirectional (no checking of SDA pulldown).
Else go optical.
Optical fiber does not take that much space, is 'trickety proof,
a PIC as i2c to optical interface, whatever.
With wasps it would be easy, you give those individual stripes for different messages,
and use a barcode scanner, training is needed.
Other ideas ?
?
ants?
<no.spam@please.net> wrote in <AQRBE.46022$8B4.29667@fx02.iad>:
On 12/5/19 5:16 pm, Jan Panteltje wrote:
On a sunny day (Sun, 12 May 2019 07:10:51 GMT) it happened Jan Panteltje
pNaOnStPeAlMtje@yahoo.com> wrote in <qb8gu6$lpf$1@dont-email.me>:
On a sunny day (11 May 2019 19:13:48 -0700) it happened Winfield Hill
hill@rowland.harvard.edu> wrote in <qb7vgs02cif@drn.newsguy.com>:
Clifford Heath wrote...
Winfield Hill wrote:
I miss-spoke, we're using an Atmel ARM SAM D21.
but datasheet says the I2C outputs have reduced
slew-rates. Hmm, the IO spec says 20-50ns with
a 10 to 400pF load.
Presumably the slew-rate limiting depends on the
selected data rate, but the data sheet is pretty
quiet on that.
Here's their spec, fall time, for 0.7 to 0.3 Vdd:
typ max
Standard/Fast 20 50 ns
Fast Mode + 15 50
High Speed Mode 10 40
Yes, it changes with speed setting, but not much.
Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns.
I = C dV/dt, with 75pF, that's i = 5mA, during
a 50ns transition. This is what can kill using
twisted-pair wires in a short USB cable. If we
have 75pF crosstalk with a 200pF load, that's
still a 28% Vdd interference signal, which is
smack on the 30% trouble threshold. Why only
slow to a fast 50ns transition with a 10us bit
interval? That's only 0.5%. That's why I made
more changes and added extra stuff.
The rise - and falltime spec has little meaning, because the i2c system works differently.
Data is sampled by the clock.
As long as you wait long enough after each transition, data will be stable,
and toggling the clock during stable data a million times due to oscillations in the transient will still read that data in
correctly.
Correction, maybe I spoke too soon, clock oscillations on edges may an have effect,
but it never seems to happen with capacitive loads or any loads I have tried.
Reflections from inductive and/or delay-line loads, i.e. not properly
terminated?
Unless those take round the world trips those will be sufficiently attenuated
after some short time.
How fast can bees fly? Why be in a hurry?
A fly is differrent those can be really fast ;-)
But seriously, just use cable with individually screened pairs, like I used audio cable,
if you want to cover a few meters.
For more use special drivers if unidirectional (no checking of SDA pulldown).
Else go optical.
Optical fiber does not take that much space, is 'trickety proof,
a PIC as i2c to optical interface, whatever.
With wasps it would be easy, you give those individual stripes for different messages,
and use a barcode scanner, training is needed.
Other ideas ?
?
ants?
W
Winfield Hill
Guest
Martin Riddle wrote...
Interesting points. The little RJ12 cable we're
discussing is outside, totally outside. Outside
of the hive, and outside of my beehiove monitor.
If my beehive monitor goes up in flame, I'm sure
it'll outgas! It probably makes phthalates too.
Little RJ14 phone cables may not be happy with
an extended season of sunlight, but the Amazon
RJ12 data cables look like they're more robust.
--
Thanks,
- Win
On 11 May 2019, Winfield Hill wrote:
Mounted RJ45 connector, but too big, cable too
stiff, unsure of how the shielded variant works.
Went to smaller, simpler RJ12 instead.
There is plenum rated cable, it does not outgas
when burning eg; low smoke.
PVC is not too good for outdoor use.
Might want to check for RoHS/REACH compliance,
that way you will not get the phthalates.
Interesting points. The little RJ12 cable we're
discussing is outside, totally outside. Outside
of the hive, and outside of my beehiove monitor.
If my beehive monitor goes up in flame, I'm sure
it'll outgas! It probably makes phthalates too.
Little RJ14 phone cables may not be happy with
an extended season of sunlight, but the Amazon
RJ12 data cables look like they're more robust.
--
Thanks,
- Win