Re: TI-H: IR Link status (was: expensive remote control)

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

Re: TI-H: IR Link status (was: expensive remote control)


Sami Khawam wrote:

> -Another possibility is the change the MChat and
>  make it compatible with the link.

If it is possible, without deviating from the I2C specifications, then I'll
do it. But I think that in this case, the hardware should adapt to the
software's needs in every way, except for the speed, because it's hard to
make a fast IR link. 

> -And the other possibility is the change MChat so
>  that it won't use the I2C protocol, but the TI protocol
>  , since this protocol is fully working.

What's the point in that? MChat is a multiuser chat program and uses I2C
because it allows many calcs to be connected. The TI protocol is restricted
to 2 calcs and there are TI protocol chat programs other than MChat.

> Does anyone have some ideas? Which is the best possibility?

How about this: Make the PIC distinguish between a low state received from
the calc, and a low state received by IR. It should only send "Hey this pin
is low" messages by IR if the calc is pulling the pin low, not if the low
state originated somewhere else.

This means that only the calc that actually pulled the pin low will have
its PIC send the state over IR. With your example, it would look like this:

(with both pins high)

1. Calc 1 pulls the pin low.

2. PIC 1 sees the low state and knows it came from Calc 1 and not by IR. It
therefore sends a low state message by IR.

3. PIC 2 sees the low state message and pulls the line of Calc 2 low, but 
the PIC memorizes that the signal came in by IR and doesn't respond with 
anything.

4. After a second, PIC 1 resends the low state. PIC 2 doesn't do anything,
because it knows the original signal came in by IR.

5. Calc 1 releases its data pin (it was never pulled down by PIC 1). PIC 1
sees the change and transmits a high state message by IR.

6. PIC 2 releases its data pin when it sees the high state message.

However, there's still one more problem...Calc 1 and PIC 1 will never know
if Calc 2 held the pin low when Calc 1 released it. This normally doesn't
matter because it was pulled down anyway and when PIC 1 sensed and
announced the change, PIC 2 would inform it about that the line is still
held down, this time by Calc 2. This delay can be sufficient for Calc 1 to
think that its data line is now high, even though it should still be low.
If the IR link was fast enough this will never happen, but I doubt the IR
link can respond in about 5 microseconds (the tightest possible link port
reading loop).

One possibility of solving this is using a "three-state" approach (no, not
the one with a high impedance state), where the PIC uses a low signal level
of around 1.5 - 2.5 volts instead of the standard TTL levels. My TI-85
recognizes voltage levels of <2.7 V as a low state, but I think the low
state it produces itself has a much lower voltage. Thus, the PIC could know,
with some external components, if the calc was actually pulling the pin low,
even if the PIC itself was already pulling it "low" (for the calc). I admit
this is dirty, has anyone got a better approach?

-Ozone

-- 
*** Osma Suominen *** ozone@clinet.fi *** http://www.clinet.fi/~ozone ***
References: