Dear Forrest W Christian, I've been playing with a few communication physical layers that seem similar to what you're looking for: * 5-wire daisy-chain SPI * 5-wire "completely asynchronous, speed independent" * 2-wire power + data (and optional gyrators) Is there a wiki somewhere that discusses developing new communication protocols? Should I publish my list of "22 common communication pitfalls"? == 5-wire daisy-chain SPI == I am currently using some chips that use "daisy-chain SPI" (is there a better name for this?). It sounds very similar to some of the ideas you suggested. I think JTAG also uses "daisy-chain SPI". The data tx of each unit is connected to the data rx of the next unit in a big ring, just as you suggested. Unlike the "independent-select SPI", the "daisy-chain SPI" does *not* require the master to generate an independent chip-select for each slave. No matter how many slaves there are, the master controls them with 3 output pins and 1 input pin. Also, each daisy-chain SPI slave has 3 input pins and 1 output pin. Such an interface also does *not* require any dip-switches or unique addresses -- every slave can be identical, and yet the master can still tell which slave generated which message and send each slave its own commands (by the hop distance along the daisy-chain). Assuming the slaves are close enough to the master that you only need a single conductor for each signal (rather than a twisted pair), each cable from one device to the next carries the global signals * +power * -power * clock * frame and the local signal * data bit. ... also, the "out" cable from the last slave on the chain is connected to the master, making a big ring. That's 5 out of the 6 pins available on the 6p6c cable. The timing requirements for daisy-chained SPI are pretty simple, making it fairly easy to bit-bang. (However, later I describe a different protocol that has no timing requirements at all). Also, if all the PICs are running at the same voltage (all at 5.0 V or all at 3.0 V), you can connect the PICs pin-to-pin without any other hardware. (But I would throw in at least a resistor between the 2 PICs, because all too often bugs in my software cause pins that should be inputs sensing a signal to instead be outputs fighting over the signal). It sounds like you more-or-less independently re-invented this idea, eliminating the "frame" signal by adding software complexity (now each slave needs a unique address), and eliminating the "clock" signal by adding stricter timing requirements. > Date: 17 Aug 2008 > From: Forrest W Christian ... > 1) Cheap. ... > 2) Two-way communication and messaging. ... > 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. ... > 5) Slaves should be able to be detected by the master ... > (factory set) unique addresses are ok (aka 1-wire style), dip-switches > are not ... > 6) Very low pin count. ... > 1) Bit-bangable is preferred. Bit-bangable without lots of nasty > timing issues is even better. ... > 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 > -- == 5-wire "completely asynchronous, speed independent" == SPI and IIC are easy to bit-bang on the master. But a SPI or IIC slave has some timing requirements that, at higher bitrates, can be a bit tricky to bit-bang. I *think* it is possible to design a protocol that has no timing requirements at all, even on the slaves. > Date: 17 Aug 2008 > From: John Coppens ... > Maybe combine spi and i2c? Have a dataline that runs around, ring-style, > but instead of clocking with a fixed (serial-style) clock, which the > peripherals could hold low to 'brake' the master. That sounds like a good idea. But how do you guarantee that the slave is fast enough to notice that the master has pulled the clock pin down, and quickly also drive the clock pin down before the master lets it back up? In order to relax the timing requirements even more (to make it even easier to bit-bang), I've been thinking about a protocol that is completely timing-independent. No matter how fast or slow 2 devices are, they can still communicate (at a rate limited by the slower device). Even if one of the devices is distracted halfway through a bit, and thinks about something else for a few seconds, the protocol can still resume as if nothing had happened. Something like this: Initially, all lines are floating high (open-collector pull-up). To transmit a "1" bit, the left device pulls down the "T1" line and lets the "T0" line continue to float high. Eventually, the right device realizes that a "1" is being transmitted, and pulls down the "T0" line in response. Eventually, the left device realizes the bit has been received, and lets the lines float high again (for faster speed, OK to drive the T1 line high). Eventually, the right device realizes that the "1" bit is no longer being transmitted, and lets the lines float high again. Transmitting a "0" bit is similar, except the left device pulls down the "T0" line first, the right device pulls down "T1", and then they relax. (This is similar to, but not quite the same as, the "dual-rail encoding" used in some "completely asynchronous, speed independent" CPUs). Assuming the slaves are close enough to the master that you only need a single conductor for each signal (rather than a twisted pair), each cable from one device to the next carries the global signals * +power * -power * frame and the local signals * T0 * T1 (If every slave has a unique serial number, you could dispense with the global frame signal). If all the PICs are running at the same voltage (all at 5.0 V or all at 3.0 V), you can connect the PICs pin-to-pin with only a pull-up resistor (I think I would one at each end of the cable). (But I would throw in at least a resistor between the 2 PICs, because all too often bugs in my software cause pins that should be inputs sensing a signal to instead be outputs fighting over the signal). > Date: 18 Aug 2008 > From: Forrest W Christian ... > These are devices which > are intended to be din-rail (or wall) mounted right next to each other > with a short, but pin-limited jumper cable between them. I'm also > providing power and ground via that jumper. I figure the jumper will > likely be a 6p6c or a 8p8c connector. Right now, I'm toying with the > idea of using power, ground, and data on a multidrop serial bus, and > assigning each device a globally-unique serial number at manufacture > time so that the probed order can be preserved from run to run. ... == 2-wire power + data (and optional gyrators) == > Date: 18 Aug 2008 > From: "Bob Axtell" ... > 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. ... What I like most about Manchester coding is that I don't have to manually set a baud rate. It also has zero DC component, allowing it to easily pass through coupling capacitors, which is convenient for another serial bus I've been thinking about: 2 wires in the cable. The 2 wires carry the data (in one direction). The 2 wires *also* carry the power. I'm still impressed that the telephone company engineers somehow manage to get full-duplex simultaneous 2-way communication *and* power over a single twisted pair. This requires a bit more external hardware (a handful of inductors and capacitors and resistors; also a analog comparator -- although some PICs have a built-in analog comparator) than the above schemes, so it's probably not appropriate for your application. So I'll say no more about it here (except to say that each inductor can optionally be replaced by single-transistor gyrator). Serial Peripheral Interface Bus : Daisy chain SPI configuration http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Daisy_chain_SPI_configuration two PIC port pins "fighting" each other http://massmind.org/techref/postbot.asp?by=time&id=piclist\1997\03\11\203507a&tgt=post&key=pins+fighting Single transistor gyrator for telephony applications http://www.epanorama.net/documents/telecom/gyrator.html -- David Cary http://carybros.com/ http://opencircuits.com/ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist