Data transmission protocol with two lines and no explicit clock

Question

Are there communication protocols that transmit bits using two lines A and B as follows:

• When line A is toggled, a 0 is sent.
• When line B is toggled, a 1 is sent.

I currently use this to push out debugging info from my µC projects, because is requires only one toggle per bit.

I wonder if that scheme is used for real communication protocols and if there is hardware with support for it (like SPI and I2C).

I've made diagrams to clarify the toggle thing. Here's how I transmit the sequence of bits '10100011':

source on WaveDrom

And here's what eight zeros look like on the wire:

source on WaveDrom

Answer 1

It's impossible to say "this isn't used", because, somewhere, someone else might do the same as you. But it's possible to say that this is very unlikely to be used in a properly designed system.

The reason is simply that

• with two lines you can do SPI, which is really just "how to shift data into a shift register", and solves the "how do I receive this" problem very elegantly. Basically every microcontroller can do that, it can be daisy-chained, it's easy to receive in hardware, and still easier to receive than your system even if you're doing it in software…
• for relatively slow data transfer (< 10 Mbit/s for short distances), UART works fine with only one line per direction, and basically every microcontroller in existence has it built in, so you can do with less programming/CPU effort, and less cabling, simply by transmitting a UART-style signal, even bitbanged
• For higher speed data transfer, your system is a bit inelegant – you now would have two signal lines that you need to design for the same high frequency (if you send a lot of 0, A toggles at full bit rate), instead of one.

So, your

because is requires only one toggle per bit.

isn't that much of an advantage:

• still uses the same CPU cycles to decide whether to toggle (compare that with unconditionally writing the bit to an output pin whilst unconditionally toggling the clock pin – that's less work! And if you're using an SPI peripheral, you don't even have to do any of that yourself, you just copy the data to some register, and the hardware takes care of the rest.)
• compared to UART, it doesn't reduce bandwidth you need to account for; compared to standard SPI, it indeed has half the transitions, but for the sake of argument, you could also build a double-edge-sampling "DDR SPI" (in fact, that does exist)
• with a clock that just toggles (not: rises) at every bit period, you could build a standard interface (SPI) with the same number of lines and microcontroller pins

Answer 2

A close match is the Wiegand protocol used in card terminals.

_{(Image from Understanding Wiegand, Farpointe Data, Inc., 2018)}

Originally Wiegand protocol was used with magnetic stripe readers, transmitting pulses at the speed at which the card was moved. The self-timing feature of the two signal lines was necessary to account for varying speed of card movement, and it also made the reader hardware simple.

Many later card readers have retained Wiegand support for backwards compatibility, even though they have internal microcontrollers now.

It differs from your protocol in that Wiegand protocol uses pulses instead of toggling to signal the bits.

Answer 3

Some answers and comments pointed out that you may "as well" use SPI. It sure is a valid point of view. But let's appreciate that it's quite easy to convert between SPI and "edge pair" using just two commonplace logic chips, in either direction.

I present it using CD4000-series, although most anything else will work just as well - TTL, 74HC, 74LV, etc.

From SPI to "edge pair":

^{simulate this circuit – Schematic created using CircuitLab}

It takes two chips, for example a CD4070 quad-XOR, and a CD4013 double D-FF. XOR1 and XOR2 convert the D-FFs into T-FFs, although with ~Q output available on the D-FF, they are not really needed: just feed ~Q to D. XOR3 inverts the serial data. XOR4 delays the clock to ensure REG2's hold times are met even if it's slow - like CD4000-series-slow at 3V.

This will work with any faster logic family as well, I'm just showing how the slow CD4000 would cope with it at 3V.

From "edge pair" to SPI:

^{simulate this circuit}

Two chips again, CD4070 recommended as it is slow enough to generate reasonable pulse lengths from 3V..5V supply. Faster logic families will work, but the pulses they generate will be the equivalent of SCLK in tens of MHz, and not all MCUs can accept that.

Answer 4

I don't remember seeing a real communication protocol which uses transitions on two lines to encode either a 0 or 1 without an explicit clock. However, Manchester encoding encodes the clock into the datastream, on a single line.

The ARM Serial Wire Output (SWO) Physical pin protocol can use two types of encoding:

• Manchester encoding
• UART encoding

The above ARM documentation page shows an example of Manchester encoding.

The question doesn't mention which family of microprocessor are in use, but the ARM Serial Wire Output is designed to output debugging and trace output. The SWO programmers model describes the visible registers which the running program can use to output debug information.

The Texas Instruments SWO Trace is an example of how SWO may be used in the Texas Instruments Arm Cortex-M processors and debug tools. As well as message logging where the running program formats messages for output, the debug tools can use SWO for the following which don't require modification of the program being debugged:

• Statistical Function Profile
• Exception Profile
• Variable Profile

As for hardware implementation of Manchester encoding on other microprocessors, found the Silicon Labs AN921: Configurable Logic Unit which describes using Configurable Logic Units (CLUs) inside the microcontroller to implement a Manchester encoder/decoder.

This answer doesn't answer the direct question, but shows that ARM Cortex-M is an example of a microcontroller family with built-in support for allowing debugging / tracing information to be output which has support in existing debug tools.

In response to the following comment:

I knew there was a way to combine clock and data into a single signal, but couldn't remember the name. – Mark Ransom

I have also seen the term Biphase used. E.g. the following diagram from the Zilog Z16C30 USC User’s Manual:

Where the above user's manual uses Biphase-Level as an alternative name for Manchester encoding. It has the following description of how the Digital-Phase Locked Loop can recover a Receive clock from the Receive data signal:

This can be done only when the received data stream includes enough transitions to keep the recovered clock synchronized to the data. NRZI-Space encoding of HDLC/SDLC frames, or Biphase (FM) encoding with any protocol, guarantees such data transition.

Answer 5

Yes, there is! The XMOS processors have a proprietary interconnect called xConnect in which one type of serial link is like the protocol you described. You can seet it in section 4.2, page 11 in this document: https://www.xmos.com/download/xCONNECT-Architecture(1.0).pdf

4.2 The serial XMOS link The serial XMOS link uses two data wires in each direction labelled “0” and “1”. A transition on wire “0” represents a zero bit and a transition on wire “1” represents a one bit. It is the transition that signals the bit; the level of the wire is irrelevant. For each token 10 transitions are made. The first eight transitions encode the 8 bits of the token value, transmitted most significant bit first. The ninth transition signals whether this is a control or data token. A transition on “1” signals a control-token, a transition on “0” signals a data-token. The final transition causes both wires to go back to low state. The two signal wires are both at rest between tokens.

So yes, your protocol exists in silicon in some obscure-ish processor family.

Answer 6

Although not exactly the same, this protocol is very similar to a network protocol used for satellites called SpaceWire. The protocol has the "advantage" that only one transition occurs at one time, and there is no clock shared between the devices. Instead, the clock is recovered within the data and strobe signals by XORing them together. The real advantage is jitter/skew tolerance.

https://soc-e.com/spacewire/

https://www.star-dundee.com/spacewire/getting-started/an-overview-of-the-spacewire-standard/

Answer 7

I3C has “ternary symbol” transfer modes. Basically, they go one step further than your idea and distinguish between three symbols:

1. The first line, SDA, changes.
2. The second line, SCL, changes.
3. Both lines change at the same time.

The full standard is not public, but this presentation from MIPI DevCon 2016 has some information starting at slide 16.

One easy way to convert this idea into normal bits would be to consider pairs of two ternary symbols, which can have 9 different combinations, so you can encode (slightly more than) 3 bits worth of information into two of these symbols, of course assuming that the receiver manages to distinguish “simultaneous” and “non-simultaneous” signal changes.

Answer 8

For a short-haul, chip-to-chip interface it's certainly possible to roll your own protocol as you propose.

My take though is that for chip-to-chip short haul at modest speeds there are so many good choices (like I2C or even UART TTY) that can do the same thing.

For a long haul or high speed? What you propose has a weakness: it requires two channels instead of one. Biphase-mark (Manchester) doesn't require that, plus it has DC-free coding, which makes it useable over transformers and other types of AC coupling.

Moving up the food chain, there's 8b/10b as used for SATA and PCI Express.

That said, what you propose is a bit reminiscent of Firewire/IEEE 1394. Firewire uses two signals, and encodes bits with data/strobe encoding that toggles one wire or the other to send a 'change' or 'no-change' on the data. This encoding has a key benefit that Firewire can take a simple XOR of the two to recover the clock, no PLL needed.