>On Wed, May 25, 2005 at 03:33:20PM -0500, PicDude wrote:
> On Wednesday 25 May 2005 03:09 pm, Byron A Jeff scribbled:
>> 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 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.

The fact that communcation is required to nodes other than the master node
suggests not using this modem.

>
> 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. :-)

As it should. It would be easier having a ACK line out of band. Can you
afford another wire, some pullup power, and another I/O line?

>> > - 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?
>
> FIxed length messages.  So far 3 bytes per message, which includes the
> address.

Short messages. But ACKS will really do some damage in terms of time and
bandwidth.

>> 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.
>
> Allowing for 16 in case needed in the future, and with this scheme, I'll
> have some simple flags in the code to indicate which types of messages need
> to be send to which stations (depending on the type of station).  I'd need
> to set these flags in the code for the new station ID and re-compile.  By
> planning,I mean that I will not need to re-write the code using a different
> message length, etc -- just set flags and re-compile the firmware.

That's fine.

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

> There is another term to descibe where it came from, but I'll refrain from
> stating it here :-)  Okay, not really -- the need to have a message mostly
> go to multiple stations made this scheme somewhat "natural" (at least for
> me).  I'll do some thinking about the token method.

It seems to me the store and forward is going to make the problem worse,
not better as you'll have to have double send and receipts for each 
message for each station.

At least with the token setup you can broadcast once, then poll for 
receipts.

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