PicDude wrote:
> I came up with this since in a significant majority of cases, the
> master will need to be informed of the event, and the slave will want
> to communicate the message to more than one other slave.  Having each
> slave send out a message to more than one other slave seems like a mess
> as they would be communicating without the master letting them do so.

Remember that all nodes must watch the bus all the time.  All slaves
therefore see a message sent by another slave, although the sending slave
never knows for sure they received it...

I think you're starting to glimpse how big this can of worms really is.  As
I said, I've done all this.  In the end it worked reliably and did
everything we wanted it to, but it is something I classify as "advanced".

> I also thought of a scheme where each bit on a couple bytes would
> represent a unique node.  In one message, multiple specific nodes could
> be addressed. But this turn out to be another can of worms for the
> acknowledgements.  All sorts of odd thoughts of having each station
> acknowledge after waiting a specific differing time followed, which
> resulted in my head spontaneous combusting. :-)

More worms.  The big issue you haven't seemed to hit on yet is reliability.
You should assume that the bus has a small but finite error rate.  Checksums
are good at verifying reliable reception at the receiver, but you can't have
reliable communication without talking both directions.  That means there
are ACKs and timeouts.  You have to go thru each possible case of a message
getting garbled, and messages not getting garbled but the ACKs getting lost,
etc.

More worms.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist