On Mon, Jul 23, 2001 at 04:12:43AM +0200, Patrick J wrote:
> From: "Byron A Jeff"
> > On Sat, Jul 21, 2001 at 05:35:54AM +0200, Patrick J wrote:
> > > I might be totally off but how about _avoiding_ collision instead of
> detecting it ?
> > > Say all pics on the bus have ID:s #1..#5, and that also represent their
> priority on the bus.
> > > Now, for a pic to be allowed to send it must wait the number of mS that is
> equal to its
> > > ID number (2mS for pic with ID=2 in this example) AFTER the LAST detected
> > > transmission on the bus, before it starts to send.
> > > In principle a low priority pic can be 'starved' (no data) but if one can
> asume
> > > the high priority pics can behave and not take up all of the bus it should
> work.
>
> > It's always better if the protocol guarantees that starvation won't occur
> > instead of making it voluntary for high priority nodes behave.
>
> Not always; that costs more and is more complicated ?

The costs are pretty much the same. The only difference is that instead of
handling priority/fairness in the applications layer, it is handled at the
data link layer.

> This idea is intended for a friendly bus (low traffic)

A situation that can get very unfriendly if for any reason that application
decides it needs to transmit all the time. With the secondary slot scheme
everyone is bandwidth limited.

>
> > Take a look back earlier in this thread when I proposed a secondary slot that
> > comes after all of the primary slots. Each node moves to that slot after
> > transmitting from the primary slot. These secondary nodes remain in that mode
> > until no primary wants to transmit. Then all of the secondaries can move back
> > to their primary slot. This enforces fairness when all the nodes want to
> > transmit and is more efficient than token ring when nodes do not need to
> > transmit.
> > But I agree that collision advoidance is a good idea.
>
> Well, I take it that for these 'slots' to be implemented you would haveto use a
> extra line to syncronice the PICs on the bus ? My schedule is intended to work
> with the tx/rx lines only. Must be the simplest and cheapest way to get the PICs
> talking on the bus. All u do is to wait the time the ID states then send. Should
> be ideal when theres little traffic on the bus.

Signalling can be done inband. Every hardware USART checks for spurious start
bits. When a start bit is seen, it's checked again somewhere between 1/3 and
2/3 of the bit width to make sure that it's valid. If the start bit is invalid
at the second check, it is ignored.

So in band signalling can be done by manipulating the transmit line in
intervals smaller than 1/3 of the bit time. For example everyone can monitor
their RX line for two blips within 1/3 of a bit time. This can signal the
negotiation and all of the UARTS will ignore it.

It does add some programming complexity. But I'm pretty sure it would work.

I do admit that my plan was to add a second signalling channel simply because
it's easier to implement and monitor.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body