[TI-H] Re: TI Networking.

[Prev][Next][Index][Thread]

[TI-H] Re: TI Networking.



On Thu, 03 May 2001 00:57:23 +0200 Olle Hedman <oh@hem.passagen.se>
writes:
> 
> At 23:47 2001-05-02, you wrote:
> >Is there any reason not to fill the address space from the bottom?
> >
> >Every time a calc makes its initial connection, it waits for a full 
> cycle
> >to pass, then uses the largest address+1.  When it's calc 0's turn, 
> it
> >waits slightly longer before sending to give any newly connected 
> calc a
> >chance to transmit.
> 
> how do you know how many calcs are on the net? how do a calc know 
> its the last.

The hard way would be to look for the long gap between the last and first
packets, then count packets until it occurs again.  Probably the easiest
way would be to have a source address on each packet, then watch for
where it rolls over to zero.

The first calculator would have to wait a long time, say twice the
expected length of a start/end loop gap before deciding it was number 0
and transmitting.

> if you start from the end or the beginning has no difference as all.
> I thought of a scheme where the next calc sensed that a packet was 
> completly send, it starts to send, if it doesn't have anything to 
> sen it 
> sends a short (1 or 2 bytes) "I have nothing to send"-message, and 
> then the 
> next sends and so on.

You'd have to use the hard method above, but a "nothing to send" packet
could be as short as a single pulse.  (2 transitions)

> Still has this problem of knowing who is the last calc that makes it 
> a bit 
> strange...

The last calc is the calc with the highest known address.

The first calc is aware of one device (itself), so it counts one packet
(its own) before sending another packet.  (It also sees that it's number
0, so it waits slightly longer before sending to allow an unknown calc to
transmit.)

The second calc to connect knows of two devices, the first and itself, so
it starts transmitting in its place (2nd), then counts 2 packets
(including its own) before sending again.  When the first calc sees the
packet from this previously unknown device, it adds one to the number of
known devices and waits for that count.

And so on.

> could just be that if there hasn't been any traffic for a while, 
> then it 
> starts from the beginnning..
> hmm.. I realized this is pretty much exactly what you are 
> suggesting...
> I don't think fixed time-intervalls else then the 
> "wait-to-se-if-more-sends"-delay, better to send packets as soon as 
> possible, as fast as the previous calc has send its packet.

That requires at least that all calcs actually read and interpret each
byte sent.  With the end of packet gap, they just need to periodically
poll the port, and if nothing has happened for a few samples, note that
the packet has ended.

A side effect of the gap is to align all calcs to an 8-bit boundary at
the start of each packet in case of line error.  If you think about it,
line errors will either add or remove line transitions, so if you don't
have a way of realigning, you can't find any full bytes intact after
that.

Also, there's the extra gap I proposed at the beginning of the ring to
allow calculators to make the initial connection.  (I should probably add
that it's best if they're all PHYSICALLY connected before this whole
thing takes place, otherwise you'll have garbled data.)  Without that
gap, you need to know before touching the link how many devices are out
there.

> This is pretty damn close to token ring, except shared medium...
> 
> If we found a good way to encode bits on a single line, you could 
> connect 
> the calcs as a ring too...
> would probably waste half the bandwith though, since most 1-line 
> protocols 
> I have seen needs two transitions per bit.

Ah, now I understand your picture! :)

The way I'm envisioning it, on two wires you can send 1.5 bits per
transition, but only one transition on the network at a time.  (and I
think it would be more robust than anything you could do on one line, if
that's what i mean...)

With one line... Well I don't know how that would work, but from what you
say you can send (effectively) .5 bits per transition, but each calc can
theoretically send or recieve simultaneously.

It sounds harder to set up, but with theoretically greater bandwidth as
long as there's > 3 calcs.  (or maybe 6)

-josh
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
Follow-Ups: