Searching \ for '[PIC] Timeless communication protocols' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/time.htm?key=time
Search entire site for: 'Timeless communication protocols'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Timeless communication protocols'
2007\02\25@121024 by Timothy J. Weber

face picon face
Bob Axtell wrote:
> Good explanation. I assumed Wouter's ZPL scheme was manchester code
> (falling edge begins/ends a new bit,
> bit time measured, if pulse width was > 50% it was a ONE, less than 50%
> it was a zero, which is also
> what I use as a production diagnostic tool). Thanks for a GREAT explanation.

All this talk of stingy protocols has spurred me to post a problem I've
been thinking about.  Consider it an open exercise.

Requirements:

- Bidirectional communications between two PICs.

- Half-duplex - that is, only one PIC can be sending at a time, and it's
OK to have a "master" and have the "slave" only talk when the master has
asked it a question.

- Hardware serial ports are not allowed.  (Either the specific PIC being
used doesn't have one, or it does, but it's already being used for
something else.)

- You may not use an interrupt handler, and your code must be
interruptible and never block longer than a few dozen instruction cycles
while sending or receiving.  (Assume lots of other time-critical stuff
is going on in both PICs.)

- You can assume the two PICs are physically close - under 10 cm.

- A few external passives are allowed, but no additional ICs.

Challenge: How few connections between the PICs can you get away with,
not counting power and ground?  How few pins?

Another way to put this is: Normal synchronous serial comms requires two
lines + low interrupt latency.  Asynchronous serial comms requires one
line + a reasonably accurate clock, as well as either the ability to
block or low-latency interrupts.  What if you have neither (dependably)
low latency nor an accurate clock, and you can't block?  How few lines
and pins can you use?

A 3 lines/3 pins solution with no external parts that could peak over 30
kbps is obvious.  I *think* the best I can do is 1 line/2 pins, with 3
extra parts, at a peak of nearly 9600 bps.

I'm happy to show my solution, but thought it might make a good puzzle
so I'll hold off for a day or two.
--
Timothy J. Weber
http://timothyweber.org

2007\02\25@133518 by Bob Axtell

face picon face
Timothy J. Weber wrote:
{Quote hidden}

SPI can easily handle this much speed. 2 pins (SDA & SCK) + GND., no
extra parts

I can transfer about 100 baud reliably using only ONE PIC pin + GND, NO
extra parts by using a manchester
scheme.

--Bob

2007\02\25@135135 by Timothy J. Weber

face picon face
Bob Axtell wrote:
> SPI can easily handle this much speed. 2 pins (SDA & SCK) + GND., no
> extra parts

I'm not sure I'm getting my goal across.  Can you do a software
implementation of SPI with no interrupts and without blocking?

> I can transfer about 100 baud reliably using only ONE PIC pin + GND, NO
> extra parts by using a manchester
> scheme.

But Manchester requires that the receiver can either poll the input
constantly or fire an interrupt when the pin changes and note the
difference in a timer.

This isn't about speed primarily, it's about software and hardware
requirements.
--
Timothy J. Weber
http://timothyweber.org

2007\02\25@140041 by Wouter van Ooijen

face picon face
> SPI can easily handle this much speed. 2 pins (SDA & SCK) + GND., no
> extra parts
>
> I can transfer about 100 baud reliably using only ONE PIC pin
> + GND, NO extra parts by using a manchester scheme.

But neither will work when the receiver has no control over its timing.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\25@140046 by Wouter van Ooijen

face picon face
> All this talk of stingy protocols has spurred me to post a
> problem I've been thinking about.  Consider it an open exercise.
>
> A 3 lines/3 pins solution with no external parts that could
> peak over 30 kbps is obvious.  
> I *think* the best I can do is 1 line/2 pins, with 3
> extra parts, at a peak of nearly 9600 bps.
>
> I'm happy to show my solution, but thought it might make a good puzzle
> so I'll hold off for a day or two.

A few years ago I was thinking about a what I called TIP, a Time
Independent Protocol. It was for communication bewteen two chips that
can assume *nothing* about timing (one could be running at 0.001 ...
10000 x the speed of the other, and the speeds can vary arbitrarily). I
used open-collector pins to interface, and I think I could prove that
unidirectional communication required 2 lines, bidirectional 3 lines. I
am not sure your restrictions are the same, if you can create
bi-directional over less than two lines I'd be surprised.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\25@141815 by David VanHorn

picon face
let the recieving end clock the data

On 2/25/07, Timothy J. Weber <spam_OUTtwTakeThisOuTspamtimothyweber.org> wrote:
> Bob Axtell wrote:
> > SPI can easily handle this much speed. 2 pins (SDA & SCK) + GND., no
> > extra parts
>
> I'm not sure I'm getting my goal across.  Can you do a software
> implementation of SPI with no interrupts and without blocking?
>
> > I can transfer about 100 baud reliably using only ONE PIC pin + GND, NO
> > extra parts by using a manchester
> > scheme.
>
> But Manchester requires that the receiver can either poll the input
> constantly or fire an interrupt when the pin changes and note the
> difference in a timer.
>
> This isn't about speed primarily, it's about software and hardware
> requirements.
> --
> Timothy J. Weber
> http://timothyweber.org
> -

2007\02\25@144413 by Bob Axtell

face picon face
Wouter van Ooijen wrote:
>> SPI can easily handle this much speed. 2 pins (SDA & SCK) + GND., no
>> extra parts
>>
>> I can transfer about 100 baud reliably using only ONE PIC pin
>> + GND, NO extra parts by using a manchester scheme.
>>    
>
> But neither will work when the receiver has no control over its timing.
>
> Wouter van Ooijen
>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: http://www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: http://www.voti.nl/hvu
>  
>
>  
MY manchester code schemes have a 10:1 timing range. The only
requirement is from BIT to BIT that the timing hold within 5% or so;
the next BIT can be 10x as long and my receiver handles it.

The bit begins as a falling edge. When the pin next rises, its length as
a low signal is noted. At the next falling edge, the bit to bit length
is noted,
and if the LOW was longer than 50% it is a ONE, otherwise it is a ZERO.
The next bits can be longer or shorter, since the test for ONE or ZERO
occurs when the next bit starts, the timing can vary a LOT yet still extract
data without error. This makes actual timing of little significance.

But you are right in that the receiver has to actually measure SOMETHING.
To do so without using an interrupt looks like Timothy is doing something
similar to Virgin Birth...

--Bob

--Bob

2007\02\25@144924 by Bob Axtell

face picon face
Wouter van Ooijen wrote:
{Quote hidden}

I can use ONE PIN from each PIC, as long as the PIC can invoke an
interrupt, such as interrupt-on-change
or EXT interrupt (any PB? except PB1, PB2 on most nanowatt PICs). The
MASTER starts the communication,
the SLAVE replies only. BiDirectionally on one pin on each PIC.

--Bob
> Wouter van Ooijen
>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: http://www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: http://www.voti.nl/hvu
>  
>
>  

2007\02\25@145444 by Bob Axtell

face picon face
David VanHorn wrote:
> let the recieving end clock the data
>  
Actually on SPI, the receiver waits for the clock FROM the xmitter. When
the SPI
port receives 8 clocks, it sets the SPI FULL flag. The receiver begins
acquiring the
bytes that way. On the hardware, the SDO and SDI are cross-connected between
the two PICs but the SCK signals are tied together.

--Bob
{Quote hidden}

>> --

2007\02\25@145928 by Wouter van Ooijen

face picon face
> let the recieving end clock the data

That will work only when the sender has control over its timing. To be
timing-independent you need a full handshake for each bit.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\25@151811 by Wouter van Ooijen

face picon face
> >> I can transfer about 100 baud reliably using only ONE PIC pin
> >> + GND, NO extra parts by using a manchester scheme.
> >>    
> >
> > But neither will work when the receiver has no control over
> its timing.
> >
> > Wouter van Ooijen
> >
> > -- -------------------------------------------
> > Van Ooijen Technische Informatica: http://www.voti.nl
> > consultancy, development, PICmicro products
> > docent Hogeschool van Utrecht: http://www.voti.nl/hvu
> >  
> >
> >  
> MY manchester code schemes have a 10:1 timing range. The only
> requirement is from BIT to BIT that the timing hold within 5% or so;
> the next BIT can be 10x as long and my receiver handles it.

So you do require that both sender and receiver have a (admitted:
relatively limited) control over their timing.

What I had in mind is a protocol that still works when timing for both
sides are rubber bands, that can be stretched atribrarily
(independently, and varing over time).

> To do so without using an interrupt looks like Timothy is
> doing something similar to Virgin Birth...

Check the trusty old centronics-style full handshake: no timing
dependency!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\25@152012 by Wouter van Ooijen

face picon face
> I can use ONE PIN from each PIC, as long as the PIC can invoke an
> interrupt, such as interrupt-on-change
> or EXT interrupt (any PB? except PB1, PB2 on most nanowatt PICs). The
> MASTER starts the communication,
> the SLAVE replies only. BiDirectionally on one pin on each PIC.

Explain? I am sceptical (that is, if you take my set of requirements:
totally time independent. so you can't even say 'side 1 waits at elast
10ms and then...')

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\25@153951 by Timothy J. Weber

face picon face
Bob Axtell wrote:
> MY manchester code schemes have a 10:1 timing range. The only
> requirement is from BIT to BIT that the timing hold within 5% or so;
> the next BIT can be 10x as long and my receiver handles it.

I understand that it's very tolerant of different timing on each chip,
and that's good... but I want something that doesn't require you to have
to time the bit at all.

> I can use ONE PIN from each PIC, as long as the PIC can invoke an
> interrupt, such as interrupt-on-change

And no interrupts allowed!

And David VanHorn wrote:
> let the recieving end clock the data

No interrupts or blocking are allowed on EITHER end.  I assert that that
means no time-dependence (though I may be wrong).  The comms code needs
to run a little a time, cooperative-multitasking-friendly.

And Wouter van Ooijen wrote:
>
> A few years ago I was thinking about a what I called TIP, a Time
> Independent Protocol. It was for communication bewteen two chips that
> can assume *nothing* about timing (one could be running at 0.001 ...
> 10000 x the speed of the other, and the speeds can vary arbitrarily).

Yes!  This is what I'm talking about.

> I
> used open-collector pins to interface, and I think I could prove that
> unidirectional communication required 2 lines, bidirectional 3 lines. I
> am not sure your restrictions are the same, if you can create
> bi-directional over less than two lines I'd be surprised.

Well, I *think* I can do it... but maybe I'm looking at the blueprint
for a perpetual motion machine...

It DOES rely on something that works on paper but may require careful
handling (at least) in the real world.  So I'll go look at it some more.
--
Timothy J. Weber
http://timothyweber.org

2007\02\25@165603 by Timothy J. Weber

face picon face
Timothy J. Weber wrote:
> Well, I *think* I can do it... but maybe I'm looking at the blueprint
> for a perpetual motion machine...
>
> It DOES rely on something that works on paper but may require careful
> handling (at least) in the real world.  So I'll go look at it some more.

(By which I didn't mean I'm withdrawing the challenge!  So far I believe
I can make it work, just not sure whether it'll be reliable [or useful]
enough for general use.)
--
Timothy J. Weber
http://timothyweber.org

2007\02\25@173126 by David VanHorn

picon face
On 2/25/07, Wouter van Ooijen <wouterspamKILLspamvoti.nl> wrote:
>
> > let the recieving end clock the data
>
> That will work only when the sender has control over its timing. To be
> timing-independent you need a full handshake for each bit.



Not at all.
The only control the sender needs, is to be able to put the next data on the
data line after the receiver has toggled the clock.

I've implemented this multiple times on multiple platforms.

2007\02\25@174755 by William Chops Westfield

face picon face

On Feb 25, 2007, at 12:18 PM, Wouter van Ooijen wrote:

> Check the trusty old centronics-style full handshake:
>  no timing dependency!
>
Doesn't it require that the receiver latch data and set BUSY
essentially "instantly" upon receiving STROBE?  Also, STROBE
is only spec'ed to be at least one microsecond long.  I recall
that implementing a centronics slave in software on a relatively
slow system was relatively problematic, at least in theory.
Some PICs have special hardware to implement a parallel slave
port... (I'm getting some of these details from modern documents,
so they may reflect current usage rather than actual spec.)

If one side of the communications has tight timing, implementing
the other side becomes much easier...

BillW

2007\02\25@180548 by William Chops Westfield

face picon face

On Feb 25, 2007, at 2:31 PM, David VanHorn wrote:

>> That will work only when the sender has control over its timing. To be
>> timing-independent you need a full handshake for each bit.
>>
I think you can do it with one bi-directional data line and
two handshake lines (one in each direction), with a SW protocol
to change direction (which implies a master/slave, I think.)
A data bit ready is indicated by changing the state of the handshake
line to the receiver, and changing the state of the handshake line
coming back indicates the bit was received.

BillW

2007\02\25@191121 by Scott Dattalo

face
flavicon
face
On Sun, 2007-02-25 at 12:05 -0500, Timothy J. Weber wrote:

{Quote hidden}

This can be accomplished with two I/O pins (on each PIC). You may need
pull up resistors if you're not using the appropriate I/O pins.

Suppose you have two lines called A and B. In the quiescent state, the
PIC's I/O's are configured as inputs and the lines are pulled high with
resistors. Call the two PICs U1 and U2. If the bus is in the quiescent
state, then when the A line is driven low this signifies the beginning of
a logic '1' transmission. Similarly if the bus is quiescent when B is
driven low then this is the beginning of a logic '0'. The processor that
drove the line is the master.

Here are examples for U1 transmitting 1's and 0's to U2.

U1 transmits a '1' to U2:

U1 drives A low
U2 acknowledges by driving B low
U1 sees the acknowledgment and drives B low too and releases A.
U2 sees A go high. It then pulls A low.
U1 sees A go low and releases B.
U2 sees B go high and then releases A.

U1 transmits a '0' to U2:

U1 drives B low
U2 acknowledges by driving A low
U1 sees the acknowledgment and drives A low too and releases B.
U2 sees B go high. It then pulls B low.
U1 sees B go low and releases A.
U2 sees A go high and then releases B.


And similar descriptions apply for U2 to U1 transmissions.

Scott

2007\02\25@200837 by Bob Axtell

face picon face
Wouter van Ooijen wrote:
>> I can use ONE PIN from each PIC, as long as the PIC can invoke an
>> interrupt, such as interrupt-on-change
>> or EXT interrupt (any PB? except PB1, PB2 on most nanowatt PICs). The
>> MASTER starts the communication,
>> the SLAVE replies only. BiDirectionally on one pin on each PIC.
>>    
>
> Explain? I am sceptical (that is, if you take my set of requirements:
> totally time independent. so you can't even say 'side 1 waits at elast
> 10ms and then...')
>
> Wouter van Ooijen
>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: http://www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: http://www.voti.nl/hvu
>  
>
>  
You are right, Wouter. SOME timing consideration is required.

--Bob

2007\02\25@201410 by Bob Axtell

face picon face
Timothy J. Weber wrote:
> Timothy J. Weber wrote:
>  
>> Well, I *think* I can do it... but maybe I'm looking at the blueprint
>> for a perpetual motion machine...
>>
>> It DOES rely on something that works on paper but may require careful
>> handling (at least) in the real world.  So I'll go look at it some more.
>>    
>
> (By which I didn't mean I'm withdrawing the challenge!  So far I believe
> I can make it work, just not sure whether it'll be reliable [or useful]
> enough for general use.)
>  
WHAT? you mean you are gonna keep us in suspense...? <G>

--Bob

2007\02\25@201730 by Timothy J. Weber

face picon face
David VanHorn wrote:
> On 2/25/07, Wouter van Ooijen <.....wouterKILLspamspam.....voti.nl> wrote:
>>> let the recieving end clock the data
>> That will work only when the sender has control over its timing. To be
>> timing-independent you need a full handshake for each bit.
>
> Not at all.
> The only control the sender needs, is to be able to put the next data on the
> data line after the receiver has toggled the clock.

But "after" isn't good enough in that case - it must be "at most X
microseconds after".  Otherwise you run the risk that the receiver
toggles the clock again before the next bit is ready.
--
Timothy J. Weber
http://timothyweber.org

2007\02\25@201850 by Timothy J. Weber

face picon face
William Chops Westfield wrote:
> On Feb 25, 2007, at 2:31 PM, David VanHorn wrote:
>
>>> That will work only when the sender has control over its timing. To be
>>> timing-independent you need a full handshake for each bit.
>>>
> I think you can do it with one bi-directional data line and
> two handshake lines (one in each direction), with a SW protocol
> to change direction (which implies a master/slave, I think.)

Yes!  That's a perfectly good 3 lines/3 pins solution.  (And I think
it's the one I'll use in the situation that prompted this train of thought.)
--
Timothy J. Weber
http://timothyweber.org

2007\02\25@202421 by Timothy J. Weber

face picon face
Scott Dattalo wrote:
> This can be accomplished with two I/O pins (on each PIC). You may need
> pull up resistors if you're not using the appropriate I/O pins.
>
> Suppose you have two lines called A and B. In the quiescent state, the
> PIC's I/O's are configured as inputs and the lines are pulled high with
> resistors. Call the two PICs U1 and U2. If the bus is in the quiescent
> state, then when the A line is driven low this signifies the beginning of
> a logic '1' transmission. Similarly if the bus is quiescent when B is
> driven low then this is the beginning of a logic '0'. The processor that
> drove the line is the master.

Splendid!  This is the 2-line, 2-pin solution.  You even used the same
labels I did!

Now, can you do it with two pins per side, but only one line between
them?  It's very much in the same spirit - requires two tri-stateable
(trinary?) pins, and also something else.
--
Timothy J. Weber
http://timothyweber.org

2007\02\25@202709 by Timothy J. Weber

face picon face
Bob Axtell wrote:
>> (By which I didn't mean I'm withdrawing the challenge!  So far I believe
>> I can make it work, just not sure whether it'll be reliable [or useful]
>> enough for general use.)
>>  
> WHAT? you mean you are gonna keep us in suspense...? <G>

:)  Yeah, at least till the Monday morning crowd gets a crack at it!

