Excellent explanation indeed !
AFAIK it could be done with only one io pic pin IF:
-there is only one master on the bus
-all slaves are rotary interogated by the master
-a fixed delay is implemented in slaves between reading own address and
sendind response.
-response have a fixed lenght ( in byte numbers ) for all slaves
Best regards, Vasile
On Tue, 16 Oct 2001, Thomas McGahee wrote:
{Quote hidden}> Quentin,
>
> First off, if you expect the single wire bus to float at 1/2 Vdd
> all by itself, you are in for a nasty suprise. Since tristate is
> a high impedance state, the line will jump all over the place in
> the high impedance state. To prevent this, use two 10k resistors
> in series. The top ties to Vdd, the bottom to Vss, and the
> junction of the two ties to your single wire bus. Now the tristate
> condition will cause the line to rest cleanly at 1/2 Vdd.
>
> A normal input line cannot detect this tristate condition, though,
> because it will interpret it as either a high or a low, depending
> on the phase of the moon and the presence of cats in the room.
> Among other things.
>
> So, how could you somehow detect whether or not the bus is
> really high, low, or tristated? Well, here is what I have done
> on occassion:
> Each PIC needs two free i/o lines. Let's call these pins IN and
> OUT. The IN pin is always an input.
> The OUT pin is always an output. Connect bus line between IN
> inputs of PICS. Put a 3.3K pullup resistor from the bus to +5.
> Each OUT pin connects to the cathode of a diode. All anodes connect
> to the bus.
>
> The bus is normally being pulled high, and each PIC outputs a
> HIGH as it's default output state. If a PIC wants to access
> the bus, it watches the state of the bus. If the bus stays high for
> a certain minimum period of time, then that indicates no
> activity, and the bus may be free. To verify that the bus is free,
> a PIC would set it's OUT low, NOP, read this low state via it's input,
> set the line high, NOP, read the high state via it's input,
> and if it read back this low-high sequence properly, then it would
> set it's output low and hold it in that state for a pre-determined
> period of time. This corresponds to take-over of the bus
> (which is normally high). Now data is transmitted. Then the bus
> is released back to it's pullup-high state. The transmitting
> PIC constantly verifies that it sees what it is sending. If there
> is an error, it would release the bus by sending out a high.
> That's how it responds to any other attempt to take over the bus.
>
> Receiving PIC sees the pullup-high become Low and enters the receive
> mode where it waits for the LOW to be stable for a minimum time
> (about half of the time allocated for take-over). It ignores the
> little low/hi/low pulse and looks for the longish low takeover
> signal. If instead it sees a longish high, then it was a false
> alarm and it knows the bus is free. If the low persists past the
> minimum time period for takeover, then it gets ready to input
> data. Data should be sent in a return to zero format. When all
> data has been sent then the transmitting PIC sets its output
> to high. Once the output has been high for a predetermined
> period of time, other PICS can jump in and attempt to
> grab the bus. You can prioritize the jump-in time by making
> lower priority devices have a longer wait before allowing them to
> jump in.
>
> This technique is simple to implement, and has low overhead. It does
> require two i/o pins per PIC, but it allows a simple method of
> syncronizing data transfers among many PICs.
>
> You can change the relative "priority" level of each PIC by
> programming them to have varying time delays before producing
> the little verification pulse. The one with the longest delay
> will win.
>
> Fr. Thomas McGahee
>
>
>
> {Original Message removed}
mitvma.mit.edu with SET PICList DIGEST in the body
