How to make the PST faster than 115,200 bps?

2»

Comments

  • edited April 2012 Posts: 0Vote Up0Vote Down
    turbosupra wrote: »
    I tested your program and saw as you stated, am I correct about the reason when it looped inside of a spin loop it would only update at 53000bps?
    Yes, the overhead of calling the Spin tx method one byte at a time will limit you to less than 125000bps. If you do anything else in the loop is slows it down even more, so 53000bps is a typical rate.

    I want to make it clear that in my test program I am only transmitting and not receiving anything. If I would have received a keystroke during the test it would have messed up the serial output since FDS is not capable of full-duplex 1mbps. Peter's driver would be a good choice for high-rate full-duplex operation, or using a single port in the 4-port serial object would work also.
  • pjvpjv
    edited April 2012 Posts: 0Vote Up0Vote Down
    Hi TurboSupra;

    Sorry to hi-jack your thread here, but there are some serious issues or misconceptions that I would like to expound on for a bit. It all relates to higher speed serial communications, and the tests that Dave Hein has run.

    Dave, please understand that my comments here are totally intended to be in good faith, and no ill will is intended, but my belief is that the test results you are basing your statemants on are seriously flawed.

    Firstly, baud rate and throughput are two different things. one cannot calculate the baud rate by dividing the total number of bits sent, by the time it takes the send them. That does not allow for any possible inter-character time. Baud rate is simply the inverse of the shortest signalling time element.

    Secondly the method of time measurement in your test is somehow incorrect. In running your "FOX" test at 115200 baud, (screen shots 003,004) it reports 69 characters in 927 usec. The blue oscilloscope cursor indicates that it takes 6.73 msec.; quite a difference.

    So obviously the (incorrect) "baud rate" calculation is also reported in error.

    Next I ran the test at 1,000,000 bits per second, and the scope (screens 005,006,007) could not reliably decode the data sent because some of the bits were quite a ways from the expected 1 usec duration. In fact, varying from typically 900 nanosec to 1100 nanosec (008..012), with the occasional 2000 nanosec thrown in. So, then setting the scope to capture for 800,000 baud, allowed me to at least catch some of the data stream.

    For clarity I added a bit-clock toggle (blue trace) to the assembler part of the code to output where the bit edges were expected to land.

    Then I changed the driver to the one I had modified for "improvement", and, it being based on the same original "FullDuplexSerial" object from long ago, was flawed with the same bit-width issues. As a result, though it is improved, as I stated in its release, it still is not really op to snuff for reliable fast comms... 460800 should generally be OK.

    It surprises me that people are actually using the FDS driver at high speed..... it simply does not work reliably over 460800, and even that is "iffy". I suspect that some may be getting away with it if they alo use that same driver for receiving the data. The receive routine uses the same timing mechanism, and perhaps the transmit and receive timing errors are aligned, and disappear. Not so when talking to a differt family of devices, such as evidenced by my oscilloscope captures.

    Again, please take these observations and comments in a positive view as I'm looking to add to the general forum knowledge base. So thanks for listening.

    Cheers,

    Peter (pjv)
    1024 x 768 - 36K
    1024 x 768 - 37K
    1024 x 768 - 35K
    1024 x 768 - 26K
    1024 x 768 - 25K
    1024 x 768 - 27K
    1024 x 768 - 28K
    1024 x 768 - 27K
    1024 x 768 - 28K
    1024 x 768 - 28K
  • edited April 2012 Posts: 0Vote Up0Vote Down
    I gave up on attempting to do high speed serial commas with FDS. After about 380400 bps,(IIRC) even with tweaked versions, it was not reliable. I changed hardware to the the FTDI 245, as I had the pins to spare. Wrote a binary compatible version of FDS for it, and never has an issue again. I use it to send DMX 512 data to the prop from a PC. I verify each frame sent to the prop. It is sent at 3Mbps. The code is in my sig.
    Feel the need for speed between your PC's com port and Prop?
    Try the FTDI 245 and the FullDuplexParallel Object.
  • edited April 2012 Posts: 0Vote Up0Vote Down
    Peter, thanks for your explanation. The "baud rate" value I compute in my test program was an attempt at expressing the data transfer rate in terms of a serial baud rate. It would be clearer if I just displayed the number of bytes divided by time. I used FDS because it is in the Spin library. I didn't have much time to spend on this code so I haven't tried your serial driver or the 4-port serial driver yet. I'll do that if I get a chance this weekend.
  • edited April 2012 Posts: 1,088Vote Up0Vote Down
    So is a better solution to take hub ram addresses and pass them to a PASM loop that reads those addresses and writes the serial bits?
  • pjvpjv
    edited April 2012 Posts: 0Vote Up0Vote Down
    Hi Dave;

    I fully understand your intent, and I agree that a throughput number of bytes per second would be a measure of combined baud rate as well as effectiveness of the Spin program that feeds the assemby byte driver.

    As for my "improved" version, it still has problems at high speed because it is based on the standard FDS code that was created years ago. What I should do, is spend some time to re-write that completely.... it is quite likely that the offending pieces that cause the variance in bit timing can be rectified..

    Cheers,

    Peter (pjv)
  • edited April 2012 Posts: 0Vote Up0Vote Down
    You mean buffer the data and send it when ready... Yes. IIRC, same advice given on one of your similar posts.
    Any fool can make something complicated. It takes a genius to make it simple. Woody Guthrie
Sign In or Register to comment.