question: multiple crystals or one?

[DJ Delorie]

Relating to EMI and/or reliability. Refresher: this board will be
bolted to my furnace, to control it and the central air. Yeah, I'm
still working on it. Old board: http://www.delorie.com/house/furnace/

Background: the board has six MCUs on it. One is a gumstix (200 or
200MHz XScale). Four are R8C/1B's and one is a R8C/26. These five
R8C's use a 20MHz crystal clock source (the usual xin/xout setup).
I've currently got five crystals on the board, one next to each MCU.
The crystals are almost as big as the chips! It's a four layer board.

The question is: Is it better to have one crystal per MCU, right at
the MCU, or to have one master clock and run it to each MCU? The
distance is about four inches, and the MCU's don't have to be
synchronized (they talk over I2C). My primary concern is correct
operation of the board, as it's in a high-noise environment, so I'm
wondering if the five crystals are going to mess each other (or
anything else) up, or if the long clock line is going to pick up EMI,
and which is the worse of the two.

DJ

 

[John Devereux]

Relating to EMI and/or reliability. Refresher: this board will be
bolted to my furnace, to control it and the central air. Yeah, I'm
still working on it. Old board: http://www.delorie.com/house/furnace/

Background: the board has six MCUs on it. One is a gumstix (200 or
200MHz XScale). Four are R8C/1B's and one is a R8C/26. These five
R8C's use a 20MHz crystal clock source (the usual xin/xout setup).
I've currently got five crystals on the board, one next to each MCU.
The crystals are almost as big as the chips! It's a four layer board.

The question is: Is it better to have one crystal per MCU, right at
the MCU, or to have one master clock and run it to each MCU? The
distance is about four inches, and the MCU's don't have to be
synchronized (they talk over I2C). My primary concern is correct
operation of the board, as it's in a high-noise environment, so I'm
wondering if the five crystals are going to mess each other (or
anything else) up, or if the long clock line is going to pick up EMI,
and which is the worse of the two.

I have not had this scenario, but I would have thought separate
crystals would be better from a susceptibility point of view, since
you can then avoid a long unfilterable trace. Can you use the built-in
oscillators instead of the external crystal?

I have tried microprocessor control of gas igniters and they do indeed
generate very nasty spikes. Main problem is likely to be conducted
interference via the wires connected to the board. Suggest groundplane
construction. Where safe, all incoming wires have TVS diode or MOV to
groundplane, then RC or LC filter, all near board connector.

 

[DJ Delorie]

Can you use the built-in oscillators instead of the external
crystal?

The built-ins are slower (8MHz vs 20MHz) and not as precise (5% vs
0.5%). I don't know how fast or precise I need, but I'm planning for
worst-case, since I need to bit-bang a 1wire interface (using timers
and interrupts, of course) with four of them.

I have tried microprocessor control of gas igniters and they do indeed
generate very nasty spikes.

In my case, the furnace has an electrostatic filter in it. I.e. big
spark generator.

Main problem is likely to be conducted interference via the wires
connected to the board. Suggest groundplane construction. Where
safe, all incoming wires have TVS diode or MOV to groundplane, then
RC or LC filter, all near board connector.

Yup, I've got all that. 12MHz LCL low pass, dual schokty diodes for
clamping, RC matrix for signal conditioning, in that order. The board
is very space-constrained.

Here's the schematics for one of the zones:
http://www.delorie.com/house/furnace/pcb2/zone1.pdf

The "SMD*" symbols are unassigned 0603 footprints so I can fiddle with
the actual filter later, and/or reuse the board for other protocols.

And the board-so-far:
http://www.delorie.com/house/furnace/pcb2/board-2007-01-08-1.pdf

You can see the crystal resonators next to U100, U200, ... U500. U10
is the gumstix.

 

[John Devereux]

The built-ins are slower (8MHz vs 20MHz) and not as precise (5% vs
0.5%). I don't know how fast or precise I need, but I'm planning for
worst-case, since I need to bit-bang a 1wire interface (using timers
and interrupts, of course) with four of them.


In my case, the furnace has an electrostatic filter in it. I.e. big
spark generator.


Yup, I've got all that. 12MHz LCL low pass, dual schokty diodes for
clamping, RC matrix for signal conditioning, in that order. The board
is very space-constrained.

Here's the schematics for one of the zones:
http://www.delorie.com/house/furnace/pcb2/zone1.pdf

It looks to me like the mosfets could turn on at the same time and
short out the +5V? Unless I've mixed up my drain and source.

The "SMD*" symbols are unassigned 0603 footprints so I can fiddle with
the actual filter later, and/or reuse the board for other protocols.

And the board-so-far:
http://www.delorie.com/house/furnace/pcb2/board-2007-01-08-1.pdf

I did some experimentation once, with different transient suppression
arrangements, to find the "best" one. For big fat sparks direct to the
I/O terminal, I found it was best to have a TVS diode directly at the
terminal. This then limited the peak voltage to a reasonable level, so
that an RC or LC filter could operate. If the TVS is after the filter,
there is a risk that the spark can just jump over the filter
component. If this did ever happen, I wonder if conducting it to +5V
via the Schottky diode is a good idea? Perhaps OK given the powerplane
construction.

Actually I don't see that happening for you, looks like any arc would
go the central ground connection of the LCL filters.

You can see the crystal resonators next to U100, U200, ... U500. U10
is the gumstix.

You've got a lot of CPU's there! I would think you could have got away
with an ARM7 for the whole thing... but then I don't know exactly what
it all does!

 

[John Larkin]

Relating to EMI and/or reliability. Refresher: this board will be
bolted to my furnace, to control it and the central air. Yeah, I'm
still working on it. Old board: http://www.delorie.com/house/furnace/

Background: the board has six MCUs on it. One is a gumstix (200 or
200MHz XScale). Four are R8C/1B's and one is a R8C/26. These five
R8C's use a 20MHz crystal clock source (the usual xin/xout setup).
I've currently got five crystals on the board, one next to each MCU.
The crystals are almost as big as the chips! It's a four layer board.

The question is: Is it better to have one crystal per MCU, right at
the MCU, or to have one master clock and run it to each MCU? The
distance is about four inches, and the MCU's don't have to be
synchronized (they talk over I2C). My primary concern is correct
operation of the board, as it's in a high-noise environment, so I'm
wondering if the five crystals are going to mess each other (or
anything else) up, or if the long clock line is going to pick up EMI,
and which is the worse of the two.

DJ

Why would anything this slow need 6 uPs?

John

 

[DJ Delorie]

It looks to me like the mosfets could turn on at the same time and
short out the +5V? Unless I've mixed up my drain and source.

Unless *I* mixed them up. The idea is that the opamps and resistor
divider guarantee that there's a dead zone in the middle. When the
MCU line is high, the top mosfet pulls the line high. Then the MCU is
low, the line is pulled low. When the MCU tri-states, neither mosfet
should conduct, and the line is tri-stated.

Yup, it's a tri-state booster.

I did some experimentation once, with different transient suppression
arrangements, to find the "best" one. For big fat sparks direct to the
I/O terminal, I found it was best to have a TVS diode directly at the
terminal.

I'll see if I can fit one in.

Actually I don't see that happening for you, looks like any arc
would go the central ground connection of the LCL filters.

Mostly I pick up inducted spikes, not direct sparks.

You've got a lot of CPU's there! I would think you could have got away
with an ARM7 for the whole thing... but then I don't know exactly what
it all does!

It's replacing the relay board that came with the furnace. The
current board (also a replacement) has a PC on the floor running the
show using busy loops, but it's (1) too sensitive to EMI, and (2) too
slow. The 1wire bus is shared among 12 pushbuttons and 4 sensors, so
the temperature polling is limited to a few times a minute, and it
takes 1-2 seconds for it to notice that you pushed a button.

The new one has each 1wire bus controlled by an MCU, using timers.
Each MCU knows what the protocol for the wires is (1wire, serial, PPP,
etc) to talk to the thermostats, and mostly manages the timing, plus
some preliminary calculations. The results go to the gumstix, which
runs Linux, so the timing is less precise but it's a lot more
flexible.

The r8c/26 is just a big I/O port with zero crossing logic (60Hz PLL)
so that (1) the furnace can be reset to a known state ASAP when the
system boots, and (2) because the ZC optos I looked at had a trigger
voltage of 35v, and this is only a 24v system. Plus it can refresh
the outputs more often to prevent latch changes due to EMI.

The r8c's are only a few dollars each, I'm basically using them as
programmable peripherals.

 

[DJ Delorie]

Why would anything this slow need 6 uPs?

Why not? ;-)

Like I said in my other email, I'm using them as programmable
peripherals. They're cheap and small, which makes them efficient for
managing line signalling. Also, the more logic I have between the
outside world and the expensive gumstix, the better. I'd rather
replace a $4 mcu than a $130 gumstix. Of course, I'd rather replace a
20 cent clamp diode ;-)

In the future, I'll put MCUs in the thermostats too (to poll the
buttons and sensor, and drive the LCD), bringing the total to 9 uPs
just to run the furnace

 

[Tim Shoppa]

Why not? ;-)

Like I said in my other email, I'm using them as programmable
peripherals. They're cheap and small, which makes them efficient for
managing line signalling.

Do you need crystal accuracy for the signalling? A resonator, or even
better the built-in oscillator could do fine for many protocols.

You haven't necessarily gone overboard: TAPR recently announced a
product (the FatPPS) that is a 74123 one-shot but costs $49 and comes
with a manual filled with many many drawings .

Tim.

 

[Jonathan Kirwan]

Why not? ;-)

Like I said in my other email, I'm using them as programmable
peripherals. They're cheap and small, which makes them efficient for
managing line signalling. Also, the more logic I have between the
outside world and the expensive gumstix, the better. I'd rather
replace a $4 mcu than a $130 gumstix. Of course, I'd rather replace a
20 cent clamp diode ;-)

In the future, I'll put MCUs in the thermostats too (to poll the
buttons and sensor, and drive the LCD), bringing the total to 9 uPs
just to run the furnace

I think putting MCUs into the thermostats is sensible, as it follows
the physical and real dimension lines of the problem you are solving.
Thermostats exist physically separate from the furnace controller,
itself. Dividing along those lines is following the natural problem
lines.

That is NOT a necessary argument for putting a linux box and 6 MCUs
into a furnace controller box. That's a separate question. Not being
as familiar as you are with your application, it still doesn't sound
like the approach I think I'd take. (But perhaps you are considering
important lines of hot-replaceable modules though that doesn't seem
the case when talking about sharing a clock module.) What _does_ make
sense to me is that your choice to use the gumstix forced your choice
of using at least one external MCU and that once you embraced that
idea fully, making that more than one was like falling off a log. But
this seems more a decision driven by choosing to use an operating
system environment whioh then drove other necessities -- none of which
were really driven by the core problem itself.

Jon

 

[DJ Delorie]

Do you need crystal accuracy for the signalling? A resonator, or even
better the built-in oscillator could do fine for many protocols.

I'm using Panasonic's EFO-BM series (ok, they're resonators, doesn't
change the EMI question), which are very small and have the load caps
built-in. The whole thing is 160x120 thou, and only 72 cents each.
Accuracy is 0.5%, not as good as the 5ppm crystals I use for ethernet,
for example, but far better than the 5% for the built-in clock.

I'm just thinking that 5% (the built-in oscillator) may not be good
enough for 1wire or RS-232. A 9600 baud link at 10080 baud? Or 9120
baud? The chip's bootloader even has - as part of the programming
procedure - a calibration loop! You send it 16 NUL bytes and it
adjusts its baud generator to match it, because it's usually off by
too much by default.

 

[John Devereux]

Why not? ;-)

Like I said in my other email, I'm using them as programmable
peripherals. They're cheap and small, which makes them efficient for
managing line signalling. Also, the more logic I have between the
outside world and the expensive gumstix, the better. I'd rather
replace a $4 mcu than a $130 gumstix. Of course, I'd rather replace a
20 cent clamp diode ;-)

Yes but you can do the whole thing with the $4 MCU

 

[DJ Delorie]

That is NOT a necessary argument for putting a linux box and 6 MCUs
into a furnace controller box.

I never said anything about necessary. It's partly for fun. When
people see how many PCs I have in my office, I can look at them and
say "Dude, this is nothing. I have 9 computers running my furnace."

What _does_ make sense to me is that your choice to use the gumstix
forced your choice of using at least one external MCU and that once
you embraced that idea fully, making that more than one was like
falling off a log. But this seems more a decision driven by
choosing to use an operating system environment whioh then drove
other necessities -- none of which were really driven by the core
problem itself.

The core problem was "I need something smarter than bi-metal switches
running my $1000 central air conditioner motor". We burned out the
first one pretty quickly, due to short on-off-on cycles.

The only restriction I'm giving myself is that the board must fit in
the existing enclosure, even though it would be easy to just bolt a
new one on. It's more challenging that way. Everything else is
flexible.

The first pass was to put a PC there, with the minimum logic needed to
interface with the furnace. Unfortunately, a 200MHz pentium talking
to a furnace with a long ribbon cable just isn't a good solution, for
various reasons. See http://www.delorie.com/house/furnace/

I originally planned board #2 to have a single M32C running
everything. It has enough peripherals in it to manage all the line
signalling in hardware (it's got 11 or so timers and 5 serial ports).
I prototyped a ram/ethernet board for the m32c to prove out those
circuits, but decided to go with a gumstix as it vastly simplifies the
programming - I can reuse the linux stuff running on the PC.

Plus, running linux gives me a web server (statistics and control),
the ability to live update the software via ssh, etc. The control
software is more complex than a regular furnace, and I have more
features planned (proactive heat/cool based on weather forecasts,
weather forecasts shown on the thermostats' LCDs, etc).

Also, I work for Red Hat, so having a furnace that runs Linux is a
prestige thing ;-) My furnace currently runs Fedora Core 4:

dj@envy pts/0 ~
$ ssh furnace
Last login: Mon Dec 11 22:04:41 2006 from delorie.com
[root@furnace ~]# /furnace/sw/console

/ MBR 69.90 F 43.1 % OPEN 16:30:27
/ DNS 72.56 F 36.7 % OPEN 16:30:31
/ UPS 70.36 F 41.1 % OPEN 16:30:19
/ EXT 40.63 F 90.5 % 16:30:23
/ ---- ---- --- ----- winter 16:30:16
16:30:32

[root@furnace ~]#

That's just cool.

The latest furnace applet calculates how much money I've spent for oil
this year so far, compared to last year, based on how many hours the
furnace was running, relative to average outside temperature.

And it turns out the hard part is the EMI anyway! The multi-uP setup
was trivial compared to the I/O circuitry.

 

[PeteS]

Relating to EMI and/or reliability. Refresher: this board will be
bolted to my furnace, to control it and the central air. Yeah, I'm
still working on it. Old board: http://www.delorie.com/house/furnace/

Background: the board has six MCUs on it. One is a gumstix (200 or
200MHz XScale). Four are R8C/1B's and one is a R8C/26. These five
R8C's use a 20MHz crystal clock source (the usual xin/xout setup).
I've currently got five crystals on the board, one next to each MCU.
The crystals are almost as big as the chips! It's a four layer board.

The question is: Is it better to have one crystal per MCU, right at
the MCU, or to have one master clock and run it to each MCU? The
distance is about four inches, and the MCU's don't have to be
synchronized (they talk over I2C). My primary concern is correct
operation of the board, as it's in a high-noise environment, so I'm
wondering if the five crystals are going to mess each other (or
anything else) up, or if the long clock line is going to pick up EMI,
and which is the worse of the two.

DJ

I've read all the others, but here's my take:

If the stuff is relatively slow [which it is], then a single high drive
buffer should not be significantly enough affected by local EMI and it
would be a whole lot cheaper than all those resonators / crystals.

I'd go with a single oscillator and a driver (if it needed one), for
price, board objects and not having to worry about loading caps.

Cheers

PeteS

 

[Jim Thompson]

I never said anything about necessary. It's partly for fun. When
people see how many PCs I have in my office, I can look at them and
say "Dude, this is nothing. I have 9 computers running my furnace."

[snip]

You'd fit right in at General Motors ;-)

...Jim Thompson

 

[John Devereux]

Unless *I* mixed them up. The idea is that the opamps and resistor
divider guarantee that there's a dead zone in the middle. When the
MCU line is high, the top mosfet pulls the line high. Then the MCU is
low, the line is pulled low. When the MCU tri-states, neither mosfet
should conduct, and the line is tri-stated.

Yup, it's a tri-state booster.

Aha I see what you are doing there now. In fact looking at
<http://www.delorie.com/house/furnace/pcb2/io_port.html> I think I
once "invented" a similar looking thing as one half of a h-bridge
motor driver, using bipolar transistors instead of fets!

Still not 100% sure what happens during the transition though.

I'll see if I can fit one in.


Mostly I pick up inducted spikes, not direct sparks.

Don't bother then, I don't see it will make much difference in that
case. My problem was big bad ESD events: literally sparks going to the
input.

 

[DJ Delorie]

Still not 100% sure what happens during the transition though.

Ok, now I'm worried. From the pdf, top circuit...

When P1_4 is higher than 2.235V, U102-6 is higher than U102-7, so
U102-1 is low. U102-4 is higher than U102-5, so U102-2 is low. Now,
a low on T100-G turns it ON and a low on T101-G turns it OFF, so
SMD100 sees a HIGH.

When P1_4 is lower than 1.065V, U102-7 is higher than U102-6, so
U102-1 is high, so T100 is OFF. U102-5 is higher than U102-4, so
U102-2 is high, and T101 is ON, so SMD100 sees a LOW.

When P1_4 floats, R100/R103 pull it to 1.65v. U102-7 is 2.235V, so -7
is higher than -6, so U102 is HIGH and T100 is OFF. U102-5 is 1.065V
so -5 is less than -4, so U102-2 is LOW and T101 is OFF. Thus, SMD100
is not connected to anything.

No problems with the wiring (whew).


Yes, at high switching speeds there may be a nanosecond where they're
both on (the comparators switch in under 0.7ns, and they're push-pull,
so a 1-2ns rise time is enough to avoid most of the overlap). Regular
CMOS IC's do this too; that's part of where the switching spikes come
into play, and one reason why higher clock speeds means more power
consumed.

Hmm, I probably should add a bypass cap right at the mosfets, yes?

 

[DJ Delorie]

Aha I see what you are doing there now. In fact looking at
<http://www.delorie.com/house/furnace/pcb2/io_port.html> I think I
once "invented" a similar looking thing as one half of a h-bridge
motor driver, using bipolar transistors instead of fets!

Actually, I looked at H-bridge chips before doing my own.

 

[John Devereux]

Ok, now I'm worried.

Then my work is done...

From the pdf, top circuit...

When P1_4 is higher than 2.235V, U102-6 is higher than U102-7, so
U102-1 is low. U102-4 is higher than U102-5, so U102-2 is low. Now,
a low on T100-G turns it ON and a low on T101-G turns it OFF, so
SMD100 sees a HIGH.

When P1_4 is lower than 1.065V, U102-7 is higher than U102-6, so
U102-1 is high, so T100 is OFF. U102-5 is higher than U102-4, so
U102-2 is high, and T101 is ON, so SMD100 sees a LOW.

When P1_4 floats, R100/R103 pull it to 1.65v. U102-7 is 2.235V, so -7
is higher than -6, so U102 is HIGH and T100 is OFF. U102-5 is 1.065V
so -5 is less than -4, so U102-2 is LOW and T101 is OFF. Thus, SMD100
is not connected to anything.

No problems with the wiring (whew).

Yes, the "wiring" looked OK to me too I was just not sure about that
transition. I made a motor driver that blew itself up like
this. Several times...

Yes, at high switching speeds there may be a nanosecond where they're
both on (the comparators switch in under 0.7ns, and they're push-pull,
so a 1-2ns rise time is enough to avoid most of the overlap).

Wow, that's pretty fast (remember the FETs will appear to have a
bigger effective gate capacitance due to the miller feedback). If they
are 2N7002 type things with high on resistance I shouldn't think they
will notice. But I know some of the modern FETS have on resistance
measured in milliohms, and high gate capacitance that slows them
down. Perhaps they will end up half-on, taking just enough current to
pull down the supply to the gate threshold, till they ignite!

Regular CMOS IC's do this too; that's part of where the switching
spikes come into play, and one reason why higher clock speeds means
more power consumed.

Hmm, I probably should add a bypass cap right at the mosfets, yes?

I don't think it will make much difference with a powerplane
construction. The impedance will already be lower than that of a
cap. Wouldn't do any harm though, or perhaps a small series resistance
+ cap.

 

[DJ Delorie]

Wow, that's pretty fast

You're right, it was uS, not nS. Now I know why you're worried.

So... An RC filter on the GPIO pin to slow it down to match the
comparator's speed?

 

[krw]

I never said anything about necessary. It's partly for fun. When
people see how many PCs I have in my office, I can look at them and
say "Dude, this is nothing. I have 9 computers running my furnace."

I certainly hope you have no CO or fire issues, or ever want to
sell the house. The furnace is one thing I do *not* mess with.
Forgetting the above, I like warm when it's furnace season (hot
showers are good even in the summer).

<snip>