Presumably there will be various sensors, switches, controllers etc. in
groups which can talk amongst themselves, but not talk to other
groups because of differences in media. We need tranceivers to act as
go-betweens, and if the network has any significant complexity, those
transceivers need to be aware of routing too. It might be convenient
to choose CAN or something as the common interface so we can build
transceivers for mains-to-CAN, RF-to-CAN, IR-to-CAN etc. rather than
having to do all possible pairs of conversion, but this sort of common
interface is mostly for design convenience and need not be exposed outside
the unit responsible for the media conversion. Any sufficiently-fast
medium would do for this purpose.
What exactly is ``sufficiently-fast''? People have suggested running
audio and video over the system. Although it would be nice to cope with
digitised video, supporting such speeds would surely be prohibitive for
all devices, so we need to have multiple networks running at different
speeds. But because of the speed differences, not all combinations of
interconnection are useful without intelligent routing, and some may just
be impossible. It would seem silly to have a I2C-to-gigabit-ethernet
converter just so that we can run the backbone at a speed suitable
for all purposes. Much better would be to have several networks with
gateways between them.
In a system with pre-existing wiring, I imagine that most if not all
of the low-speed long-range communications will be done by mains or RF
(or both). In a newely-wired system, this would be done by CAN or RS485.
It would be elegant to have each terminal constructed with a media option
part and a ``works'' part, so the media option could be swapped while
the works stayed the same. If we went this way, having something simple
like or I2C as the terminal's internal bus would be a good idea as it
would allow re-use of design (and where the internal and external busses
were compatible, the media option part could be omitted). For practical
reasons (size, electrical safety, choice of embedded controllers), I
think that most media options will significantly influence the design of
the terminal anyway, so maybe having that common format isn't so useful.
> I've already browsed the net for more relevant CAN information & data
> sheets (app. notes) but apart for some vendor specs, I haven't found
> much explanation about the do's and dont's.
Found any good pointers? I'll add them to http://ha.ro.hu/links.html
Robin.
-- R.M.O'Leary <robin.at.acm.org> +44 7010 7070 44, PO Box 20, Swansea SA2 8YB, UK