Raymond Choat wrote:
>
>My slave (16f876pic board) runs a 24volt air valve. The Master (16f877)
>runs
>6 of these slaves. The Master activates slave by signaling a LOW signal
>that
>was held high. This signal is working as each valve will turn on and off
>with the test program run. The Slave tells Master that it has finished (or
>end limit was reached) by sending a HIGH signal from its port C to the
>Masters port B. Signal is low when slave is busy and high when it is
>finished.  I checked with digital probe and signals are correct. The signal
>to the slave is correct and signal back from slave is correct. So it must
>be
>how the Master sees this busy/finished signal from the slave. It seems
>simple what I am trying to do "Turn on slave and wait till slave is done,
>then continue". None of the signals timing or speed is real critical.
>
>Sometimes when the master activates the slave, the slave may already be in
>that position and the _done line will already show high (finished), never
>showing (low)busy.  Here is a piece of the code that the Master uses to
>talk
>to slave. Does this piece of code require that it sees the "low" first then
>exits when it goes "high"?
>
>Main = 0                         'Master signals Slave to turn OFF
>While Main_done = 0   'Wait till Slave signals that its done with a high
>signal
>Wend                             'Then continue
>
>Is there a better way of doing this with PBP?
>

Simple things between two (or more processors) are rarely as simple as they
may appear to be. :=)

No, your code does not require that the master see a low before it sees a
high. What I'm suggesting is that it should be changed so that it does.

The timing of the interactions between master and slave processors can
create all sorts of problems that aren't immediately obvious.


How quickly can a slave respond to the master's 'main = 0' port change?
Unless it's instantaneous (or faster), a 'race condition' between the two
processors can result.

Since the slave has to detect the port change and can only then respond by
dropping its '_done' line, your master processor can be checking the
condition of the _done signal well before the slave has had any chance to
drop it.

In this case, _done doesn't just mean 'done', it also means 'not responded
to yet'. If this happens, the master 'thinks' that the slave is finished
when it had just seen the change command and had not yet responded to it.

Without a clear indication from the slave that it has seen the command, the
master can't know whether the _done indication is valid or not.

By having the slaves go busy in response to every command, the master can
'see' the slave go busy. (At this point, the master knows that the command
has been accepted by the slave.) The master can then wait for the _done
indication when the slave completes its processing (or immediately if no
processing is needed).


Regards, Bob


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu