Manchester encoding needs twice the bandwidth of serial (RS232) encoding. Apparently 802.3 Ethernet and hardisk data use Manchester Phase Encoding!
Transmitting Manchester is easy, just XOR the internal clock against your serial data.
Receiving looks for a transition between bits for a state toggle and there is always a transition mid bit to synchronise the clock.
I have nor coded anything before but it seems like you would use edge interrupts and a timer.

Have you thought about self clocking signals such as Manchester encoding. 

Wow, I just looked that up.  That is really cool.  I have never seen this before, so my question is: why doesn't everyone use it? Now: how to put it into arduino!   Also, I was thinking of making an arduino/Rpi network to send data around without the internet.  Manchester encoding would be great for the wired signals.

The occasional error may be due to the timer update interrupt (i.e. millis()). You may need to think about how you will deal with that particularly as you increase the speed. This interrupt takes about 20 us (from my failing memory). Perhaps use a parity bit or bits to detect errors and resend if bad. Perhaps preempt the interrupt and go silent. Perhaps synchronise interrupts (now this is getting far out there!).

Perhaps a bit more of an explanation of the benefits of your scheme is in order as I don't understand the why? The standard serial format should work fine in my mind.

You probably need to use the SPI hardware to get around the interrupt problem. Without a clock signal you will need to be more inventive. Perhaps an internal SPI receive clock could run at 3x the transmit clock. Then after reception you decode the mess back to something sane?

AlanX

Thank you very much! yes, perhaps I should disable interrupts or something.  The reason I set things up the way I did is because the protocol has to have exactly one output pin and exactly one input pin.  Otherwise I would have just used SPI.

Intriguing.  I implemented my own V.4 transceiver logic in Verilog to handle the 4-wire (TXD/TXC and RXD/RXC pairs) variation of this idea.  (It's not finished yet, though.)  The goal is the same: multi-megabit speeds over an interface that is backwards compatible with 2-wire RS-232.  I'll need to study this project and see if I can learn new tricks from it!  Thanks for sharing it!

I would also like to learn more about your protocol.  Mine MUST be 2 pins.  And one output, one input, so very constrained.  No clock pin can be used!  Anyways, I would appreciate anyone's ideas or thoughts.

Oh, I don't really have a protocol per se.  It's literally RS-232 (more precisely, ITU V.4) with exposed clock pins (old-school synchronous serial, before all these new-fangled formats came into existence).  The TXD pin changes on the rising edge of the TXC signal (both outputs).  The receiver is designed to asynchronously clock bits on RXD *or* slightly after the rising edge of RXC.  This way, I can drive slower peripherals using plain-vanilla 115200bps serial or slower with two wires, and drive megabit/second workloads using all four (where the clocks are used to enforce synchronization).

I *originally* wanted to use Spacewire (which used data/strobe signalling allowing the receiver to recover clock with just a single XOR gate), and may yet switch to it later on, but it turns out the hardware description is too complex for my individual brain to fully encompass.  For now, I'm just trying to build the simplest possible system.

My serial transmitter and receiver circuits can also be used to implement SPI as well, although only in certain modes.  External logic would be needed to get all four SPI clocking modes.

No, not self-clocking. But probably not hard to implement.

So this is basically like a half duplex SPI multi master but with the added twist of shared MOSI/MISO?

Yes, the SCK is the output of whichever chip is receiving, and the MOSI/MISO would be the input of that chip. When information goes the other way the roles of the pins flip.

Hmmmm this reminds me of a protocol I had been thinking about, 10 or 15 years ago, but with 2 pins on each side... using a similar principle but full duplex :-)

If this works, I'll love to use your system because it has interesting properties that I think are lacking in I2C.

Yes, I want to basically make a clocked UART that's faster for my #Open Source Graphics Card.  It seems that my entire hackaday revolves around that project! Anyways, the speed is causing tons of unacceptable errors. But other than that, its working great so far.

if I'm not mistaken the system is self-clocking and adjusts its speed on the fly, which is a desirable feature :-)

OK I am mistaken :-D

But it's really cool !