Matt Calder <PICLIST@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 - fastfwd@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: listserv@mitvma.mit.edu