Searching \ for 'On topic for a change: PIC Networking' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'On topic for a change: PIC Networking'.

Truncated match.
PICList Thread
'On topic for a change: PIC Networking'
1999\03\13@011604 by Bob Drzyzgula

flavicon
face
I'd like to pick y'all's brains for a minute if it's
not too much trouble. I'm working on an application to
provide instrumentation to a wide variety of computer,
storage and communications systems in a data center
environment. (* see footnote below if you want more info
on exactly what.) I want to keep tabs on temperatures,
current loads, fan status, and such.  I also want to pick
up whatever external signals the systems *do* give me and
feed them back to a monitoring server (E.g. Kingston RAID
enclosures have headers in them that will close if there's
been various sorts of failures).  In addition, I want to
put relays on e.g. ATX soft power on/off and reset headers,
so that I can toggle those things remotely.

Now, most of the design aspects of this are straightforward
and I don't have much trouble with that. I expect to
have little PIC-based probes in each monitored device,
reporting back to (and taking commands from) a two-tier
(distributed probe managers and the top-level management
server) hiearchy of Unix (probably Linux) monitoring
and control severs.  But there is one part of this that
I'm having trouble seeing which way to go, and that's
networking the the PIC-based probes.

To some extent, the answer seems obvious to me: RS-485 (I
suppose that I2C would also be an option). But my problem
with that is that all this gives me is the electrical
connection. I need a protocol to place on the net,
and I would much rather not re-invent the wheel if at
all avoidable. Optimal, in my mind, would be if there
was a library package that I could simply call from my
application code, or which called my application code.
I've been putting off dealing with this in hopes that it
would become obvious to me (in case you couldn't tell,
this is an in-house application and I don't really have
a deadline for it, it will just make our jobs easier if
I can make it work, and I suppose I could look into
some pre-fab DIN rail sensor network, but that wouldn't
be any damned fun) but unfortunately this answer hasn't
yet jumped out at me; I suppose that I'm just thick.

One other complicating factor is that, in some circumstances,
I'd like to be able to put a probe in a "streaming mode",
where I could set up a "virtual circuit" of sorts that
would allow the PIC-based probe to dump a whole bunch of
data down the pipe without the risk of being interrupted
by another station. This would be useful if, for example,
there was a few KB of data on a monitored system that the
PIC needed to forward on to the management station; clearly
the PIC can't buffer all that much data without resorting
to external RAM or eeprom; but it could shovel it from
one side to the other without much difficulty.

I've dug and dug on the web and at websites, but I'm not
having a lot of luck. It seems as if, when it comes to
RS-485, most people just roll their own protocol. (Possible
here, but a lot of work for just this one application,
and potentially a major source of code revision). CAN
seems as if it would fit, but it isn't clear how far
this has gotten out of Microchips marketing department
and into the engineering labs... see the link (**) below;
first quarter is almost up, guys... (I did note a PICLIST
discussion on Microchip's CAN products from last December,
the conclusion mostly being that CAN is potentially cool
but expensive and limiting, and most people who responded
were more inclined to roll their own).

emWare's EMIT stack (http://www.emware.com) seems another
likely kind of thing, and in fact it seems pretty darned
intriguing; the EMIT SDK is only about $350, which seems
quite affordable.  However, the words on  PIC support seem
pretty darned squishy; it seems as if they had version 2.5
of EMIT running on a PIC16C74 about a year or so ago,
but that the support for that chip hasn't been carried
through to the new 3.0 version of the EMIT SDK. (Anybody
know anything about this?) The other problem I have with
this is that master end of EMIT is at best Windows NT;
I would much, much rather have a Unix-based control
stations (mostly because of my 15 years of using Unix
and the fact that Windows isn't multi-user in the same
way).

I've seen other packages advertised with various levels
of apparent relevance, but I've had trouble finding one
that held up under close examination.

So I guess the question I have for y'all is: Can you
make any suggestions here? What would you use? If the
answer is "my own protocol", do you sell it? :-) I'm
not necessarily looking for a free solution here,
just one that will work and save me a bunch of time.

Basically, what I'm looking for is a serial network/
protocol architecture with packaged software that
would support things such as the following:

* Stringing several PICs together in a bus network;
 across several buses, maybe 200-400 probes would
 need to be supported.
* At least 10kbps (~9600 baud) bandwidth per supported
 probe; 56kbps or more would be ideal. I imagine
 having only one transmitter and one reciever at
 a time, so the maximum data rate on the net itself
 doesn't have to be all that high. Although being
 able to interleave several virtual circuits at
 the same time would be real useful; this would
 be more a matter of maintaning state information
 rather than dealing with CSMA/CD type overhead;
 limiting this so that, say, all open current
 virtual circuits had to have the same master
 would probably be reasonable. Thus, if the
 master was a Unix system, you could have multiple
 users and processes pulling data from multiple
 sensors...
* Streaming support to pull large blocks of data off
 a single probe in a single transaction. (~10KB,
 say... a few seconds worth, anyway)
* Only one bus master at a time would be required,
 but it would be nice if a probe could just up and
 transmit a message onto a quiet bus without having
 to wait to be polled.
* Only short distances need to be handled, maybe 10-15
 meters at most, but this would be passing through
 EMI hell.
* Unix, especially Linux/X86, support is all but
 mandatory (as a target networked platform; I can
 deal with Windows as a develoment platform -- I
 don't like it, but I can deal with it).
* The bus master must be able to send control requests
 downstream to the probes. (Duh).

Thanks for any ideas or assistance that you can
offer, and sorry for being so long-winded.

--Bob

(*) We currently have about 25 40U (70") 19" machine racks
and will have an addtional 10 by mid-year; there will
be hundreds of devices to monitor, for example dozens
of UltraSPARC Unix servers, RAID storage enclosures,
Gigabit Ethernet switches, NT servers, etc. Most of
these devices are being integrated in-house, so we're not
talking RAS-enhanced Compaqs or anything like that. And
while many devices have integrated monitoring capabilities
(LM75s and the like), many do not and the ones that do have
widely varying interfaces, and in most cases can only be
monitored in-band with the operating system (not much good
if the system hangs up -- how do you remotely reset a dead
server over the network?). Most of these systems fall into
the mission-critical category, and we spend altogether
too much time in reactive mode, running down to the data
center to examine a sick system. I want to build in as
much early warning as is possible on things like fan
failures and A/C circuits pushing their limit. We also
have trouble with systems that have designed-in redundancy
(dual power supplies, or RAID-5 systems with multiple hot
spares) and the we don't get notified when the redundancy
is lost so that we can effect repairs before the system
fails altogether. I need to detect, if possible, when
these things happen.


(**) Microchip CAN press release:
http://www.microchip.com/10/Edit/pRelease/PR89/index.htm

--
============================================================
Bob Drzyzgula                             It's not a problem
spam_OUTbobTakeThisOuTspamdrzyzgula.org                until something bad happens
============================================================

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...