On Tue, 22 Feb 2000, Byron A Jeff wrote:

> >
> > Adam,
> >
> > Unless you have a really big house, you can circumvent the collision
> > detection by adding an arbitration phase. Without going into enormous
> > details, you can create an arbitration phase at the end of every message
> > that goes out on to the bus. The device who last sends a message may
> > initiate the arbitration phase by driving the bus low (opposite of the
> > stop bit) and then releasing it. All nodes listen to this falling edge and
> > start a timer when it occurs. Then all contending devices compete by
> > asserting the bus (driving it high - the same state as the stop bit) at
> > pre-designated time slots. The time slots, or arbitration slots may be
> > derived from the devices' addresses. The first one to assert the rising
> > edge wins the arbitration and will obtain control of the bus on the next
> > cycle.
>
> This is close to a scheme I was devising. A couple of questions. First what is
> the state of the line between the time that the last device releasing and the
> first device asserting? It's unclear from the description above.

First of all, I must confess that I implemented this in my pre-pic days...
But there's no reason why it shouldn't work on a pic.

TTL <-> EI485 transcievers have a transmitter disable control signal that
proves to be vital for this algorithm. Also, how you terminate the '485
network is equally important.

This is what you do. The device that has control of the network and is
transmitting data onto it, will be responsible for initiating the
arbitration phase. It knows when the last byte is to be transmitted (and
depending on your protocol, so will all other nodes too). Once this last
byte has gone on to the wire, it will reprogram the UART output as general
purpose output and keep the I/O line in the same state as the stop bit
(TTL high). After some suitable delay, say 5 bit times, this node will
drive the line low and keep it low for some other conveniently suitable
time. Now two things have to happen. First, when this edge goes low ALL
nodes must capture it with their Input Capture lines (including the one
just asserting the edge). Second, when this node releases the line, the
'485 bus will be floating. Consequently, you'll need to terminate the bus
in a way that will keep it biased in this state. If you chose not to
terminate the 485 bus, then simple pull up and pull down resistors are
sufficient. Otherwise, you can go ahead use the standard 120 termination
and just terminate one side to a plus rail and the other to a minus.


> Secondly since UARTS are going to be a part of this I presume that the
> arbitration phase must be less that 1/2 of a normal bit time? That way none
> of the UART circuity should register the arbitration pulse as an actual
> start bit right? I was planning on having a separate arbitration line for
> this reason. Also with a separate arbitration line then the winner
> can start transmitting instantly instead of waiting for the arbitration cycle
> to end.


During the arbitration phase, the UARTs are totally disabled. The capture
compare module will have control. So it really doesn't matter how big the
arbitration intervals are. Practical considerations are the guiding
factor. For example, if you were bit banging everything, it may make sense
to make the arbitration intervals a little wider and thus ease the timing
constraints of a software-based input capture. I found that 1 to 2 bit
times worked well (with hardware based IC). So if you have 32 nodes on the
bus, then the arbitration may take between 3 and 6 character times. So you
may want to shorten the arbitration intervals and/or reduce the number of
nodes.

>
> Lastly it doesn't look fair which is the battle I had been fighting. In the
> scheme I devised I have a primary and secondary slot for each device. The
> secondary slots all fall after all the the primaries. So arbitration would
> happen like this:
>
> 1. Arbitration pulse starts the timers.
> 2. All primaries would check their slots, If the line is available then
> assert and start transmitting. After transmitting move to secondary slot.
> 3. If no primary answers then all current secondaries can move back to their
> primary slot after the first secondary answers. However if any primary answers
> then all secondaries stay put.
> 4. In all cases if the arbitration line is asserted in your slot wait until
> the next cycle.
>
> So this way if everyone wanted to transmit all the time then the bus would get
> assigned in round robin priority order. Once you've transmitted then everyone
> who is a primary will get a chance to transmit before you get to transmit
> again. Initial evaluation seems to give fairness without a chance of
> starvation.

Absolutely! This is exactly what I did as well. There were some minor
differences, but having a primary and secondary slot is crucial. One of
the things you may wish to consider is designating one (or perhaps a few)
device(s) with more authority than the others. The secondary slots can be
reserved for only these devices. Also, if for some reason communication
ceases, then these devices could act as network watchdog timers.



> Also I had been in the mode of thinking that a single node would control
> the arbitration pulse. But clearly the distributed approach of having the last
> sender initiate the next arbitration cycle is clearly superior.

I think so too. You can sort of compare it to the differences between
pre-emptive and semi-pre-emptive multitasking. Distributing control puts a
little more pressure on each node involved, but in my opinion the
communication efficiency gained is worth it.

> I'm planning on getting a couple of students of mine who are working on a
> PIC based UDP/SLIP node to implement and test the scheme. I'll let you know
> how it turns out.

Great!

One freebie with this approach is that you almost get automatic
time-synchronization. Since every node knows WHEN the arbitration edge is,
then one node responsible for keeping the time can tell the others when in
real time that edge occured. Depending on your node separation distances,
micro-second resolution time synchronization is possible. (I never needed
more than 500uS though).


Scott