[A83] Re: calculator networking - good idea?
[Prev][Next][Index][Thread]
[A83] Re: calculator networking - good idea?
Jeff wrote:
>Could someone critique my logic and tell me if there is anything wrong with
>my plan?
>
>
It looks good. I miss some details though. One thing is that a calc that
wants to initiate to send, should wait for the line to be silent.
maybe you thought of that, but didn't write it, but anyway.
This is specially critical i this design, since only the calc already
sending can detect collision.
Otherwise you probably would have several calcs working their asses off
trying to send data, but no data is actually sent, because they get
interrupted by another calc after just a few bytes and has to start
over, in the meantime the interrupting calc has just succeded in sending
its first bytes of data, and gets interrupted by the first, and so on...
You should probably make the delays random too (a simple fast one is
enough), so that two calcs won't wait the same time all the time,
specially at collisions, and in waiting for the line to be silent, to
avoid having calcs try att the approximate same time.
(Due to murphys laws, the calcs will very often try to send at the exact
same time, regardless of how unsyncronized they are. Probably no matter
what you do, too, but some measures can be taken.:)
--Olle
>>From my concept design in progress, a calculator that wishes to send data to
>one other calculator would first send an 'initiate' packet:
>
>[ Both lines would be held low for a predetermined delay, then the handshake
>line brought high for a predetermined delay. Subsequently, falling edges of
>the handshake signal would indicate a valid bit on the data line, and the
>bit will remain valid until the handshake line goes high. The speed of the
>handshake pulses is required to be less than 4000? bps, but the speed loss
>is justified considering all calculators must be able to keep up with the
>handshake signal and that the initiate packet will be only 5-6 bytes long.]
>
>After the 'initiate' packet:
>
>[Sending calculator brings handshake line low, and waits for data line to be
>brought low by receiving calculator. If the data line isn't brought low
>after a predetermined timeout, abort: receiver is not responding. If
>receiver responds, continue transfer using TI's link protocol which offers
>highest possible speed.]
>
>Collision detection:
>
>[When the sending calculator is in any delay loop in its sending routine, it
>samples the link port to verify that signals are as they should be. If a
>line controlled by the sending calculator is low when the calculator is
>outputting a high on that line, then abort (the other calculator that is
>trying to send cannot detect the collision). According to open-collector
>hardware, a calculator can output a high on a line, but the line can still
>be logically low if at least one other calculator pulls that line low.]
>
>I think that this solves problems related to synchronization, wiring, etc
>that we have discussed. We cannot wire in a circle because any calc on the
>circle busy at the time of a transmission will bring the network to a halt.
>We cannot use timing to determine when to sample the data lines, because the
>83 contains no reliable timing device. And collision detection is provided
>by making use of open-collector hardware.
>
>Jeff
>
>
>
Follow-Ups:
References: