close-circle
Close
0%
0%

2-pin SuperSerial

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

Similar projects worth following
close
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.

    SERIAL INITIALIZATION

    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

    SERIAL TRANSMISSION

    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?

Share

Discussions

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