(though it may make you say "Yuck!" more than "Aha!")
--
Timothy J. Weber
http://timothyweber.org

2007\02\25@210617 by Jake Anderson

flavicon
face
Bob Axtell wrote:
{Quote hidden}

I think the solution may be in the analogue regime, You could do it with
1 pin per pic a cap and some resistors.
Analouge gives you the ability to communicate multiple bits of data over
one line. The question is, how.

2007\02\25@212654 by Timothy J. Weber

face picon face
Jake Anderson wrote:
> I think the solution may be in the analogue regime, You could do it with
> 1 pin per pic a cap and some resistors.
> Analouge gives you the ability to communicate multiple bits of data over
> one line. The question is, how.

Bingo!
--
Timothy J. Weber
http://timothyweber.org

2007\02\26@001859 by Forrest W Christian

flavicon
face
I'm 99.9% sure I can do bidirectional, half-duplex no-timing-needed,
digital-realm communications with 2 open-collector outputs capable of
self-read.

Direction setting is left as an exercise to the reader - it's really a
function of passing data, or some initial handshake to ensure that the
end wanting to send a message has control of the bus.  Half duplex
really just means switchable uni-directional.

You have two lines.   Idle is "high".  Call one of the lines the "mark"
(1) line, and one of the lines the "space" (0) line.

To send a zero, do the following (master is defined as the end sending):

Initial state is both lines high.  Lines must be in this state before
transmitting.

Master yanks the space line low and waits for the mark line to go low.

Slave sees that the space line went low first, and records a zero.  
Yanks the mark line down.  Waits for the space line to go back high.

Master sees that the mark line went down, and releases the space line.  
Waits for the mark line to go back high.

Slave sees that the space line went back high, and releases the mark line.

Both ends now see both lines high, proceed with next bit.

To send a one, reverse mark and space.

Or, to put it another way:  Whichever line goes low first is what the
bit is - a mark or a space.   The other processor acknowleges that it
saw the bit by yanking the opposite line low.  The sending processor
acknowedges that it saw the second processor got the bit by returning
it's bit to high, and the far end processor acknowleges this by turning
it's bit back high.

-forrest

2007\02\26@004224 by Denny Esterline

picon face

> Or, to put it another way:  Whichever line goes low first is what the
> bit is - a mark or a space.   The other processor acknowleges that it
> saw the bit by yanking the opposite line low.  The sending processor
> acknowedges that it saw the second processor got the bit by returning
> it's bit to high, and the far end processor acknowleges this by turning
> it's bit back high.
>

Where have I seen this before -- Oh yeah, this is Texas Instrument's link
protocol for thier calculators. I interfaced my TI-89 titanium to a 16F88
a couple years back, one of my first projects with the '88 as I recall.

-Denny

2007\02\26@004307 by Vasile Surducan

face picon face
On 2/25/07, Timothy J. Weber <EraseMEtwspam_OUTspamTakeThisOuTtimothyweber.org> wrote:
> Jake Anderson wrote:
> > I think the solution may be in the analogue regime, You could do it with
> > 1 pin per pic a cap and some resistors.
> > Analouge gives you the ability to communicate multiple bits of data over
> > one line. The question is, how.
>
> Bingo!

Bingo but looser. You need voltage to current conversion for long
lines. And you're back to '80. Not talking about the problems.

Vasile

2007\02\26@021625 by Wouter van Ooijen

face picon face
> Doesn't it require that the receiver latch data and set BUSY
> essentially "instantly" upon receiving STROBE?  Also, STROBE
> is only spec'ed to be at least one microsecond long.  I recall
> that implementing a centronics slave in software on a relatively
> slow system was relatively problematic, at least in theory.
> Some PICs have special hardware to implement a parallel slave
> port... (I'm getting some of these details from modern documents,
> so they may reflect current usage rather than actual spec.)
>
> If one side of the communications has tight timing, implementing
> the other side becomes much easier...

Maybe I did not read the centronics style handshake carefully. A full
handshake is:

1 I put the data on the line or bus
2 I make 'data available' high
3 you read the data
4 you make 'data read' high
5 I make 'data available' low
6 You make 'data read' low

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\26@021625 by Wouter van Ooijen

face picon face
> > That will work only when the sender has control over its
> timing. To be
> > timing-independent you need a full handshake for each bit.
>
> Not at all.
> The only control the sender needs, is to be able to put the
> next data on the
> data line after the receiver has toggled the clock.

That's a bit short for a protocol discription.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\02\26@021625 by Wouter van Ooijen

face picon face
> And similar descriptions apply for U2 to U1 transmissions.

But how do you resolve when both sides attempt to transmit at the same
time?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\26@021625 by Wouter van Ooijen

face picon face
> I'm 99.9% sure I can do bidirectional, half-duplex no-timing-needed,
> digital-realm communications with 2 open-collector outputs capable of
> self-read.

I agree for uni-directional, but how would you do half-duplex?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\26@021625 by Wouter van Ooijen

face picon face
> I think the solution may be in the analogue regime, You could
> do it with
> 1 pin per pic a cap and some resistors.
> Analouge gives you the ability to communicate multiple bits
> of data over
> one line. The question is, how.

Without any details I would say: a capacitor has timing aspects, so it
can't be part of the solution.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\26@024740 by William Chops Westfield

face picon face
>
> I agree for uni-directional, but how would you do half-duplex?
>
For anything that works uni-directionaly, can't you just require
a software layer to do line turn around or polling to get data
in the reverse direction?

BillW

2007\02\26@024946 by Jake Anderson

flavicon
face
Wouter van Ooijen wrote:
>> I think the solution may be in the analogue regime, You could
>> do it with
>> 1 pin per pic a cap and some resistors.
>> Analouge gives you the ability to communicate multiple bits
>> of data over
>> one line. The question is, how.
>>    
>
> Without any details I would say: a capacitor has timing aspects, so it
> can't be part of the solution.
>
> Wouter van Ooijen
>  
The only "timing" is for the pic to be able to look at the voltage on
the pin when it isn't activly driving it.
So its not a timing between the pics, its an "internal timing" issue.
IE you need to hold the voltage long enough to read the ADC.

So some kind of 55 farad ultracap might do the job ;-> Provided the time
between making the port an input and doing the reading is within a few
seconds.

2007\02\26@030152 by Forrest W Christian

flavicon
face
Wouter van Ooijen wrote:

> I agree for uni-directional, but how would you do half-duplex?

Forgetting the whole collision-advoidance/detection issue for a second
(again more software), I would submit that if you had two PIC's
connected with open-collector, self-reading outputs (resistor pullup),
that either machine could initiate a transfer as described.   That is,
assuming both lines are high, there is nothing to say that either
processor could yank a line low initiating a conversation with it as the
master end.  

Collision advoidance/detection would be fun, but in reality, as long as
you checked that both lines were high just before you yanked one down,
the window of opportunity for a collision would be minimal.

If this was going into an actual product I would have to figure out how
to handle the states where both processors yanked a line down at the
same time - both the same and the opposite line.

-forrest

2007\02\26@031918 by Wouter van Ooijen

face picon face
> > I agree for uni-directional, but how would you do half-duplex?
> >
> For anything that works uni-directionaly, can't you just require
> a software layer to do line turn around or polling to get data
> in the reverse direction?

I think there will be a timing problem at the turnaround moment, but I
might just be pessimistic.

The last phase of sending bit is that the receiver makes his handshake
link high. Now the former receiver can start sending, but only after he
is sure that the former sender knows he has made his handshake line
high. How is the receiver to know when this is the case?

