You didn't indicate what speed you needed.

I have had good luck with Manchester coding. It is almost completely
insensitive to timing
differences, so I use it between RC-timed PICs or RC-timed PICs and
crystal-controlled PICs.

Normally I have an OUT and an IN channel seperately, so two pins are
needed. A MASTER sends a command, and the correct slave answers. But
max the speed is about 1K BPS.

--Bob

On Sun, Aug 17, 2008 at 4:52 PM, Forrest W Christian <forrestc@imach.com> wrote:
> I'm working on selecting a "expansion bus" for a PIC project I'm working
> on.   In short, the architecture is that I'll have a master controller
> which will need to poll several slave modules.
>
> Characteristics which are requirements are:
>
> 1) Cheap.
>
> 2) Two-way communication and messaging.   Think digital and analog I/O.
>
> 3) Implementable using PIC's on both the master and slave side.  A PIC
> implementation should not require any external logic to the PIC.
>
> 4) Daisy-chainable architecture.   This means either bus or in/out
> architectures are acceptable.   Star architectures are not.   Note this
> kills SPI, since \CS is a problem in this regard.
>
> 5) Slaves should be able to be detected by the master, and should not
> have to have addresses set via dip-switches or other means.   Globally
> (factory set) unique addresses are ok (aka 1-wire style), dip-switches
> are not (aka i2c is not an option).
>
> 6) Very low pin count.   Lower the better.   Like 2-3 or fewer, not
> counting Vss.
>
> Some additional preferred characteristics:
>
> 1) Bit-bangable is preferred.   Bit-bangable without lots of nasty
> timing issues is even better.  In fact, I almost added bit-bangable to
> the requirements, since it is pretty common for me to have both the MSSP
> and the EUSART tied up - although if I had to choose required hardware
> I'd say the EUSART would be less likely to be used.
>
> 2) Easily implementable or libraries are available for C18.
>
> I keep coming back to 1-wire, but I really don't like the looks of how
> big of a pain it is to implement and some of the nasty timing requirements.
>
> I have also been thinking about a multidrop or "ring" async.   That is,
> either connecting the tx of one unit to the rx of the next one and so on
> back to the start - or tying tx (through a fet and pullup resistor) and
> rx together on all of the units, and do it that way...  but I really
> don't like bit-banging serial data.
>
> In short, I haven't found the perfect solution yet...   Ideas?
>
> -forrest
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist