Shop OBEX P1 Docs P2 Docs Learn Events
What is the Fastest Serial Object? — Parallax Forums

What is the Fastest Serial Object?

blittledblittled Posts: 681
edited 2013-03-08 22:05 in Propeller 1
I'm looking at an application where I want Propeller to PC serial communication at 1MBaud. Can the FullDuplexSerial object handle this speed or is there a better serial object to use?

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2013-03-06 07:40
    I don't think FDS can handle 1MBaud. The four port serial driver in the ObEx can handle 750KBaud with a single port. That's probably the best you can do with a full duplex routine. You would need to separate out the receive and transmit functions into separate cogs for higher speeds. The receive side is the most difficult because it has to sample the input line about 4 times faster than that to look for the beginning of the start bit.
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2013-03-06 08:19
    Mike, I don't really believe the 4-port object can reach that speed, even when there is only one active thread going on. It is basically the same code as the original FDS, but it has to handle 4 threads instead of just one, and it also has to handle the possibility of flow control. It does improve a bit on the FDS program flow, by patching the code at startup rather than testing flags at run time, but it has to be slower due to the extra overhead. That applies to either Tim Moore's original version and to my own updates. I know it says 750kbaud in Tim's notes, but I've been meaning to test that to see what its actual limits are under different conditions of activity.

    Johathan (lonesock) has made a fast counter-based jitter-free FDS driver, FFDS1. 460.8 kB.

    Blittled, can you use half-duplex, or one of the clever non-standard schemes that have come up here on the forums?
  • blittledblittled Posts: 681
    edited 2013-03-06 08:36
    The project I am working on is OldBitCollector's OpenScope Project for the PropScope. Since Hanno's firmware communicated at 1MBaud I was looking into keeping the feature but it is not critical so I can go slower or possibly half-duplex. Thanks for the info.

    I just had a thought. Since the PropScope runs at 100MHZ could the 750Kbaud limit also be overclocked close to 1MBaud?
  • Mike GreenMike Green Posts: 23,101
    edited 2013-03-06 08:49
    I think Hanno uses a specially written serial driver for ViewPort and the PropScope. The 100MHz clock is probably meant to simplify timing with a 10ns system clock as much as it's to overclock the Prop to get better throughput.
  • John AbshierJohn Abshier Posts: 1,116
    edited 2013-03-06 09:17
    This object says it does 1MBaud half duplex

    http://obex.parallax.com/objects/512/

    John Abshier
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2013-03-06 10:04
    Tackyon Forth might go that fast and faster. You need to ask Peter J. how he does it.

    Apparently to get lightning fast serial out of the Propeller, he is using one cog as a TX and another as an RX. I think the TX is shared with the Forth stack machine while the RX just hussles to receive and buffer (I may have this backwards).

    Peak rates of TX and RX may be asymmetrical, but he claims that he can use a USB port at its top rate.. maybe 3Mbaud or wifi.

    https://docs.google.com/document/d/1r10E2bFLeASkogsAH3wz4q0tiYxNNU2gP-uCHlJU0eA/edit
  • pjvpjv Posts: 1,903
    edited 2013-03-06 21:11
    Hi All;

    Back sometime in 2010 I tested and posted assembler 5Mb/s serial Ascii transmitter engine as well as a (separate) receiver at the same speed. They were finely tuned to hit the sweet spot of the rdbyte/wrbyte hub instructions. It would run at that speed all day long, not just bursts.

    They would transfer data to/from hub at that rate, any size buffer you want. In assembler only though, so any spin issues you would have to deal with yourself.

    Nobody seemed interesed, and I just parked the project.

    Is anyone interested now?

    Cheers,

    Peter (pjv)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2013-03-06 21:51
    pjv wrote: »
    Hi All;

    Back sometime in 2010 I tested and posted assembler 5Mb/s serial Ascii transmitter engine as well as a (separate) receiver at the same speed. They were finely tuned to hit the sweet spot of the rdbyte/wrbyte hub instructions. It would run at that speed all day long, not just bursts.

    They would transfer data to/from hub at that rate, any size buffer you want. In assembler only though, so any spin issues you would have to deal with yourself.

    Nobody seemed interesed, and I just parked the project.

    Is anyone interested now?

    Cheers,

    Peter (pjv)

    You know you could have just included a link to that post or attached the file again :)

    BTW, my serial routines have only been tested (and used) at 3M baud because that's the top usable rate of the FT232R chip. The receive routine has it's own cog but also does preprocessing while the transmit is a simple and tight loop in the kernel cog. This arrangement works really well as the kernel can talk directly to the transmitter without buffering which also simplifies and speeds up the transmit process and allows the cog to return to the kernel quickly. Since receive can occur at any time and timing errors can occur at higher speeds if the receive routine is not precisely synchronized to the start bit, it then makes sense to dedicate a cog to this and use the WAITPNE instruction for the start bit.
  • pjvpjv Posts: 1,903
    edited 2013-03-07 06:33
    Hi Peter;

    Very good point..... just a little lazy I guess.

    I'm not very PC literate, and don't know my way around searching or linking forum posts very well, so my method here may not be the best, but here goes:

    I searched through my posts, and found the entry at Feb 19, 2010, and copied the "properties" of the page and pasted it here. http://forums.parallax.com/showthread.php/120125-5Mbit-sec-ASCII-streaming-from-to-Hub-RAM

    Don't know if that will link directly when I post this reply, but at least you have the address now.

    Cheers,

    Peter (pjv)

    EDIT... Hey that worked! Learn something new every day..... and I need to because I forget a bunch every day also !!
  • jmgjmg Posts: 15,173
    edited 2013-03-07 13:29
    Peter Jakacki wrote: »
    You know you could have just included a link to that post or attached the file again :)

    BTW, my serial routines have only been tested (and used) at 3M baud because that's the top usable rate of the FT232R chip. The receive routine has it's own cog but also does preprocessing while the transmit is a simple and tight loop in the kernel cog. This arrangement works really well as the kernel can talk directly to the transmitter without buffering which also simplifies and speeds up the transmit process and allows the cog to return to the kernel quickly. Since receive can occur at any time and timing errors can occur at higher speeds if the receive routine is not precisely synchronized to the start bit, it then makes sense to dedicate a cog to this and use the WAITPNE instruction for the start bit.

    Sounds good.
    Did you test 3MB on a FT232H/FT2232H as well ?
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2013-03-08 08:51
    Peter (pjv) provides a clear explaination of his test bench - a chain of three Propellers with the first transmiting, the second receiving and forwarding, and the third recieving. It appears all are operating successfully at 5mbaud. Very simple and impressive.

    Inserting a USB to serial device and another computer to provide the loopback brings all sorts of variables into play.

    If it works on a 5mbaud bench with its own i/o hardwired to other Propellers, it should work with the USB converter at 3mbaud or maybe a Wifi interface.

    I previously was annoyed by PropForth using an internal loopback to do serial i/o demos. It may be just as valid, but it might evade fully testing the i/o. And after all i/o is suppose to include a connect to external devices.

    Anyway, I guess if I used Peter (pjv)'s serial driver, I could create a version of Forth on a Propeller and claim it is faster than Tachyon Forth's serial. And faster than PropForth's too. Though I would have to admit that it would be very unfair as the work is Peter(pjv)s, and he is a master at getting more out of a microcontroller's timing than most of us could ever hope to be.

    In other words, if he claims 5mbaud, you can be sure he has verified it quite soundly. Just look at all the pins of i/o that are providing monitoring data to a scope.

    If CRC is eventually included, the driver would be exceedingly excellent. Confirmed packets as well as extreme speed.
  • ke4pjwke4pjw Posts: 1,155
    edited 2013-03-08 13:03
    If you have the spare pins, my Full Duplex Parallel object for the FT-245 should be able to transfer close to 10Mbps TX and RX without error. It is mostly compatible with the FDS object. I have tested it to 3Mbps using the standard VCP FTDI drivers. The D2XX Direct Drivers are needed for 10Mbps.

    http://obex.parallax.com/objects/644/
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2013-03-08 22:05
    Oh my, faster and faster... I fear disaster.... oh my......

    The reality is that I rarely need to go so fast, but it is interesting to learn optimization from the examples.

    These examples reveal the nuances that reading PDF files will never disclose. And Peter9pjv) loves to demonstrate extreme precision.

    Of course parallel immediately offers up faster rate.. roughly 8x, maybe more. And there is a FTDI USB to parallel pin. But the Propeller 1 pretty soon is hamstrung by too few remaining pins.
Sign In or Register to comment.