Maybe this can be solved by requiring that the new senser first sends
the inverse of the last sent bit.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\02\26@031918 by Wouter van Ooijen

face picon face
> The only "timing" is for the pic to be able to look at the voltage on
> the pin when it isn't activly driving it.
> So its not a timing between the pics, its an "internal timing" issue.
> IE you need to hold the voltage long enough to read the ADC.
>
> So some kind of 55 farad ultracap might do the job ;->
> Provided the time
> between making the port an input and doing the reading is within a few
> seconds.

But the requirement was that *neither* PIC has *any* control over its
timing.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\26@040437 by Wouter van Ooijen

face picon face
> Forgetting the whole collision-advoidance/detection issue for
> a second
> (again more software), I would submit that if you had two PIC's
> connected with open-collector, self-reading outputs (resistor
> pullup),
> that either machine could initiate a transfer as described.  
> That is,
> assuming both lines are high, there is nothing to say that either
> processor could yank a line low initiating a conversation
> with it as the
> master end.  

I start to send an 0 and pull line A low. Next I see line B has been
pulled low. Is this the acknowledge for my pulling A low, or an attempt
from my peer to start sending a 1?

> Collision advoidance/detection would be fun, but in reality,
> as long as
> you checked that both lines were high just before you yanked
> one down,
> the window of opportunity for a collision would be minimal.

I think you can reread that and see it makes no sense. In the 'no
control over timing' situation there is no 'just before'. And whoever
small the windows of trouble, you must still be able to deal with it
propperly.

> If this was going into an actual product I would have to
> figure out how
> to handle the states where both processors yanked a line down at the
> same time - both the same and the opposite line.

IMHO you should make sure that it *can* be done before commiting to do
it!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\26@043207 by Dario Greggio

face picon face
Jake Anderson wrote:

>Analouge gives you the ability to communicate multiple bits of data over
>one line. The question is, how.

VRef pin on some 18F parts (2550, 2520?) can be used as some kind of DAC
(it has high impedance, though...) with 4 bit resolution; one A/D input,
and maybe 16 bits on a line is done :)

--
Ciao, Dario

2007\02\26@051143 by Russell McMahon

face
flavicon
face
I've just seen this thread and there's too much to read to check if
this has been mentioned, so may have been covered:

The use of a "hybrid" as used in telephony applications to convert 2
wire to 4 wire and back can give you additional signal paths at no
extra cost in interconnections.

Cost is one connection wire and two pins. A differential comparator or
ADC would make life easier BUT use of standard port pins and some
careful-magic [tm] may suffice.

In this case, using a single interconnecting "wire" (plus ground) and
a hybrid means the receive path could be used to eg carry a clock or
other signal from the far end which was transparent to the transmitted
signal.

Hybrids are usually implemented actively or with transformers, but a
passive hybrid can be implemented with a few resistors. The receive
circuit is usually implemented with a comparator, but by using high
value summing resistors to a single port pin, and depending on the
port pins characteristics, one may be able to get a reliable digital
result based on the varying analog levels for the 4 combinations of
txd and rxd.

Rather than provide a circuit, here's the basic configuration which
you can run through your mental plus BOTE SPICE emulator.

X & Y are circuit nodes.
R1' = R1 for the other processor.

R1    LocalPin1 X
R1'    X    RemotePin1
R3    LocaPin1    Y
R4    Y    Gnd
R5    Y    LocalPin2
R6    X     LocalPin2

R1 = R2 = lowish
R3 = R4 = somewhat lowish
R5 & R6 highish value and adjusted to create sum voltage at LocalPin2
that is useful.

X & Y would usually drive a comparator making R6 & R7 and arcane port
pin designing unnecessary.


Use of an A2D at LocalPin2 makes life trivially easy :-)



       Russell

____________

2007\02\26@054021 by Wouter van Ooijen

face picon face
> The use of a "hybrid" as used in telephony applications to convert 2
> wire to 4 wire and back can give you additional signal paths at no
> extra cost in interconnections.

We were talking about timeless/timeindependent protocols. I think
telephone-style forks in practice always have so time (=frequency)
dependence, so they would not be suitable.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\26@055041 by Alan B. Pearce

face picon face
>- A few external passives are allowed, but no additional ICs.
>
>Challenge: How few connections between the PICs can you get
>away with, not counting power and ground?  How few pins?

2 pins and 2 resistors. Look at the protocol that TI uses on the TI-83 and
related calculators. It is a totally self clocked bi-directional protocol
that can be done with a pure state machine.

See http://www.ticalc.org/pub/text/calcinfo/tixx_guide.zip for info.

2007\02\26@055538 by Alan B. Pearce

face picon face
>A few years ago I was thinking about a what I called TIP,
>a Time Independent Protocol. It was for communication bewteen
>two chips that can assume *nothing* about timing (one could
>be running at 0.001 ... 10000 x the speed of the other, and
>the speeds can vary arbitrarily). I used open-collector pins
>to interface,

This is exactly what the TI calculator protocol does. (see previous
message).

>and I think I could prove that unidirectional communication
>required 2 lines, bidirectional 3 lines.

They do bidirectional with 2 lines - but it is half duplex.

>I am not sure your restrictions are the same, if you can create
>bi-directional over less than two lines I'd be surprised.

That would require timing constraints that are specifically excluded in
Timothys requirements I believe.

2007\02\26@055953 by Alan B. Pearce

face picon face
>To do so without using an interrupt looks like Timothy is
>doing something similar to Virgin Birth...

No, by using state machines at both ends that keep in sync by handshaking
both lines, the TI calculator protocol does exactly what Timothy is asking
for.

2007\02\26@060653 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: piclist-bouncesspamspam_OUTmit.edu [@spam@piclist-bouncesKILLspamspammit.edu]
>On Behalf Of Forrest W Christian
>Sent: 26 February 2007 05:19
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] Timeless communication protocols
>
>
>I'm 99.9% sure I can do bidirectional, half-duplex no-timing-needed,
>digital-realm communications with 2 open-collector outputs capable of
>self-read.

A slightly adpated I2C multi-master system would acheive this I think, i.e Master becomes a slave after finishing it's transmission.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\02\26@060825 by Alan B. Pearce

face picon face
>I think you can do it with one bi-directional data line and
>two handshake lines (one in each direction), with a SW protocol
>to change direction (which implies a master/slave, I think.)
>A data bit ready is indicated by changing the state of the handshake
>line to the receiver, and changing the state of the handshake line
>coming back indicates the bit was received.

That is sort of like the TI calculator protocol.

2007\02\26@061145 by Alan B. Pearce

face picon face
>Here are examples for U1 transmitting 1's and 0's to U2.
>
>U1 transmits a '1' to U2:
...
>U1 transmits a '0' to U2:

That is very similar to the TI calculator protocol, but seems to have more
steps in each exchange. I seem to remember only 4 states for each exchange,
where Scott has 6.

2007\02\26@061813 by Alan B. Pearce

face picon face
>Or, to put it another way:  Whichever line goes low first is what the
>bit is - a mark or a space.   The other processor acknowleges that it
>saw the bit by yanking the opposite line low.  The sending processor
>acknowedges that it saw the second processor got the bit by returning
>it's bit to high, and the far end processor acknowleges this by turning
>it's bit back high.


Yes that is the TI-Calculator protocol.

2007\02\26@065959 by Wouter van Ooijen

face picon face
> 2 pins and 2 resistors. Look at the protocol that TI uses on
> the TI-83 and
> related calculators. It is a totally self clocked
> bi-directional protocol
> that can be done with a pure state machine.
> See http://www.ticalc.org/pub/text/calcinfo/tixx_guide.zip for info.

Alan, I understand the 'send' part (exactly what I and others had found
independently), but I don't understand the 'receive' flowchart. It
starts with a diamond (choice) with only one outgoing line (probably the
other should loop back?), and immediately after that there is another
choice with partially the same condition. That looks definitely like a
timing dependency.

The protocol also uses timing to signal an abort, but that is an extra
above the bit-level protocol, so I won't hold it against it.

Another note on time-independent protocols: I would also require that
the proctocol is lockup-free: whatever state the two sites start in,
after a finite (and reasonable?) number of exchanges they must be able
to communicate. This facilitates error recovery, independent
powerup/reset, and hot-plugging.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\26@090607 by Gerhard Fiedler

picon face
Michael Rigby-Jones wrote:

> From Forrest W Christian
>>
>> I'm 99.9% sure I can do bidirectional, half-duplex no-timing-needed,
>> digital-realm communications with 2 open-collector outputs capable of
>> self-read.
>
> A slightly adpated I2C multi-master system would acheive this I think,
> i.e Master becomes a slave after finishing it's transmission.

Wouldn't this require that the current slave (receiver) can follow the
current master's (sender's) clock speed? There's the clock extension thing,
but this works only in one clock direction, and need to come before it's
too late.

Gerhard

2007\02\26@092022 by Michael Rigby-Jones

picon face


{Quote hidden}

Clock stretching works in the direction that's important, i.e. the slave can bring the speed of the master down to wherever it feels comfortable.  However the fact that only whole bytes are acknowledged rather than individual bits means that it's probably less suitable as a polled software only protocol between devices with widely differing speeds.  Using an external interrupt for the incomming clock would fix this.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\02\26@094825 by Timothy J. Weber

face picon face
Just catching up - whew!

Several people noted that the 2-line solution has been done by TI.
Thanks - good to know.

Vasile Surducan wrote:
>> Jake Anderson wrote:
>>> I think the solution may be in the analogue regime, You could do it
with
>>> 1 pin per pic a cap and some resistors.
>>> Analouge gives you the ability to communicate multiple bits of data
over
>>> one line. The question is, how.
>> Bingo!
>
> Bingo but looser. You need voltage to current conversion for long
> lines.

Long lines are not a requirement.

Wouter van Ooijen wrote:
> I start to send an 0 and pull line A low. Next I see line B has been
> pulled low. Is this the acknowledge for my pulling A low, or an attempt
> from my peer to start sending a 1?

I would say that your peer isn't allowed to send something until you've
sent it a command telling it to.  That is, you have to have a
master/slave relationship, with the slave sending only when requested.

Not sure about the threading - you may have been talking about NOT
requiring master/slave; if so, I agree, I can't see how that would fit
here either.

And also:
> Another note on time-independent protocols: I would also require that
> the proctocol is lockup-free: whatever state the two sites start in,
> after a finite (and reasonable?) number of exchanges they must be able
> to communicate. This facilitates error recovery, independent
> powerup/reset, and hot-plugging.

I agree, and I haven't solved that yet.  The best I've come up with so
far is something like this:

Send data as 8 bits with an inverted parity bit following.  I.e., 0 is
sent as binary 0000 0000 1.

Start a new message with some large number of 0 bits (18 seems like
enough, but fewer may be sufficient), followed by a 1.

On a parity error, or on startup, or whenever you're confused, wait for
that startup string, then begin again.

If the master has asked for a response from the slave, and the slave
takes an eternity to respond (seconds, e.g.), give up and take over
again.  This violates the requirement for complete time-independence.
But, in my original application, slow (second-resolution) timekeeping is
globally available, and I bet for most applications, you can define both
some glacial measurement of time and a length of time beyond which you
assume your peer is dead.
--
Timothy J. Weber
http://timothyweber.org

2007\02\26@094839 by Timothy J. Weber

face picon face
part 0 44 bytes
his is a multi-part message in MIME format.
part 1 3193 bytes content-type:text/plain; charset=ISO-8859-1; format=flowed (decoded 7bit)

Russell McMahon wrote:
> The use of a "hybrid" as used in telephony applications to convert 2
> wire to 4 wire and back can give you additional signal paths at no
> extra cost in interconnections.
>
> Cost is one connection wire and two pins. A differential comparator or
> ADC would make life easier BUT use of standard port pins and some
> careful-magic [tm] may suffice.

I can't parse the text description as is and haven't drawn it out so I
can... but it sounds very similar to what I came up with.

And I think you're right that the careful-magic [tm] might work with
regular pins - there are some transitions where it works out easily - but...

> Use of an A2D at LocalPin2 makes life trivially easy :-)

... and that's what I decided.

(See, I predicted you'd say "Yuck"!)

Schematic is attached.  Important nodes are A and B (pins driven by the
two PICs) and C (the single connecting line, read by both PICs).

With the resistor values specified, the algorithm relies on one somewhat
uncomfortably precise A/D measurement, one nicely sloppy one, and some
plain logic pin readings.  Here's what I have so far:

Sender:

Initialize:
       Tristate A.
Bit:
       Pull A low.  C goes to about 77/1024 * V+.
       Wait for A/D on C to go under about 59 (should go down to 40).
       Choose the bit value you want to send.
Send0:
       Tristate A.
       Wait for C to go back to logic 1.
       Loop to Bit if there's more to send.
Send1:
       Set A to 1.  C goes to about 50%.
       Wait for A/D on C to go very high - say, over 75%.
       Tristate A, or loop to Bit if there's more to send.

Receiver:

Bit:
       Tristate B.  C is pulled up to logic 1.
       Wait for C to go low.
       Set B low.
       Wait for A/D on C to rise over about 59.
       Read C's value as the next bit.
       Loop to Bit.

The uncomfortably precise A/D is where we need to differentiate between
values of about 40/1024 and 77/1024.  This is where the magic 59 comes
in - splits the difference between them.  A bit tight, but perhaps
feasible.  It's clearly the weak point.

And, these expected A/D values are calculated assuming the outputs A and
B are at 100% of V+ for logic 1 and 0% for logic 0.  That's not true in
practice, so I need to redo the numbers with ranges, and see how narrow
that detection window gets.  Having to tune those values to the specific
implementation would be annoying.  At present, I think 5% resistors are
just on the border, 1% is probably required.  More judicious choices for
R1, R2, and R3 may help some.  I could post my spreadsheet, but it's a
bit messy at the moment.

Allowing 40 us for each A/D acquisition and conversion and some sloppy
estimates for the rest of the phases gives about 104 us/bit if both ends
are doing nothing else, which is around 9600 bps.

It seems like there may be more states than necessary, and if it could
use just the states that produce more reliably-distinguishable A/D
values I'd be happier.  (E.g., A/B = 0/0, 0/1=1/0, 1/1, x/0=0/x are all
easily distinguishable.)

I'm sure y'all can improve on this; suggestions, counter-arguments,
insults, etc. are all welcome.
--
Timothy J. Weber
http://timothyweber.org


part 2 6880 bytes content-type:image/png; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2007\02\26@102113 by Alan B. Pearce

face picon face
>I'm sure y'all can improve on this; suggestions,
>counter-arguments, insults, etc. are all welcome.

Well, for the distance you were talking of doing this over originally, I
cannot see the need for this complexity to get it down to one wire, from the
two wire of the TI-calculator system. It seems to me that it may possibly
need more processor overhead as well, without going to the extent of a
worked example.

2007\02\26@102139 by Bob Axtell

face picon face
Timothy J. Weber wrote:
{Quote hidden}

Not very fast, though, right? Looks to be about 500baud max..

--Bob

2007\02\26@104833 by Alan B. Pearce

face picon face
>> that can be done with a pure state machine.
>> See http://www.ticalc.org/pub/text/calcinfo/tixx_guide.zip for info.
>
>Alan, I understand the 'send' part (exactly what I and others had found
>independently), but I don't understand the 'receive' flowchart. It
>starts with a diamond (choice) with only one outgoing line (probably the
>other should loop back?), and immediately after that there is another
>choice with partially the same condition. That looks definitely like a
>timing dependency.
>
>The protocol also uses timing to signal an abort, but that is an extra
>above the bit-level protocol, so I won't hold it against it.
>
>Another note on time-independent protocols: I would also require that
>the proctocol is lockup-free: whatever state the two sites start in,
>after a finite (and reasonable?) number of exchanges they must be able
>to communicate. This facilitates error recovery, independent
>powerup/reset, and hot-plugging.

I don't quite know how you can do anything else but timing to signal an
abort or timeout - even Timothys one wire solution is going to need to do
that I think.

Another link that may help explain the protocol is this one (which extracts
to a web page with pictures, along with some more zip files).

http://www.ticalc.org/pub/text/calcinfo/link86all.zip

But for a long time I have considered this to be an ideal comms format for
off loading a function (such as front panel or LCD display handling) from a
"main" processor, without requiring I2C or SPI hardware, and yet requiring
minimal software.

2007\02\26@105437 by Alan B. Pearce

face picon face
>Wouter van Ooijen wrote:
>> I start to send an 0 and pull line A low. Next I see line B has been
>> pulled low. Is this the acknowledge for my pulling A low, or an attempt
>> from my peer to start sending a 1?
>
>I would say that your peer isn't allowed to send something until you've
>sent it a command telling it to.  That is, you have to have a
>master/slave relationship, with the slave sending only when requested.
>
>Not sure about the threading - you may have been talking about NOT
>requiring master/slave; if so, I agree, I can't see how that would fit
>here either.

IIRC in the TI case, the transmission is started by a human pushing a button
(or equivalent action) on one of the devices. Until then the transmission
lines are totally benign, and in the rest state.

