| |
Mike Moran <mm@ee.ed.ac.uk> wrote:
> I assumed that the IR burst would be still around whilst it was
> transmitting, however, can the IR hardware actually be asked to detect a
> burst whilst it is transmitting? What is the software <-> hardware
> interface to the IR capable of?
I believe transmission and reception are independent, i.e. the emitter
circuit is decoupled from the receiver circuit. The hardware on the H8 is
full duplex. Once you finish sending a byte, I think you get two
interrupts: one saying a byte has been transmitted, one saying a byte has
been received.
Regarding detecting collisions, I forgot to mention that you can only
detect a collision after an entire byte has been transmitted. This is a
pain, since every collision costs you at least one byte time. This affects
algorithms that try to avoid further collisions by waiting a random delay
before retransmitting. I think this makes slotted algorithms look more
attractive.
> The clock shows up because the transitions always happen on a clock tick,
> hence the wire-line signal embodies some notion of time that can be used
> to synchronize both ends.
I think something like this is possible on the H8. You might be able to
use the rhythm established by the reception of bytes from other RCXs to
keep clocks in sync, although the timings would be somewhat coarse grained
and you'd have to leave space for whatever the margin of error ended up
being.
I wonder what the throughputs and latencies are given different numbers of
RCXs, different transmission distributions, use of slotted vs. unslotted,
and the necessary RCX-specific parameters describing time to transmit as a
function of number of bytes transmitted.
-Kekoa
|
|
Message has 1 Reply:
Message is in Reply To:
15 Messages in This Thread:
  
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
