Fast Full Duplex Serial to 921600
pjv
Posts: 1,903
Hi All;
Since there seemed to be some interest in high speed comms, I have modified the standard FDX Serial in the OBEX to speed it up a bit. In the assembler portion, there were some redundant calculations in a tight transmit test loop that have been streamlined a bit. I believe it now should (just barely) copy streaming at 921,600, but it might still be a bit of a stretch. Half that speed, 460,800 should be cool.
The Spin portion has not been touched.... I would not know what to do with that anyway!
Now, since I don't know Spin, I am unable to test it, so If you are willing to test the attached modified "beta level" code on a no-guarantees basis, and provide some feedbak on its operation, especially at higher speeds, I would appreciate it.
If any repairs are required, I will do that, and then once everything is good, post it in the OBEX.
I hope I have not made any silly mistakes.
Cheers,
Peter (pjv)
Since there seemed to be some interest in high speed comms, I have modified the standard FDX Serial in the OBEX to speed it up a bit. In the assembler portion, there were some redundant calculations in a tight transmit test loop that have been streamlined a bit. I believe it now should (just barely) copy streaming at 921,600, but it might still be a bit of a stretch. Half that speed, 460,800 should be cool.
The Spin portion has not been touched.... I would not know what to do with that anyway!
Now, since I don't know Spin, I am unable to test it, so If you are willing to test the attached modified "beta level" code on a no-guarantees basis, and provide some feedbak on its operation, especially at higher speeds, I would appreciate it.
If any repairs are required, I will do that, and then once everything is good, post it in the OBEX.
I hope I have not made any silly mistakes.
Cheers,
Peter (pjv)
Comments
I was wondering if the rx and tx buffers could be increased to possibly 256?
Thank You
Probably, but it may have an impact on the Spin portion, and that I have no expertise in. It should be trivial for the assembly portion, but can't look at that until tomorrow.
Cheers,
Peter (pjv)
Late at night here now, just got back from a party,.... lots of wine (Australian Shiraz, I love it), so thinking may be a little off.......
Do I then understand that your version would be the preferred iteration to put it in?
If so, would you take care of that, because I don't know how to do it??
I would think that the code needs to be vetted first, and I have no idea if anyone has tried it, even at ANY speed.
See you all tomorrow..... I mean later today!
Cheers,
Peter (pjv)
Does anyone have anything else required in the FDX code? I would like to see fdx.out added in spin (same as fdx.tx) so that a TV.out could be substituted.
Good of you to offer this.
Since no one has tried this code, perhaps I can figure out a simple Spin op to test it. I can manage all the high speed suff OK, and I can program up an SX to generate a contiuous stream (stream = ultimate test) for it to receive. Then temporarily adding an XOR outa,#x instruction here and there will give some outputs for the scope to track on.
Hey, I don't need Spin at all ...... I can just run the assembler portion because that is where the problem was!. DUH !!
By the way, I'm curious by what method are you connected to the Internet while bobbing on the water, presumably far from land?
Cheers,
Peter (pjv)
I have now tested the assembly portion for speed, and can confirm:
The original FDX assemby ran at best -no data, just searching for a start bit- at 900 nanoseconds for an Rx/Tx ping-pong.
The minor mods I made now have it running at 500 nano seconds for a ping-pong.
So now it should be able to find that start bit whenever it comes. I have not actually set up an SX to pump it yet, so don't know what the Spin part does when an actual character is received. The 16 byte buffer will fill in 16-ish uSec, and that is probably a stretch for Spin.
Hopefully someone out there can actually test this.
Cheers,
Peter (pjv)