If wanting to use this system where there is no external event to start the
communication, then I gues some form of master-slave relationship will be
required.

2007\02\26@110109 by Wouter van Ooijen

face picon face
> (See, I predicted you'd say "Yuck"!)

both clever and yuck (I like clever!)

A problem: when the receiver reads the bit value it waits for the A/D to
raise over 59, then reads either 59..77, or 50%. But when you read
59..77, how do you know that the voltage is not 'on its way' to 50%?
What might help is first wait until it is within 59..77, and then wait
at least a certain amountr f time, and then measure again. I don't like
this, it re-introduces time...

Note that the above is a general problem when a state change passes
through intermediate states.

Logically it is not that different from the 2 OC lines, so I think it
probably has the same problem: how to arbitrate the half-duplex flow?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\26@111038 by Timothy J. Weber

face picon face
Bob Axtell wrote:
>> Allowing 40 us for each A/D acquisition and conversion and some sloppy
>> estimates for the rest of the phases gives about 104 us/bit if both
>> ends are doing nothing else, which is around 9600 bps.
[snip]
> Not very fast, though, right? Looks to be about 500baud max..

Maybe I miscalculated, but 9600 is what I get.

In practice it would be slower of course, since the requirements make no
sense unless something else is taking a lot of run-time.
--
Timothy J. Weber
http://timothyweber.org

2007\02\26@111720 by Timothy J. Weber

face picon face
Alan B. Pearce wrote:
>> I'm sure y'all can improve on this; suggestions,
>> counter-arguments, insults, etc. are all welcome.
>
> Well, for the distance you were talking of doing this over originally, I
> cannot see the need for this complexity to get it down to one wire, from the
> two wire of the TI-calculator system. It seems to me that it may possibly
> need more processor overhead as well, without going to the extent of a
> worked example.

I agree.  I think mine fits the requirements, but the requirements are
wrong.  :)  Fun exercise, though!

I'll probably use the TI calculator system in practice.

> But for a long time I have considered this to be an ideal comms format for
> off loading a function (such as front panel or LCD display handling) from a
> "main" processor, without requiring I2C or SPI hardware, and yet requiring
> minimal software.

I think you're right - mine doesn't improve on that except in the case
where lines are expensive, which seems unusual unless the lines are
long, in which case it doesn't work (or you'll need to really tweak it).
--
Timothy J. Weber
http://timothyweber.org

2007\02\26@113024 by Timothy J. Weber

face picon face
Wouter van Ooijen wrote:
>> (See, I predicted you'd say "Yuck"!)
>
> both clever and yuck (I like clever!)

I'm glad to get at least some clever with the yuck!

> A problem: when the receiver reads the bit value it waits for the A/D to
> raise over 59, then reads either 59..77, or 50%. But when you read
> 59..77, how do you know that the voltage is not 'on its way' to 50%?
> What might help is first wait until it is within 59..77, and then wait
> at least a certain amountr f time, and then measure again. I don't like
> this, it re-introduces time...

Good point.  You could specify two consecutive reads that are "close,"
figuring that rise time to 50% will be generally be far shorter than one
A/D cycle time (again, dependent on short transmission lines and low
capacitance).

> Note that the above is a general problem when a state change passes
> through intermediate states.

Right.  One good reason why trinary never caught on.

> Logically it is not that different from the 2 OC lines, so I think it
> probably has the same problem: how to arbitrate the half-duplex flow?

Yes.  Again, I think the trade-off is to require something in the higher
level protocol - a token kind of thing.  It seems acceptable to me.

The original motivation was that I had two old boards that, together,
could solve a new problem - but I only had access to a couple of pins on
each board's PIC.  In this case, it's OK to have the master update the
slave's status, then every now and then say, "By the way, has anything
changed on your end?", receive one status byte, and gain control back.
--
Timothy J. Weber
http://timothyweber.org

2007\02\26@122940 by Alan B. Pearce

face picon face
>> Note that the above is a general problem when a state change passes
>> through intermediate states.
>
>Right.  One good reason why trinary never caught on.

I don't think that trinary didn't catch on for this reason. But trinary
devices do exist, check out the Motorola MC14502x series devices, designed
for remote control (door openers etc) type use. They use trinary addressing
to minimise the number of pins used to get the maximum number of addresses
from those pins.

But once the trinary address is determined it is then transmitted by two
bits of binary data, resulting in a 25% waste of bit states. This is most
likely the reason it did not catch on in a big way. For the price of a few
more pins it is possible to get more data sent.

It was an arrangement like this that I first assumed when you started
talking of trinary data.

2007\02\26@132827 by Wouter van Ooijen

face picon face
> Another link that may help explain the protocol is this one
> (which extracts
> to a web page with pictures, along with some more zip files).
>
> http://www.ticalc.org/pub/text/calcinfo/link86all.zip

Good description of the simplex communication, but I see now
explaqnation of how direction switching is done.


Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2007\02\26@134631 by Scott Dattalo

face
flavicon
face
Timothy J. Weber wrote:
>
> I can't parse the text description as is and haven't drawn it out so I
> can... but it sounds very similar to what I came up with.
>
Russel's description is different than yours in that in his both pins of
the PIC have a resistor between them and the communication line.

<snip> algorithm
> The uncomfortably precise A/D is where we need to differentiate
> between values of about 40/1024 and 77/1024.  This is where the magic
> 59 comes in - splits the difference between them.  A bit tight, but
> perhaps feasible.  It's clearly the weak point.

I think you can significantly reduce the tight A/D requirements.
Furthermore, I think it's possible to enhance the design by adding a
collision detection.

First, with a tri-state output there are three states: Z, L and H. With
two tri-state outputs, there are nine possible combinations, but only 6
possible voltages when the outputs are interconnected. It should be
possible to realize all 6 of these unique combinations. In your circuit,
there are 3 resistors. Add one more resistor between node C and ground;
call it R4. Now let the values be:

R1=R3=R4 =  Nominal R
R2 = half of Nominal R

If the two tristate I/O's are A and B then the six states are:


AB     Vc
----------
ZZ    2/3
ZL    1/2
ZH    3/4
LL    2/5
LH    3/5
HH    4/5

The two closest states (in terms of voltage) are the ZH and HH states,
so you'd probably want to avoid state transitions between them.

Here is one possible state transition sequence for sending a 0 from A to B
ZZ -> LZ -> LH -> ZH -> ZZ
And the state transitions for sending a 1 from A to B:
ZZ -> HZ -> HL -> ZL -> ZZ

Notice that the LL and HH states are absent. If these occur then this
means there was a collision; both devices attempted to transmit a 0 or
or a 1 at the same time.  The recovery can be:

ZZ -> LL -> LH -> HH -> ZH -> ZZ
and
ZZ -> HH -> LH -> LL -> ZL -> ZZ

You don't want to make the transition ZZ -> LL -> LZ because you can't
guarantee both devices saw the LL state. Flowing through both 'illegal'
states ensures each device recognized the contention.

The only other collision state is when one device sends a 0 and the
other simultaneously sends a 1. You can stipulate that the one that
drove a 0 must initiate the recovery:

ZZ -> LH -> HH -> ZH -> ZZ

The error recovery sequence unfortunately requires a state transition
between ZH and ZZ. So you'll definitely want to check the error budget
(e.g. when using 1% resistors).

Finally, even with the collision detection, you'll probably still want
some kind of time out error recovery mechanism.

Scott

2007\02\26@140312 by Richard Prosser

picon face
I think  have at least a partial solution using only one wire & 1 pin per micro.
It is based on the receiver detecting the tristate output of the
transmitter. The hardware comprises of 2 low value (220ohm?)
resistors, a 100pF cap to ground at the junction of the 2 resistors
and a optional high value (100k ? ) pullup or pulldown  resistor.

It isn't going to break any speed records though as to test the line a
micro has to:-
a) sample the input state of the line,
b) drive the line in the opposite state
c) wait a few nops (depending on R & C values used)
d) return the pin to input condition.
e) wait a few more nops
f) sample the line again. If in same state as initially tested in a)
then the line is being driven. If in the same state as it just set the
line to in b),  then the "other end" is in high impedance mode.

Operation is then:-
1. The line normally idles with both micro pins set as inputs - high
impedance mode.
2. To send a bit then "A" tests the line and if in HiZ mode, sets the
line in accordance with the first data bit.
3."B" eventually tests the line, sees it is being driven and sets
itself to drive the line in the same polarity and records the value.
4. Unit "A" comes around again, tests the line itself and determines
it is being driven in the same polarity as the TX bit so notes the bit
has been received and sets the drive back to high impedance. If the
line is being driven low it registers this as a collision and restarts
the sequence in the next loop.
5 Once"B detects the line is back to HiZ, it responds by putting the
line into HiZ mode itself, awaiting the next bit.
6. "A" will not regard the bit transmission complete until it sees a
HiZ condition on the line.

There is no Master/Slave hieracrchy, either unit can initiate transmission.
There are timing limits, based on leakage currents, line capacitance
and pullup resistor size but these can largely be adjusted to suit the
actual requirements.

Obviously to send a byte of data a higher level protocol will also be
needed, to include parity or and/or start/stop bits. As there are
oppertunities for collisions and corruption, some overall rules will
need to be applied to handle errors, but should be possible.

The biggest problem will be collisions that occur when both units test
the line at the same time. This will occur eventually so needs to be
handled gracefully. I haven't quite figured it out but some sort of
timeout may have to be involved. Of course, if the data being sent is
ASCII then then a range of control codes are available to handle this.
Maybe the protocol should include control codes - all starting with a
high bit, as opposed to data  bytes which all start with a low bit?

Anyone see why it can't work - at least for slow, sparce data?

Richard Prosser


On 26/02/07, Wouter van Ooijen <TakeThisOuTwouterEraseMEspamspam_OUTvoti.nl> wrote:
{Quote hidden}

> -

2007\02\26@161311 by John La Rooy

flavicon
face
On 2/27/07, Richard Prosser <RemoveMErhprosserspamTakeThisOuTgmail.com> wrote:
>
>
> 3."B" eventually tests the line, sees it is being driven and sets
> itself to drive the line in the same polarity and records the value.
> 4. Unit "A" comes around again, tests the line itself and determines
> it is being driven in the same polarity as the TX bit so notes the bit
> has been received and sets the drive back to high impedance. If the
> line is being driven low it registers this as a collision and restarts
> the sequence in the next loop.


What happens here if A is testing the line for acknowlegement at the time
that B tries to also test it to read the polarity?

John La Rooy

2007\02\26@164320 by Richard Prosser

picon face
That would either be detected a collision, or the bye would fail
parity or the block would fail checksum.
I'm still trying to sort out the exact details of how this sort of
thing could be handled but will probably have to mock up a system to
find all the pitfalls.

Or Possibly the TX and RX side could carry out their tests twice, but
with slightly different delays? An inconsistant test would again be
treated as a collision. (I'm not considering delays as going against
the "Timeless" requirement as they would be included in the TX or RX
subroutine and are independent of the other unit.)

RP
On 27/02/07, John La Rooy <piclist.jlrEraseMEspam.....larooy.com> wrote:
{Quote hidden}

> -

2007\02\26@165153 by Gerhard Fiedler

picon face
Michael Rigby-Jones wrote:

>>> A slightly adpated I2C multi-master system would acheive this I think,
>>> i.e Master becomes a slave after finishing it's transmission.
>>
>> Wouldn't this require that the current slave (receiver) can follow the
>> current master's (sender's) clock speed? There's the clock extension
>> thing, but this works only in one clock direction, and need to come
>> before it's too late.
>
> Clock stretching works in the direction that's important, i.e. the slave
> can bring the speed of the master down to wherever it feels comfortable.
>  However the fact that only whole bytes are acknowledged rather than
> individual bits means that it's probably less suitable as a polled
> software only protocol between devices with widely differing speeds.
> Using an external interrupt for the incomming clock would fix this.

I2C has lots of timing requirements, it seems to me. The slave needs to
recognize the start and stop conditions, without the help of clock
stretching: if the slave isn't reading the data at this precise moment, the
start condition is already gone without being recognized by the slave. The
slave needs to hold the clock low before it goes back up high when it wants
to stretch the clock: if it isn't there to read the first clock pulse going
low and back up high, the opportunity for stretching this bit is already
gone. There are probably more.

There's a reason (or two :) why an I2C slave isn't exactly trivial in
firmware only (without any hardware support) if the processor has other
stuff to do also.

Gerhard

2007\02\26@165935 by PAUL James

picon face

All,

It seems to me that with the talk so far about this, it appears as
though this is a peer to peer system.
So when one unit talks, the other one listens.  And if it is listening,
it knows enough not to talk at
The same time.  Or at least I would think so anyway.

If it master to slaves, then there must be a way of addressing which
device you want to talk to.  If this
Is the case, then when each slave notices that there is a bit on the
line, it would participate in the handshake
By pulling the other line low momentarily, then releasing the line.
This would tell all slaves that there is a transmission about to come
down the pipe, and that everybody listen and nobody handshake.  The
master will assume
That all units have received the address message.   When the unit that
was addressed sees a match between it's address and the address sent in
the message, it responds by pulling one or the other of the lines low.
This signals the master that the intended receiver has received the
address message hand has matched the address sent.
>From here on out, the conversation between the master and slave is a one
to one transfer.  And the other slaves
Know not to talk until the bus has been released by broadcasting a Bus
Clear message to all slaves.  All slaves listen all the time.  They just
don't speak back until invited by an address.


       
Regards,

       
Jim

{Original Message removed}

2007\02\26@173236 by Timothy Weber

face picon face
Scott Dattalo wrote:
> First, with a tri-state output there are three states: Z, L and H. With
> two tri-state outputs, there are nine possible combinations, but only 6
> possible voltages when the outputs are interconnected. It should be
> possible to realize all 6 of these unique combinations. In your circuit,
> there are 3 resistors. Add one more resistor between node C and ground;
> call it R4. Now let the values be:
>
>  R1=R3=R4 =  Nominal R
>  R2 = half of Nominal R

I like it.  I was avoiding a non-logic-stable "rest state", but I'm not
sure there's any reason to.  This means you're using A/D for all the
steps (I think), but that's also not a big deal.  And it addresses that
tight spot.

> Notice that the LL and HH states are absent. If these occur then this
> means there was a collision; both devices attempted to transmit a 0 or
> or a 1 at the same time.  The recovery can be:
>
> ZZ -> LL -> LH -> HH -> ZH -> ZZ
> and
> ZZ -> HH -> LH -> LL -> ZL -> ZZ

I don't grok this yet, but I'll stare at it some more.

> Finally, even with the collision detection, you'll probably still want
> some kind of time out error recovery mechanism.

Agreed.  There's no other way to handle the situation when the other end
disappears at an arbitrary time and you want to recover gracefully when
it reappears.  (that I can see)
--
Timothy J. Weber
http://timothyweber.org

2007\02\26@173932 by Timothy Weber

face picon face
Richard Prosser wrote:
> I think  have at least a partial solution using only one wire & 1 pin per micro.
> It is based on the receiver detecting the tristate output of the
> transmitter. The hardware comprises of 2 low value (220ohm?)
> resistors, a 100pF cap to ground at the junction of the 2 resistors
> and a optional high value (100k ? ) pullup or pulldown  resistor.
[snip]
> The biggest problem will be collisions that occur when both units test
> the line at the same time. This will occur eventually so needs to be
> handled gracefully.

I think it will be easy to get something that works 99% of the time, but
I think you'll always be able to find a pathological timing sequence
where both ends keep saying "Hello?" simultaneously ad infinitum.

If you add some kind of random or per-unit delay, and are very careful
with the protocol, maybe it won't cause problems in practice... but I
think you'd be talking about statistical likelihood of failure rather
than deterministic behavior.

It reminds me of multi-threaded code.  Without some kind of mutex or
semaphore, race conditions will happen no matter how quickly you can
switch between setting a value and checking it.  You have to have
something held stable while you change something else.

That's just a gut reaction, though - can't prove that it's impossible!
--
Timothy J. Weber
http://timothyweber.org

2007\02\26@174332 by Timothy Weber

face picon face
PAUL James wrote:
> It seems to me that with the talk so far about this, it appears as
> though this is a peer to peer system.
> So when one unit talks, the other one listens.  And if it is listening,
> it knows enough not to talk at
> The same time.  Or at least I would think so anyway.

I agree.

> If it master to slaves, then there must be a way of addressing which
> device you want to talk to.  If this
> Is the case, then when each slave notices that there is a bit on the
> line, it would participate in the handshake
> By pulling the other line low momentarily, then releasing the line.

Ooh... We've been talking about a single slave so far.  Multiple slaves
is much more complex.

Essentially, you need to confirm that EVERY slave has received the bit
before you're done sending it.  And they might try to acknowledge it all
at the same time.

I suppose you could figure out A/D values for LZZZZ vs. LLZZZ vs. LLLZZ
etc. (using Scott's notation with four slaves for example), and consider
it fully acknowledged when you get to LLLLL (but not LLLLZ), but that's
splitting it quite fine.
--
Timothy J. Weber
http://timothyweber.org

2007\02\27@003535 by Forrest W Christian

flavicon
face
Wouter van Ooijen wrote:

>I start to send an 0 and pull line A low. Next I see line B has been
>pulled low. Is this the acknowledge for my pulling A low, or an attempt
>from my peer to start sending a 1?
>  
>
You don't know.  Quite simply, you assume it's the case where
communication is correct.  Maybe it's my longstanding network
experience, but it seems to me that this is more a question for
something higher up in the stack.

The communication we discussed here is a 99% reliable way of
transmitting data end to end.  Yes, there are problems - specifically,
where you have both ends being able to transmit across the bus there are
issues where you have bus contention.  This is absolutely no different
than a radio link or any other half-duplex mechanism.  You are going to
have collisions.  Period.   How you deal with collisions is highly
dependant on what you are trying to move.

We're talking about Pure CSMA here.  
(http://en.wikipedia.org/wiki/Carrier_Sense_Multiple_Access ).   Look at
the bus and see if it's in an idle state as late as possible before you
transmit.   Assume that the data you're transmitting is ok.    To some
limited extent, there is some CSMA/CD, since the bus can go into invalid
states if both ends are transmitting.

-forrest

2007\02\27@045158 by Russell McMahon

face
flavicon
face
> This means you're using A/D for all the steps (I think), but that's
> also not a big deal.

If A/D is not a big deal then my hybrid suggestion is viable.
It works easiest where there is one remote present at a time - either
only a single one or many with only one active.

With a hybrid you can single bidirectionally simultaneously (or clock
one way and data the other) on a single wire plus ground.


       Russell

2007\02\27@085753 by Gerhard Fiedler

picon face
Timothy Weber wrote:

> I think it will be easy to get something that works 99% of the time, but
> I think you'll always be able to find a pathological timing sequence
> where both ends keep saying "Hello?" simultaneously ad infinitum.

> It reminds me of multi-threaded code.  Without some kind of mutex or
> semaphore, race conditions will happen no matter how quickly you can
> switch between setting a value and checking it.  You have to have
> something held stable while you change something else.

For example, the CAN bus detection works so that the first time a unit
detects a state different from what it expects on the bus it assumes it has
lost the bus, aborts the transmission and usually retries. It's still
somewhat statistical as nothing is there to guarantee that the same
contention won't happen on every of the programmed number of retries, but
this probability is probably "low enough" in most cases :)

Gerhard

2007\02\27@095450 by Jeff Findley

flavicon
face

"Wouter van Ooijen" <RemoveMEwouterEraseMEspamEraseMEvoti.nl> wrote in message
news:033801c75976$03821c20$0b00a8c0@PAARD...
>> And similar descriptions apply for U2 to U1 transmissions.
>
> But how do you resolve when both sides attempt to transmit at the same
> time?

If one tries to send a 0 while the other tries to send a 1, they could
confuse each other's initial transmission as an acknowledge of data
reception.  This sounds pretty bad to me, so one would consider requiring
transmissions to always start with the same bit, but that has its own
problems...

If both try to send the same bit at the same time, they'll be waiting
forever for the acknowledge because of the "no timing" requirement, since in
this type of situation, you could detect this by timing out after a certain
length of time and both PICs would abort their transmission.

Using only two lines like this will seem to work, most of the time, but
every once in a while I'm guessing the PICs might stop communicating with
each other because they happen to talk at the same time.

Jeff
--
   "They that can give up essential liberty to obtain a
    little temporary safety deserve neither liberty nor
    safety"
- B. Franklin, Bartlett's Familiar Quotations (1919)





2007\02\27@100007 by Jeff Findley

flavicon
face

"Wouter van Ooijen" <RemoveMEwouterspam_OUTspamKILLspamvoti.nl> wrote in message
news:033801c75976$03821c20$0b00a8c0@PAARD...
>> And similar descriptions apply for U2 to U1 transmissions.
>
> But how do you resolve when both sides attempt to transmit at the same
> time?

That's the problem with only using two lines and also requiring "no timing
and no interrupts", isn't it?  If you could use some sort of timing, you
could require all transmissions to start with the same bit and you could
time-out if you don't get an acknowledge after a certain period of time.
Then you still need to come up with a way to make sure the two pics don't
immediately try to talk at the same time again.

Jeff
--
   "They that can give up essential liberty to obtain a
    little temporary safety deserve neither liberty nor
    safety"
- B. Franklin, Bartlett's Familiar Quotations (1919)



2007\02\27@101527 by Byron A Jeff

face picon face
On Tue, Feb 27, 2007 at 09:57:00AM -0500, Jeff Findley wrote:
>
> "Wouter van Ooijen" <RemoveMEwouterTakeThisOuTspamspamvoti.nl> wrote in message
> news:033801c75976$03821c20$0b00a8c0@PAARD...
> >> And similar descriptions apply for U2 to U1 transmissions.
> >
> > But how do you resolve when both sides attempt to transmit at the same
> > time?
>
> That's the problem with only using two lines and also requiring "no timing
> and no interrupts", isn't it?

Actually I think it's an orthogonal problem.

>  If you could use some sort of timing, you
> could require all transmissions to start with the same bit and you could
> time-out if you don't get an acknowledge after a certain period of time.

But timing is out.

> Then you still need to come up with a way to make sure the two pics don't
> immediately try to talk at the same time again.

Again I think it's an orthogonal problem. It's a multi-master issue, not
a timing issue.

A upper level protocol that using polling would resolve this problem because
then there would only be one master in the system.

What isn't resolved is when only one working system is on the line. I think
there has to be some sort of timeout, even if it's an extraordinarily long
one (like 2-3 seconds)

BAJ

2007\02\27@112050 by Bob Axtell

face picon face
Byron A Jeff wrote:
>
>> Then you still need to come up with a way to make sure the two pics don't
>> immediately try to talk at the same time again.
>>    
>
> Again I think it's an orthogonal problem. It's a multi-master issue, not
> a timing issue.
>
> A upper level protocol that using polling would resolve this problem because
> then there would only be one master in the system.
>
> What isn't resolved is when only one working system is on the line. I think
> there has to be some sort of timeout, even if it's an extraordinarily long
> one (like 2-3 seconds)
>
> BAJ
>  

Exactly.

The same problem exists on a single-pair RS422 network. The master
speaks, all slaves listen, but only one
(or none) replies. The rule for all slaves is that if in doubt, shut up;
in any case release the bus as soon
as the stop bit of the last byte of the reply is sent; and a slave NEVER
initiates a communication. This was
used on early CAT3-based RS422 casino player systems.

A single wire between a master PIC and multiple slave PICs is the same
scheme.

Manchester code always works for me, requiring just (1) an interrupt on
the falling edge, and (2) a timer tick
interrupt to measure the length of the bit and the pulse itself.  The
firmware is inordinately simple to write, but
perhaps its because I have done this repeatedly; it uses the same code
words to receive & store a Manchester
byte than to receive and store  a UART byte. The main advantage of the
Manchester scheme is that timing is
not critical, and will work fine with a 10:1 timing range (although I
normally try to keep it tighter than that).

If anyone wants the flow analysis for my Manchester scheme, I will
publish it  here tonight.

--Bob

--Bob

2007\02\27@133935 by peter green

flavicon
face
> I think it will be easy to get something that works 99% of the time, but
> I think you'll always be able to find a pathological timing sequence
> where both ends keep saying "Hello?" simultaneously ad infinitum.
>
> If you add some kind of random or per-unit delay, and are very careful
> with the protocol, maybe it won't cause problems in practice... but I
> think you'd be talking about statistical likelihood of failure rather
> than deterministic behavior.
truth is no system is fully deterministic, there is always a chance that an oscilator will miss a beat or a power spike will come at just the wrong time or a cosmic ray will hit your dram or a mistimed edge on an imput will give you metastability despite your best attempts to stop it.

ultimately you have to decide what level of risk is acceptable and then engineer your system based arround that.


2007\02\27@202236 by Jake Anderson

flavicon
face
Russell McMahon wrote:
>> This means you're using A/D for all the steps (I think), but that's
>> also not a big deal.
>>    
>
> If A/D is not a big deal then my hybrid suggestion is viable.
> It works easiest where there is one remote present at a time - either
> only a single one or many with only one active.
>
> With a hybrid you can single bidirectionally simultaneously (or clock
> one way and data the other) on a single wire plus ground.
>
>
>         Russell
>
>  
I have been trying to work out a way that they can communicate by giving
the master the first 2 bits of the ADC and the slave the next 2, IE the
master speaks in volts the slave in half volts. so you get in effect 4
channels of communication

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...