On Sun, May 17, 2009 at 01:11:03PM -0400, solarwind wrote:
> I very much appreciate all of your suggestions and responses. Since  I
> can not target just one or two emails, I will post without a quote.

Good idea.

> 
> I have found a site which discusses all the different types of
> protocols: http://www.ece.cmu.edu/~koopman/protsrvy/protsrvy.html

Interesting read.

> I think that for my purposes, the token bus type works very well
> because each node is guaranteed voice every x milliseconds (depending
> on the number of nodes on the bus).

As stated in other posts, the biggest issue is managing a lost token. Any
token mechanism trusts each node to do their job properly. If any node
screws it up, the network locks up permanently.

> However, the CSMA/CD seems to be tempting as it is simple to implement
> and it works most of the time. However, the problem there is "how to
> detect collisions". My idea was to listen to your own transmission and
> ensure they are equal (by enabling the receiver and driver of the
> RS485 chip), but multiple people said this is not a good way to detect
> collisions. I don't know how else to do it.

There's no effective way to do it with async transmissions. Two nodes
driving the line asyncronously can cause all types of funky effects.

The best way to manage collisions is simply not to have them.

> I also looked at uLan. What kind of network is it?

>From first glance it's a rotating reservation slot system that uses the
break character to seize the line and manage line arbitration. Slot
reservation based on the previous master makes it pseudo token passing when
all nodes are busy. Not a bad design overall.


> And the polling type of network seems to be another cool choice where
> the bus owner polls the devices to see if anyone wants to talk. What
> happens when the bus owner goes down?

You have to have some sort of election of a new bus owner. You rejected the
polling solution a while ago when someone suggested a single master. That's
what a polling system is.

> Similarly, I could attach a bus owner node to my network as described in
> the first post, to act as a registrar. It would keep track of the token,
> and if it gets lost, reboot the network. Would that work?

Still gives a single point of failure, which is why some type of slot
reservation system seem to be inherently better even if it's just to
reestablish the token. The nice thing about token passing is that you don't
have to wait for a timeout to occur in order to select the bus, because the
receiver of the token is automatically granted bus ownership. But if the
token holder dies or the token is corrupted, then regaining control with a
slot reservation system gives a much more robust chance to rebuild the
token network than pinning the responibility on a single node. The one
thing about any token passing system is that the network will be busy at
all times, even if nothing is happening other than passing the token. So if
the network goes idle, then the token is lost. Every node has a idle
network timeout of ID+some delay characters (say 10 for the sake of
argument). So for node #1 if the network is idle for 11 character slots,
then it will start to rebuild the token network. The problem is that #1
doesn't know who's the next to pass the token. So #1 broadcasts their ID
and then removes itself from participating in the rebuild. So on the next
timeout, the next lowest node will pick up the stick and so forth. It's
slow sledding to get the token net rebuilt, but it can be done and be done
even in the face of some nodes bring down.

uLan seems to be a good compromise allowing for line arbitration at any
time. But there's a cost for non deterministic arbitration.

BAJ
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist