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 ?
This idea is intended for a friendly bus (low traffic)

> 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.
/PJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics