Searching \ for 'Asynchronours Serial I/O - AN555' 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/io/serials.htm?key=serial
Search entire site for: 'Asynchronours Serial I/O - AN555'.

Truncated match.
PICList Thread
'Asynchronours Serial I/O - AN555'
1997\08\18@220224 by MURRAY PATRICK MAURICE

flavicon
picon face
Hi,
       Has anyone used the interupt driven RS232 comms
program in microchip AN555 on the 16C84?

       From what I can see, it is for the 16C71.

Pat

LT Patrick M Murray      __  /\    Electrical Engineering Department,
4th Year Student        /  \/  \   University College UNSW,
                       /        \  Australian Defence Force Academy,
++61  6 2688    (w)   /         /  Canberra  ACT  2600.
++61  6 2397182 (h)   \   __  */   AUSTRALIA.
++61  6 2688443 (fax)  `-'  \_/
                             .

1997\08\18@222353 by ags

flavicon
face
>         Has anyone used the interupt driven RS232 comms
> program in microchip AN555 on the 16C84?
>
>         From what I can see, it is for the 16C71.
I have used a modified version to work on different pins.  Since I couldn't use
the interrupt for the
Receive I used the timer Interrupt (TMR0) to check for Receive Data.
I actually implemented mine fully in the ISR where you simply set a flag when
you have transmit data
available and a flag is set when receive data is available.
I had very little problems making the modifications and getting it to work.

If you have any problems implementing it, let me know and I will see what I can
do to help.

Good luck!

Alan G. Smith
+---------------------------------------------------------
| Alan G. Smith
| spam_OUTagsTakeThisOuTspampoboxes.com
| http://www.innovatus.com/ags

1997\08\19@001038 by Matt Calder

flavicon
face
Alan,
       Perhaps some more detail would make an interesting thread. I have
been trying various serial protocols to get two PICs (16C84) talking and
am wondering what is the 'best' way. Some of the issues I faced, and I
suppose anyone doing this must face are:

       1) How few pins can I get away with?
       2) How fast can I go?
       3) What is the interrupt mechanism?

My, final design (amatuerish at best), involved timer interrupts, and
flags, perhaps similar to your own. I would be very interested in hearing
what the experts have to say, and also would be interested in any
references for relevent reading material.

       Matt

On Mon, 18 Aug 1997, Alan G. Smith wrote:

> >         Has anyone used the interupt driven RS232 comms
> > program in microchip AN555 on the 16C84?
> >
> >         From what I can see, it is for the 16C71.
> I have used a modified version to work on different pins.  Since I couldn't
use
>  the interrupt for the
> Receive I used the timer Interrupt (TMR0) to check for Receive Data.
> I actually implemented mine fully in the ISR where you simply set a flag when
>  you have transmit data
> available and a flag is set when receive data is available.
> I had very little problems making the modifications and getting it to work.
>
> If you have any problems implementing it, let me know and I will see what I
can
{Quote hidden}

/*****************************************/
/* Matt Calder, Dept. of Statistics, CSU */
/* http://www.stat.colostate.edu/~calder */
/*****************************************/

1997\08\19@065515 by Lee McLaren

flavicon
face
Alan,
Have you concidered connection the chips by a one wire serial bus like
the dallas buttons use.
Its very easy to do in code and because only one chip clocks the data
you dont get any suprises while you are doing other things.
You could poll the outer chips in turn to see if they have any thing to
say.

regards
Lee McLare


Matt Calder wrote:
{Quote hidden}

when
{Quote hidden}

1997\08\19@074220 by Andrew Warren

face
flavicon
face
Matt Calder <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU> wrote:

> I have been trying various serial protocols to get two PICs (16C84)
> talking and am wondering what is the 'best' way. Some of the issues
> I faced, and I suppose anyone doing this must face are:
>
> 1) How few pins can I get away with?

   Matt:

   Depending on what you're doing, you can get away with
   ZERO I/O pins.

   For example:

   Your Master PIC controls the Slave PIC's MCLR line.  The Master
   normally keeps the Slave's MCLR line high (out of reset).  When
   the Master wants to send a message, it pulls the Slave's MCLR
   line low, then pulls it high for a short time before pulling it
   low, then high again.

   The "message" is the time between MCLR-low pulses.

   I've glossed over the details, but if you're only sending
   messages in one direction, and if your Master only needs to send
   a small number of unique messages to the Slave, and if you don't
   need the messages to be sent very quickly, this technique can
   work real well.

> 2) How fast can I go?

   In general, you can trade speed for pins; a one-wire bus, like
   the one that Dallas uses in their Touch Memories, is pretty slow
   (and complicated when you want to communicate in both
   directions).

   Two-wire asynchronous protocols allow easy communication in both
   directions, but they're slow and (if you don't have any
   interrupts) they make it tricky to implement full-duplex
   communications.

   Two-wire synchronous methods, like I2C, can be relatively fast,
   but they don't allow full-duplex bi-directional communications
   without a complicated token-passing protocol or something.

   Three-wire systems with a clock generated by a Master and data
   sent synchronously by each PIC on the other two pins, or a
   two-wire system in which the two PICs take turns transmitting
   one bit at a time on one data line, can be very fast, but don't
   allow the Slave to transmit until the Master gives it a clock.

   A system with a clock and data line for each PIC is fast and
   allows easy full-duplex operation, but (of course) requires four
   pins on each side.

   What I'm saying, I guess, is that there IS no "best" way; the
   protocol you choose is highly dependent upon the needs of your
   application.

   -Andy

=== Andrew Warren - EraseMEfastfwdspam_OUTspamTakeThisOuTix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: listservspamspam_OUTmitvma.mit.edu

1997\08\19@080812 by ags

flavicon
face
>       Perhaps some more detail would make an interesting thread.
Here is the basic idea that I have:
TMR0 interrupt - set for baud/2
On Interrupt -
Are we in the middle of receiving? - If yes, get next bit.  Set TMR0 interrupt
for baud
Else
Are we in the middle of transmitting? - If yes, send next bit.  Set TMR0
interrupt for baud
Else
  Does the receive pin have a start bit on it? - If yes, set receiving flag.
Set TMR0 interrupt for
baud
  Else
     Is the TxDataAvail flag set?  If yes, send start bit.  Set TMR0 interrupt
for baud.

After we finish sending or receiving, we set TMR0 back to baud/2.

In my design, I am using one PIC (the master) to communicate with a PC using
Serial.  That allows me to
store "program sequences" in the EEPROM that I have on an I2C bus.  The PIC then
can be transitioned
into a "Run" mode with a command over the serial port.  At that point, it
interprets the tokens in the
EEPROM and sends commands to the "slave" PICs via I2C.  I have found that I2C
works very well for a
slave/master relationship.  However, if your slave ever needs to interrupt the
master, then you need to
use additional wires.  (If you used one of the PICs with hardware start and stop
bit detection, then
you could do a multi-master scheme.)

I prefer the I2C to have the two processors talk because then I don't have to
worry as much about one
of them being out of synch.  Also, I can slow the communications up and down.

Hope this helps!

Alan G. Smith
+---------------------------------------------------------
| Alan G. Smith
| @spam@agsKILLspamspampoboxes.com
| http://www.innovatus.com/ags

1997\08\19@080815 by ags

flavicon
face
> Have you concidered connection the chips by a one wire serial bus like
> the dallas buttons use.
> Its very easy to do in code and because only one chip clocks the data
> you dont get any suprises while you are doing other things.
> You could poll the outer chips in turn to see if they have any thing to
> say.
I actually think the 2 wire protocol is easier, because it isn't as timing
dependent.
And you have the same benefit/drawback where only the master can clock the data.

--Alan
+---------------------------------------------------------
| Alan G. Smith
| KILLspamagsKILLspamspampoboxes.com
| http://www.innovatus.com/ags

1997\08\19@134346 by unknown667

picon face
At 10:23 PM 8/18/97 -0400, Alan G. Smith wrote:
>         From what I can see, it is for the 16C71.
>I have used a modified version to work on different pins.  Since I
couldn't use
> the interrupt for the
>Receive I used the timer Interrupt (TMR0) to check for Receive Data.
>I actually implemented mine fully in the ISR where you simply set a flag when
> you have transmit data
>available and a flag is set when receive data is available.
>I had very little problems making the modifications and getting it to work.
>
>If you have any problems implementing it, let me know and I will see what
I can
> do to help.
>
>Good luck!

Why couldn't you use the interrupt to check for data received?  I've also
been having trouble with RS232/RS485 communications on a 16C74A.  It seems
to always send 0x0 when it's not specifically sending something else.

---
Unknown

1997\08\19@164729 by Bob Blick

flavicon
face
At 04:41 AM 8/19/97 -0800, you wrote:
>> 1) How few pins can I get away with?
>
>    For example:
>
>    Your Master PIC controls the Slave PIC's MCLR line.  The Master
>    normally keeps the Slave's MCLR line high (out of reset).  When
>    the Master wants to send a message, it pulls the Slave's MCLR
>    line low, then pulls it high for a short time before pulling it
>    low, then high again.
>
>    The "message" is the time between MCLR-low pulses.

OK, that's got me interested.. the SLAVE's second job out of reset is to
increment a register, so that next time it comes out of reset, the first
job it has is testing that same register for the message sent to it... So
far so good. What's the approved method of determining if it's a valid
message, or just random powerup garbage?

Cheers,

Bob

http://www.bobblick.com/

1997\08\19@170501 by Marc 'Nepomuk' Heuler

flavicon
face
Hi Matt (Matt Calder), in <RemoveMEPine.SUN.3.96.970818220149.7842A-100000TakeThisOuTspamtlaloc.stat.colostate.edu> on Aug 18 you wrote:

>         Perhaps some more detail would make an interesting thread. I have
> been trying various serial protocols to get two PICs (16C84) talking and
> am wondering what is the 'best' way. Some of the issues I faced, and I
> suppose anyone doing this must face are:
>
>         1) How few pins can I get away with?
>         2) How fast can I go?
>         3) What is the interrupt mechanism?

I'd go with one pin if you can share the oscillator of the PICs!  The code
of each PIC can then take the other one into account!

The sender of data should pull down the comm line for a short period of
time to indicate its wish to send.  When it releases the bus, the receiver
can ack after few commands for a very short time.  If the ack is too long
or is detected _right_after_ the sender released the bus, the receiver is
probably also trying to send something (collision detection).

If the ACK is ok, you can start sending the data.  Both PICs are in sync
(the share the same clock), so you can send _very_ fast.

1997\08\19@194952 by Aydin Yesildirek

flavicon
face
> >> 1) How few pins can I get away with?
> >
> >    For example:
> >
> >    Your Master PIC controls the Slave PIC's MCLR line.  The Master
> >    normally keeps the Slave's MCLR line high (out of reset).  When
> >    the Master wants to send a message, it pulls the Slave's MCLR
> >    line low, then pulls it high for a short time before pulling it
> >    low, then high again.
> >
> >    The "message" is the time between MCLR-low pulses.
>
> OK, that's got me interested.. the SLAVE's second job out of reset is to
> increment a register, so that next time it comes out of reset, the first
> job it has is testing that same register for the message sent to it... So
> far so good. What's the approved method of determining if it's a valid
> message, or just random powerup garbage?

This method sounds dangerously exciting. I guess, glitches and
power up garbage can be filtered by the value of timer.
That is data only valid if the timer is between N1 and N2.

Aydin

> Bob

1997\08\19@201106 by Andrew Warren

face
flavicon
face
I wrote:

> >    Your Master PIC controls the Slave PIC's MCLR line.  The Master
> >    normally keeps the Slave's MCLR line high (out of reset).  When
> >    the Master wants to send a message, it pulls the Slave's MCLR
> >    line low, then pulls it high for a short time before pulling it
> >    low, then high again.
> >
> >    The "message" is the time between MCLR-low pulses.

and Bob Blick <spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU> replied:

> OK, that's got me interested.. the SLAVE's second job out of reset
> is to increment a register, so that next time it comes out of
> reset, the first job it has is testing that same register for the
> message sent to it... So far so good. What's the approved method of
> determining if it's a valid message, or just random powerup
> garbage?

Bob:

You can do it just as you would with any other communications
protocol... Any of the following techniques, for example, will work:

   1.  Redundancy:  Send the message two or more times and
       require that the Slave see consecutive, identical messages
       before acting on them.

   2.  Parity:  Send your message, then follow it with a "parity"
       message that brings the total time-between-MCLR-low-pulses
       time to some constant value.

       For example, let's say that your Master only sends one of
       two possible messages:  One's a 100-millisecond pulse and
       the other's a 200-millisecond pulse.

       Send your message, then send another pulse whose length is
       equal to, say, 300 milliseconds minus the length of the
       "message" pulse.  The Slave doesn't accept the message
       unless it receives two consecutive pulses whose combined
       duration is 300 milliseconds.

   3.  Framing:  Send a unique-length "start of message" pulse, then
       your message pulse, then a unique-length "end of message"
       pulse. The Slave doesn't accept the message unless it sees
       the "start" and "end" pulses around it.

-Andy

=== Andrew Warren - TakeThisOuTfastfwdEraseMEspamspam_OUTix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: RemoveMElistservspamTakeThisOuTmitvma.mit.edu

1997\08\19@202821 by ags

flavicon
face
> Can you please help me by tagging a simple RS232 from p.c. to PIC program.??
For anyone who needs SIMPLE Asynchronous Serial I/O look at App Note 510.
Especially at Figure 3 and Figure 4 which have the code snippets that you need.

If you have problems getting this to work, let me know.

Best of luck!

Alan G. Smith
+---------------------------------------------------------
| Alan G. Smith
| agsEraseMEspam.....poboxes.com
| http://www.innovatus.com/ags

1997\08\20@004657 by tjaart

flavicon
face
Bob Blick wrote:
>
> At 04:41 AM 8/19/97 -0800, you wrote:
> >> 1) How few pins can I get away with?
> >
> >    For example:
> >
> >    Your Master PIC controls the Slave PIC's MCLR line.  The Master
> >    normally keeps the Slave's MCLR line high (out of reset).  When
> >    the Master wants to send a message, it pulls the Slave's MCLR
> >    line low, then pulls it high for a short time before pulling it
> >    low, then high again.
> >
> >    The "message" is the time between MCLR-low pulses.
>
> OK, that's got me interested.. the SLAVE's second job out of reset is to
> increment a register, so that next time it comes out of reset, the first
> job it has is testing that same register for the message sent to it... So
> far so good. What's the approved method of determining if it's a valid
> message, or just random powerup garbage?

I'm interested too! How do you insure that the register does not get
corrupted? Do you save it in EEPROM?

--
Friendly Regards

Tjaart van der Walt
EraseMEtjaartspamwasp.co.za
________________________________________________________
|        WASP International   http://wasp.co.za          |
|   R&D Engineer : GSM peripheral services development   |
|Vehicle tracking | Telemetry systems | GSM data transfer|
|Voice : +27-(0)11-622-8686  |  Fax : +27-(0)11-622-8973 |
|             WGS-84 : 26010.52'S 28006.19'E             |
|________________________________________________________|

1997\08\20@011451 by Andrew Warren

face
flavicon
face
Tjaart van der Walt <RemoveMEtjaartEraseMEspamEraseMEwasp.co.za> wrote:

> How do you insure that the register [used for measuring the time
> between MCLR-low pulses] does not get corrupted? Do you save it in
> EEPROM?

Tjaart:

No, you just store it in RAM; a reset won't corrupt the
general-purpose registers.

-Andy

=== Andrew Warren - RemoveMEfastfwdspam_OUTspamKILLspamix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: RemoveMElistservTakeThisOuTspamspammitvma.mit.edu

1997\08\20@013348 by Andrew Warren

face
flavicon
face
Marc 'Nepomuk' Heuler <EraseMEPICLISTspamspamspamBeGoneMITVMA.MIT.EDU> wrote:

> I'd go with one pin if you can share the oscillator of the PICs!
> The code of each PIC can then take the other one into account!
>
> ....
>
> Both PICs are in sync (the share the same clock), so you can send
> _very_ fast.

Marc:

Actually, sharing the oscillator doesn't buy you any speed; you can
go just as fast with separate clocks as you can with a single clock.

-Andy

=== Andrew Warren - RemoveMEfastfwdKILLspamspamix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: listservSTOPspamspamspam_OUTmitvma.mit.edu

1997\08\20@072315 by mikesmith_oz

flavicon
face
On 16 Sep 97 at 9:46, unknown667 wrote:
     ^^^^^^^^
Hey, Unknown667, can you adjust your clock to reality?  My mailer is
too stupid to compensate for this time warp.  Alternatively, could
you check the Australian papers for this weekend's (23rd August 97,
if its still available) OZ-Lotto numbers.  - and post them here I
wouldn't mind sharing the 16million with the other oz members of
piclist... <g>
MikeS
<spamBeGonemikesmith_ozSTOPspamspamEraseMErelaymail.net>

=== For PICLIST help (including "unsubscribe" instructions),
=== send an e-mail containing the single phrase "help piclist"
=== to: KILLspamlistservspamBeGonespammitvma.mit.edu

1997\08\20@101917 by John Payson

flavicon
face
> Actually, sharing the oscillator doesn't buy you any speed; you can
> go just as fast with separate clocks as you can with a single clock.

Sure it buys you speed.  Once you've gotten the two PICs synchronized,
they can exchange unlimitted amounts of data, bidirectionally, at a rate
of 1 byte per 17 clocks (if the ports are located favorably).  By
contrast, if you use non-synchronized clocks you couldn't do better than 3
clocks/bit, and even then you'd have to resync yourself at most every 30
bits or so.

1997\08\20@123410 by Andrew Warren

face
flavicon
face
I wrote:

> > Actually, sharing the oscillator doesn't buy you any speed; you
> > can go just as fast with separate clocks as you can with a single
> > clock.

and John Payson <EraseMEPICLISTspamEraseMEMITVMA.MIT.EDU> replied:

> Sure it buys you speed.  Once you've gotten the two PICs
> synchronized, they can exchange unlimitted amounts of data,
> bidirectionally, at a rate of 1 byte per 17 clocks (if the ports are
> located favorably).  By contrast, if you use non-synchronized clocks
> you couldn't do better than 3 clocks/bit, and even then you'd have
> to resync yourself at most every 30 bits or so.

John:

You can synchronize two PICs to within one instruction-clock cycle of
each other WHETHER OR NOT they share an oscillator.

While a shared oscillator obviates the need for resynchronization, a
two-oscillator system can also do without (frequent) resyncs so long
as the two oscillators are closely matched in frequency.

I assume that your "17-cycle" code (I count 18 cycles, but
that includes the load/store) looks something like this:

   BSF     STATUS,RP0   ;Setup to send data.
   CLRF    TRISB^080H   ;

   ....

   MOVWF   PORTB        ;Send a byte.
   RLF     PORTB        ;
   RLF     PORTB        ;
   RLF     PORTB        ;
   RLF     PORTB        ;
   RLF     PORTB        ;
   RLF     PORTB        ;
   RLF     PORTB        ;
   RLF     PORTB        ;

   BSF     TRISB^080H,7 ;Prepare to receive a byte.

   RRF     PORTB        ;Receive a byte and store it in W.
   RRF     PORTB        ;
   RRF     PORTB        ;
   RRF     PORTB        ;
   RRF     PORTB        ;
   RRF     PORTB        ;
   RRF     PORTB        ;
   RRF     PORTB,W      ;

Is that correct?  If so, there's a faster way:  Since the "favorable"
arrangement of the ports requires that the PORTB0-6 pins be unused
outputs (or outputs that are tied to devices that don't care whether
they're madly toggled whenever you receive a byte, and how common is
THAT?), you might as well dedicate the ENTIRE port to data transfer.

If you do that, your "transfer a byte in each direction" code
becomes:

   BSF     STATUS,RP0   ;Setup to send data.
   CLRF    TRISB^080H   ;

   ....

   MOVWF   PORTB        ;Send a byte.
   COMF    TRISB^080H   ;Setup to receive data.
   MOVF    PORTB,W      ;Receive a byte.

-Andy

=== Andrew Warren - @spam@fastfwd@spam@spamspam_OUTix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: spamBeGonelistservspamKILLspammitvma.mit.edu

1997\08\20@153457 by John Payson

picon face
> I assume that your "17-cycle" code (I count 18 cycles, but
> that includes the load/store) looks something like this:

Nope.  Like this [assuming RB0 is output on each device, RB7 is 'the'
input, and RB's 1-6 are either unused or are inputs:

       rlf     Data0,w ; Get C flag
       rlf     PORTB
       rlf     Data0
       rlf     PORTB
       rlf     Data0
       rlf     PORTB
       rlf     Data0
       rlf     PORTB
       rlf     Data0
       rlf     PORTB
       rlf     Data0
       rlf     PORTB
       rlf     Data0
       rlf     PORTB
       rlf     Data0
       rlf     PORTB
       rlf     Data0
; Then 17 cycles for Data1, then 17 for Data2, etc.

1997\08\21@041826 by Andrew Warren

face
flavicon
face
John Payson <.....PICLISTspam_OUTspamMITVMA.MIT.EDU> wrote:

{Quote hidden}

   Ah... I see, John.  I misread your message and thought that you
   were saying that you could transfer TWO bytes (one in each
   direction) in 17 cycles.

   Sharing the clock still doesn't give any speed advantage, though.

   -Andy

=== Andrew Warren - TakeThisOuTfastfwd.....spamTakeThisOuTix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: TakeThisOuTlistservKILLspamspamspammitvma.mit.edu

1997\08\22@211740 by Marc 'Nepomuk' Heuler

flavicon
face
Hi Andrew (Andrew Warren), in <.....199708200449.XAA08360spamRemoveMEdfw-ix7.ix.netcom.com> on
Aug 19 you wrote:

> Actually, sharing the oscillator doesn't buy you any speed; you can
> go just as fast with separate clocks as you can with a single clock.

You need start/stop bits then, or a dedicated clock line.  We're talking
about a 1 wire transmission.

1997\08\22@223150 by Andrew Warren

face
flavicon
face
I wrote:

> > Actually, sharing the oscillator doesn't buy you any speed; you can
> > go just as fast with separate clocks as you can with a single clock.

and Marc 'Nepomuk' Heuler <RemoveMEPICLISTspamspamBeGoneMITVMA.MIT.EDU> replied:

> You need start/stop bits then, or a dedicated clock line.

   No, you don't.

> We're talking about a 1 wire transmission.

   Correct.

   -Andy

=== Andrew Warren - spamBeGonefastfwd@spam@spamspam_OUTix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: TakeThisOuTlistservspamspammitvma.mit.edu

1997\08\25@131414 by Marc 'Nepomuk' Heuler

flavicon
face
Hi Andrew (Andrew Warren), in <199708230231.VAA13831EraseMEspamdfw-ix15.ix.netcom.com> on
Aug 22 you wrote:

> > > Actually, sharing the oscillator doesn't buy you any speed; you can
> > > go just as fast with separate clocks as you can with a single clock.
>
> and Marc 'Nepomuk' Heuler <RemoveMEPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU> replied:
>
> > You need start/stop bits then, or a dedicated clock line.
>
>     No, you don't.

How do you want to keep them in sync?  The pic speeds may drift.

I think about something similar to this:

       XMIT PIC                        REC PIC

       bcf     XPORT,XBIT
       rlf     BUFFER,f
       btfsc   STATUS,C
       bsf     XPORT,XBIT              bcf     STATUS,C

       bcf     XPORT,XBIT              btfsc   RPORT,RBIT
       rlf     BUFFER,f                bsf     STATUS,C
       btfsc   STATUS,C                rlf     BUFFER,f        ; buffer init is
0x00, so C is clear again
       bsf     XPORT,XBIT              nop

       bcf     XPORT,XBIT              btfsc   RPORT,RBIT
       rlf     BUFFER,f                bsf     STATUS,C
       btfsc   STATUS,C                rlf     BUFFER,f
       bsf     XPORT,XBIT              nop

       bcf     XPORT,XBIT              btfsc   RPORT,RBIT
       rlf     BUFFER,f                bsf     STATUS,C
       btfsc   STATUS,C                rlf     BUFFER,f
       bsf     XPORT,XBIT              nop

       ...

Sure you can save some cycles if you don't want the ports to stay all-purpose.

1997\08\27@065343 by fastfwd

face
flavicon
face
I wrote:

> No, you don't [need start/stop bits to do very fast (one bit per
> instruction cycle) one-wire data transmission between two PICs,
> each of which is running on its own oscillator].

and Marc 'Nepomuk' Heuler <@spam@PICLISTRemoveMEspamEraseMEMITVMA.MIT.EDU> replied:

> How do you want to keep them in sync?  The pic speeds may drift.

Marc:

To be fair, the "drift" issue doesn't have anything to do with the
fact that each PIC has its own oscillator; if both oscillators are
highly accurate, drift isn't (much of) a problem.

Just for the sake of argument, though, let's assume that the two
oscillators DO drift, so one PIC can gain or lose a cycle relative to
the other.  Is that any different from the situation in which both
PICs share a SINGLE oscillator?

I don't think so... Here's why:  If you have two PICs with a single
shared oscillator, you can synchronize them to within one INSTRUCTION
cycle, but you can't sync them to within one OSCILLATOR cycle.  Since
one PIC could be starting its "write" quarter-cycle just as the
other's starting its "read" quarter-cycle, a tiny bit of jitter can
cause the two PICs to lose synchronization EVEN THOUGH they share an
oscillator.

-Andy

=== Andrew Warren - EraseMEfastfwdspam@spam@ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to: @spam@listservspam_OUTspam.....mitvma.mit.edu

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