On Wed, May 25, 2005 at 02:35:49PM -0500, PicDude wrote:
> On Wednesday 25 May 2005 12:32 pm, Olin Lathrop scribbled:
> > ...  What happens when a node has something to say, but it can't
> > just squawk it out?  Do you have a master that queries each node in turn? 
> > How many nodes does it query?  What happens when a queried node goes down? 
> > Do you wait for some timeout?  How do you detect new nodes being added? 
> > Will you leave enough room in your home grown protocol to accomodate future
> > expansion?
> 

Olin is right. It's a tough problem. I had tackled it at one time using a
two level priority scheme. I'd have to go find it though. Also I never got
a chance to implement it.

> 
> So far, my thoughts for most of this are as follows... 
> - Master will query each node in sequence asking "do you want to send 
> anything"?

Fine as long as no new nodes are being added as Olin specified

> - Master will wait for a specified time for a response.  No response in 
> specified time means an error occurred.  I've been toying with the idea of 
> re-trying once or twice, but haven't determined that yet.  Any error is 
> indicated at the master station (specifics TBD).

That should be good enough.

> - When the master gets a response, it will be addressed on the bus to the 
> master, but the data will indicate if it is intended for another station, and 
> the master will pass it along.

If you're going that route then you may want to implement virtual token 
passing instead. Operate with the presumption that all stations will be
well behaved. Then when a station wants to talk and it has the token, it
can speak to any target it wants. When it's finished it passes the token
to the next node.

There's no real point in have double transmissions if nodes need to talk
directly to one another. Primary/secondary based systems work best when all
of the secondaries need to interact with the primary.

> - I'm planning to implement an acknowledgement to the slave that message was 
> received.

That will facilitate flow control. But how will you know when the addressed 
node is finished sending?

> - Master will send out message on the bus, which the appropriate slave will 
> respond to.

> - Master will expect an acknowledgement within a certain time, else error.

> - Master will continue with next node.

> - I might need a broadcast message, but will not expect an acknowledgement 
> for 
> that.  If I do, I'll have the master send it to all stations 
> individually/sequentially.  Latency is not an issue here.
> 
> At this point, there will be about 10 stations, but I was planning to allow 
> for 16.  However, for simplicity, and since traffic will be relatively low, 
> I'm thinking I'll just send a full byte as the station id/address, and 
> another with the command, and perhaps a third with some checksum, etc.  That 
> last part is yet TBD.
> 
> The messaging will be very specific to each station, so new nodes will require 
> a firmware change at the master, since it will need to be setup based on the 
> type of node.  I don't plan to put anything automatic in for this.

But that doesn't jibe with "about 10 ... planning to allow for 16". Either it's
fixed and you hardcode it, or it's not and you allow new stations to join.

It feels like you picked the primary/secondary model out of thin air. Token
passing is more flexible and also eliminates contention.

BAJ
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist