Norm:

I don't know if I qualify as one of the great minds out here on the list, but I
do know that you have bit off a tough issue. You should expect to chew for a
while on it. Some of the things you need to address:

1) What is going to be the underlying logic of your protocol? Will you want this
to be a strict peer net? If so, anybody can initiate a transaction at any time,
so your response to the user is quick, but the protocol gets tough fast. You now
have to allow for the bus acquisition logic, as well as bus initialization and
error recovery. In addition, there now must be an additional layer of software
in each application module to handle all this stuff before handing off to the
app layer. Even the app layer gets messy, what with asynchronous updates and
such.

A polled net avoids many of these issues at the expense of speed. Nevertheless,
I personally think you will default to a polled architecture, if not for any
other reason just to keep it simple enough to fit in a PIC chip and be doable in
real time. (Some projects never end, they just fade away...)

2) Even with a polled architecture there are serious issues regarding timing on
the slaves. You can assume that the master is paying attention; it started
things going. But there is no such assurance for the slaves, unless you take
pains to design it in. This can get messy fast, so it's best to keep the slaves
logic simple unless you have spent a lot of time looking into the details of the
protocol before you started.

This is, by the way, why there are myriad drivers available for 2 and 3 wire
protocol masters, and few if any for slaves. Sit down and check out the
requirements for an ISP slave sometime; it can be done, of course, but it isn't
what you give to a beginner to learn on. Most 2 and 3 wire slaves are
implemented in hardware.

3) Connecting the bus isn't trivial. Your protocol will interact with the
wiring, connectors, and connection length in a serious way. A lot of efforts
leave this issue until the end, leading to a late round of debugging and
rewrites.

So, what would I do if I were going to do it? I would think seriously about
using an async serial polled system, with the net architecture hard coded, using
open collector rs232 or rs485 drivers. Let the master poll like crazy, keep the
slaves simple, set your data rate high and it should work nicely. You can let
the master simply gather information and pass it to a closely coupled slave that
does the real control work, if necessary. But I think you'll find that the
polled protocol can leave a lot of time for the app layer, if done right.

If you absolutely must look into another approach (don't let my recommendations
stop you for a minute) do just that - sit down and think hard about the issues
involved (getting smart is fun and they pay you for it) and don't start coding
until you can clearly see what's what.

Have fun.

-- Tom Rogers
______________________________________________________________

Norm Cramer wrote:

> I am using several PIC's for a control system.  The PIC's will be using the
> USART to communicate between each other and a PC.  One of the PIC's is  the
> controller, the other PIC's and the PC are "control input stations".  I was
> wondering if anyone has done a simple comm scheme.  I know I can do it by
> polling the stations from the "controller".  I would like something that
> allowed faster response.  For example, if a user adjusts a control, in the
> polling scheme it will have to wait till the next time that station is
> polled to update the "controller".  Polling stations that do not have data
> seems like a waste of time.  BTW polling limits my devices to about 12 if I
> can tolerate a 500msec delay from input to response (this is really kinda
> high for this application).  I would like to handle more devices and have
> better response time.  The user can only update things so fast.  Typically
> ony a few users would be adjusting thier controls at the same time.  I have
> some ideas of how to solve this but would like some more solutions from the
> great minds out there on the list.
>
> Thanks,
>
> Norm