CasaDelGato Systems

Brett Paulin wrote:

> I hope I don't step on any toes by stepping outside the current
> hardware ideas on the EViL bus

No problem. We're all learning, and just trying to make things that
work. *And*, trying to perfect and document them well enough so others
will build on the work, rather than inventing their own solutions.

> I'm not certain that the EViL approach of trying to make a low baud rate
> rs-232 channel into a many-node opto-isolated system is going to be a
> nontrivial task.

There is no relationship between RS-232 and Evilbus. Both are hardware
standards that do not specify the data format. They (and I2C, RS-485,
USB, and so many other standards) can be thought of as the "road" for
moving the data.

> It looks like you are going to have to spend a lot of time massaging
> the bus bits into shape with opto's of carefully chosen
> characteristics, and dealing with all sorts of transmission line
> coupling theory issues, which probably isn't an area you want to get
> bogged down in, comms bus-driving is a science in itself, its the the
> higher level functions are where the innovation is wanted.

The idea of a low-speed bus is to *avoid* all these problems. At low
speeds, transmission line effects don't matter, slow inexpensive parts
work, wiring is non-critical, power requirements are low, etc.

My hope is that people *don't* "overclock" the bus and try to jam too
many nodes, too much data, and too high a speed onto it. Keep it simple,
and Evilbus is cheap and easy, and works well.

Problems come when you take something designed for low speeds and try to
make it run at high speeds anyway. It's like saying, "Your 100 lbs test
rope is no good -- it broke when I tried to pick up 200 lbs with it. So
I designed my own."

> I just spent a few months surveying a variety of communication bus
> possibilities for a vehicle control network - including Can, Lin,
> 1-wire, Zigbee, Mod and others, and my current favourite candidate
> under test is a buffered I2C bus with a packet-CRC and retransmit
> logic added at the protocol layer to cope with any errors.

I would encourage you to experiment with these other buses in a test in
a real EV, where you have a 50 KW motor controller operating, and the
various bus wiring tangled in with it. The noise problems become fierce!
No normal desktop computer bus can operate in such an environment.

> I2C can be fast or slow (Clock-stretched-100Kz to 3.4mbps)

What you call "slow" I2C (100 KHz) is already 10x the speed of the 9600
baud people are using for Evilbus. This means you can expect about 10x
the noise problems. At 100 KHz, you need expensive optocouplers. To get
this speed, they tend to require higher power levels, too.

> it is a well defined multi-master protocol with all the
> potential bus timing issues already studied and resolved

Yes, for the NON isolated case. However, I2C is almost never isolated.
It is really intended for chips on the same PC board to talk to each
other -- not for long distance communications in noisy isolated
environments.

Another issue is that I2C is a binary protocol. It is unintelligible to
mere humans. A goal with Evilbus is to use plain ASCII data, designed to
be human-readable. "B1=12.6v", not "FC345D17".

> The bus-buffer chip is the key.. Without it, I2C is only useful for
> short-run few-node networks due to its bus-drive-current capabilities
> limiting the capacitance that can be handled in the cabling. Add a
> bus-buffer that can pump tens of milliamps down the cable and
> capacitances messing up your waves becomes much less of a problem.

Except, 10's of ma per per node can run your car's batteries dead fairly
soon. Modern cars use things like CANbus -- another relatively fast
high-power bus. Modern cars will kill their 12v battery in less than a
month from the parasitic loads of all these networked microcontrollers.

> It also enables driving opto's for isolation, handles differences in
> ground potentials across nodes, adds noise and ESD protection and
> generally makes handling long-run links much easier to implement
> without too much futzing about with bit-control details.
>
> The particular buffer I am considering at present is the P82B96 -
> although there seem to be a few options, thats the one I like the
> look of so far.

It's a good part if you have already mandated I2C; but I don't think I2C
is right for the application. Also note that this chip alone costs more
and uses more power than all the Evilbus parts for a node put together.

> I'm trying RJ45 UTP on the physical layer, which means you can buy
> standard cheap network patch cords to link the modules together, and
> connectors are already availble in harsh-environment versions if
> required.

These connectors aren't built for outdoor or automotive use. The I2C
system also requires twice as many wires per node, which increases the
number of failure points.