2-pin SuperSerial

One input, one output, 2 microcontrollers. How fast can I get things???

Similar projects worth following
I have my propeller graphics card using UART for communication. Can't I go faster???

Will add more here as I figure some stuff out.

So far I'm at about 92.8% accuracy. Need to get that up! will add better details when it isnt about time to get off my computer.

  • First day - working to a good degree.

    Dylan Brophy03/29/2017 at 00:28 0 comments

    I started coding the serial functions for my Arduino. I applied the concepts described in the previous project log - except I made the data latch on the rising edge except for the falling.

    At first I got varying lengths of garbage, but as I refined the functions exchanging data the garbage got to double the length as the word I was transmitting: "test". I found that by shifting the data once to the right fixed it and displayed the text with spaces - or 0xFF - in between. I figured out that the transmission did not close properly causing extra data to be transferred. Fixing this made everything work and all the data was always sent and received correctly!

    Oh, except for the fact that the data transfer stopped after a certain amount of data sent too quickly. I'm not yet sure if this is the transmitter or receiver, but that's the next step. Its probably some if block I did or didn't put where I should have... Well anyways after that I'll speed up the heck out of it and apply it to my #Open Source Graphics Card.

  • Theory of Operation - first idea

    Dylan Brophy03/28/2017 at 02:17 0 comments

    I have a basic idea of how this could work. since clocks make things faster, lets implement that.


    Pins set accordingly. Outputs set high. Serial port waits for a low on their inputs of a certain duration (will figure this out later). The input becomes the DATA_IN and the output becomes CLK_OUT


    Transmitting micro sends a low pulse on the output and waits for a clock signal from the receiver. the clock's rising edge updates the data output and the falling edge latches the data.

    This should work! I'll update the project after some code and testing.

View all 2 project logs

Enjoy this project?



agp.cooper wrote 12/11/2017 at 01:07 point

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.

  Are you sure? yes | no

agp.cooper wrote 12/09/2017 at 12:34 point

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

  Are you sure? yes | no

Dylan Brophy wrote 12/09/2017 at 17:22 point

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.

  Are you sure? yes | no

agp.cooper wrote 12/09/2017 at 01:21 point

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?


  Are you sure? yes | no

Dylan Brophy wrote 12/09/2017 at 02:54 point

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.

  Are you sure? yes | no

Samuel A. Falvo II wrote 04/29/2017 at 07:12 point

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!

  Are you sure? yes | no

Dylan Brophy wrote 04/29/2017 at 07:24 point

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.

  Are you sure? yes | no

Samuel A. Falvo II wrote 04/29/2017 at 16:46 point

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.

  Are you sure? yes | no

Dylan Brophy wrote 04/02/2017 at 03:40 point

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

  Are you sure? yes | no

matseng wrote 04/02/2017 at 03:02 point

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

  Are you sure? yes | no

Dylan Brophy wrote 04/02/2017 at 03:42 point

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.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/01/2017 at 18:52 point

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.

  Are you sure? yes | no

Dylan Brophy wrote 04/02/2017 at 01:17 point

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.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/02/2017 at 01:58 point

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

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/02/2017 at 04:01 point

OK I am mistaken :-D

But it's really cool !

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates