+ Reply to Thread
Page 1 of 2 12 LastLast
Results 1 to 20 of 38

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

  1. #1

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

    I've tried going beyond 115200 and not had success, has anyone done this besides viewport which I believe is around a gbps.

    Does something in the actual object need to be modified as well? I'd like to go up to 250000 or 460800, I need to compare a bunch of data all at once to chase down an issue I'm having.

  2. #2

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

    PST is based on the FullDuplexSerial driver for its serial I/O and this is not designed to run faster than 230KBps. ViewPort uses a specially designed serial driver to get the speeds it uses. FullDuplexSerial4Port in the ObEx can handle speeds up to 750KBps (see the documentation in the program) with a single serial port, so you might try that.

  3. #3

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

    If you're only doing output -- that is, you don't need to send keystrokes back in -- then you can use a half-duplex transmit-only driver. I've attached (an old) one that I have used for my own projects. As it only does one thing it can run quite fast.
    Attached Files Attached Files
    Jon McPhalen
    Burbank, CA

  4. #4

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

    Just be aware that anything above 57600 is too fast for spin programs. IE, the spin program cannot put the data in the buffer fast enough to make use of the higher speed (even if the strings are already in the hub...). So it's pointless to run it faster, unless you're writing your own assembly.

    For the computer side, try using a different terminal program.

  5. #5

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

    I am using PASM to write values and spin has it's own communication loop/cog where it calls the PASM object and reads the PASM values and prints it to screen. Do you think it'll go faster than 57600 this way?

    Is it still too slow, maybe I'll have to try and write a PASM com program?

    Quote Originally Posted by SRLM View Post
    Just be aware that anything above 57600 is too fast for spin programs. IE, the spin program cannot put the data in the buffer fast enough to make use of the higher speed (even if the strings are already in the hub...). So it's pointless to run it faster, unless you're writing your own assembly.

    For the computer side, try using a different terminal program.

  6. #6

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

    Sweet, thanks Jon!

    Quote Originally Posted by JonnyMac View Post
    If you're only doing output -- that is, you don't need to send keystrokes back in -- then you can use a half-duplex transmit-only driver. I've attached (an old) one that I have used for my own projects. As it only does one thing it can run quite fast.

  7. #7

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

    I believe I read a little on this, it uses 4 pins right? Am I still limited by the speed of spin with this object?

    Quote Originally Posted by Mike Green View Post
    PST is based on the FullDuplexSerial driver for its serial I/O and this is not designed to run faster than 230KBps. ViewPort uses a specially designed serial driver to get the speeds it uses. FullDuplexSerial4Port in the ObEx can handle speeds up to 750KBps (see the documentation in the program) with a single serial port, so you might try that.

  8. #8

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

    The PASM cog driver is plenty fast enough (at least in the 4 port object, which I use). It's just that the spin TX routine is too slow. It is this routine that puts the characters into the TX buffer that the PASM driver then reads, and it is this routine that limits the speed. If you have an assembly program to put data into the TX buffer then you don't need to worry about the limitations.

    In any case, FullDuplexSerialPlus and FullDuplexSerial4Port both use only two pins per serial coms: one TX pin and one RX pin. With the four port, you need a pair for each port. I don't know if ViewPort uses 4 pins, but I doubt it: the FTDI chip has only RX and TX.

  9. #9

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

    The main speed bottleneck is the Spin code, as SRLM said. There is quite a bit of overhead when calling the tx or rx routine. In a tight loop that calls the rx routine and writes into a byte buffer, the Spin code runs at about 125,000 bits/second on an 80 MHz processor. If you do anything else in the loop it will slow it down even more. In my YMODEM receive program I receive 1 KB packets, and store them in a buffer. The loop also does time-out detection, so this limits it to about 57,600. I'm able to run at 115,200 by using a 512-byte buffer in FDS. The buffer is just below full after receiving 1 KB of data at 115,200.

    I wrote an rxblock routine that is able to handle 2 mega-bits/second. It uses bytemove to move data from the FDS receive buffer to a data buffer. I plan on integrating this into my YMODEM code at some point. A similar technique could be used for transmit to speed that up also.

    Code:
    PUB rxblock(ptr, num) | num1, num2, rxhead
      rxhead := rx_head
      if rxhead => rx_tail
        num1 := rxhead - rx_tail
        num2 := 0
      else
        num1 := 128 - rx_tail
        num2 := rxhead
      if num1 > num
        num1 := num
        num2 := 0
      elseif num1 + num2 > num
        num2 := num - num1
      bytemove(ptr, rx_buffer + rx_tail, num1)
      bytemove(ptr + num1, rx_buffer, num2)
      result := num1 + num2
      rx_tail := (rx_tail + result) & 127
    EDIT: This routine handles a buffer size of 128. Other sizes can be handled by changing the values of 128 and 127 to the buffer size and the mask. The buffer size must be a power of 2. The return value indicates the number of bytes read, which is between 0 and num.

  10. #10

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

    Quote Originally Posted by SRLM View Post
    Just be aware that anything above 57600 is too fast for spin programs. IE, the spin program cannot put the data in the buffer fast enough to make use of the higher speed (even if the strings are already in the hub...). So it's pointless to run it faster, unless you're writing your own assembly.

    For the computer side, try using a different terminal program.
    I just timed a program at two different bauds.

    At 57600 baud the loop to display the PlayStation 2 controller information (after removing any waitcnt statements) took 47.8 million clock cycles. At 115200 baud the same loop only took 2.99 million clock cycles.

    I think 57600 is still below the maximum useful baud rate for the Prop (using Spin).

    Edit: I think 115200 is approaching the limit for Spin. I changed the baud to 230400 and the loop time changed to 2.89 million cycles. Not much better than the time at 115200. The loop time didn't change when I increased the baud to 250,000.

  11. #11

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

    Duane, How many bytes did you print out? I'm guessing it was around 400 bytes, correct?

  12. #12

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

    Quote Originally Posted by Dave Hein View Post
    Duane, How many bytes did you print out? I'm guessing it was around 400 bytes, correct?
    Actually, much of the screen isn't printed each loop.

    I counted 285 characters displayed each loop.

  13. #13

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

    Turbosupra;

    Some while ago I made some improvements to the Full Duplex Serial driver to speed it up a bit. The following thread speaks about it.

    http://forums.parallax.com/showthrea...rial-to-921600

    Somewhere in this forum I have also posted a 5 Megabit/sec assembly based full duplex driver, taking data from/to a hub buffer of any desired size. Would take some digging to find it I suppose. Be happy to do that if it is of interest to you.

    Cheers,

    Peter (pjv)

  14. #14

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

    Quote Originally Posted by Duane Degn View Post
    I counted 285 characters displayed each loop.
    That works out to about 80,000 bits/second, which is consistent with the other numbers we've seen.

  15. #15

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

    Thank you, this should make for good reading tomorrow!



    Quote Originally Posted by pjv View Post
    Turbosupra;

    Some while ago I made some improvements to the Full Duplex Serial driver to speed it up a bit. The following thread speaks about it.

    http://forums.parallax.com/showthrea...rial-to-921600

    Somewhere in this forum I have also posted a 5 Megabit/sec assembly based full duplex driver, taking data from/to a hub buffer of any desired size. Would take some digging to find it I suppose. Be happy to do that if it is of interest to you.

    Cheers,

    Peter (pjv)

  16. #16

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

    Quote Originally Posted by pjv View Post
    Turbosupra;

    Some while ago I made some improvements to the Full Duplex Serial driver to speed it up a bit. The following thread speaks about it.

    http://forums.parallax.com/showthrea...rial-to-921600

    Somewhere in this forum I have also posted a 5 Megabit/sec assembly based full duplex driver, taking data from/to a hub buffer of any desired size. Would take some digging to find it I suppose. Be happy to do that if it is of interest to you.

    Cheers,

    Peter (pjv)
    I'd be VERY interested in a 2Mbps full duplex driver. Most of the stuff I make hangs off a FTDI USB adaptor, and I have times when it'd be far easier to blast out an ascii .csv data file over the serial port at 2Mbps than switch to a packed binary format that needs decoding software on the PC. (though it sounds like I'd need to make some ASM formatting code [and a faster terminal program] to truly use this speed.)

    You can search for your own posts if you click on you name in the top left of a post. Also you can see everything you've ever attached to a forum post in the dialog to attach a new file.

    Lawson
    micro-power experiments with the propeller.
    Drivers for TAOS TSL3301 line sensor Forum thread, and OBEX
    Lumen Electronic Jewelery Website
    My AWD motorcycle Website and action video
    What I'm paid to work on. UW Lidar Group.
    FME, a Spin-only floating point library with trig, exponential, and logarithm functions. OBEX and Forum.

  17. #17

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

    Hi Lawson;

    Thanks for the tip on how to quickly examine all posts I have made. It was a great help to track down the 5Megabit/sec routines I was referring to. The link is here.

    http://forums.parallax.com/showthrea...rom-to-Hub-RAM

    Holler if you have any questions.

    Cheers,

    Peter (pjv)

  18. #18

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

    Hi Peter,

    Looking at your code, I'm only a PASM novice and a little overwhelmed trying to follow the logic, do you think you could give an example of how to use it?



    Code:
    CON
            _clkmode        = xtal1 + pll16x
            _xinfreq        = 5_000_000
    
    PUB  main
         cognew(@MainProg, 0)
    
    CON
    ScopeBit0       = 1 <<0
    ScopeBit1       = 1 <<1
    ScopeBit2       = 1 <<2
    ScopeBit3       = 1 <<3
    ScopeBit4       = 1 <<4
    ScopeBit5       = 1 <<5
    ScopeBit6       = 1 <<6
    ScopeBit7       = 1 <<7
    ScopeBit8       = 1 <<8
    ScopeBit9       = 1 <<9
    
    RxSearchLong    = 500                                   'how long to search for first received START
    RxSearchShort   = 8                                     'end of message time-out....how long to search for following STARTs 
    RxSampleTime1   = ScopeBit1                             'show when Rx sample is taken 
    
    RxHubAddrExp    = 11                                    'hub receive buffer... arbitrarily at $800
    
    'RxByteExp       = 0                                     'receive 1 byte
    RxByteExp      = 4                                      'receive 16 bytes
    'RxByteExp      = 8                                      'receive 256 bytes
    'RxByteExp      = 14                                     'receive 16K bytes
    'RxByteExp      = 16                                     'receive 64K bytes
    
    
    TxLine4         = ScopeBit4                             'transmit data line
    TxCommence5     = ScopeBit5                             'show duration transmission active
    TxBitTime6      = ScopeBit6                             'show bit duration.... actual position is 2 instructions later
    
    TxHubAddrExp    = 11                                    'hub transmit buffer... arbitrarily at $800
    
    'TxByteExp      = 0                                      'dump 1 byte
    TxByteExp      = 4                                      'dump 16 bytes
    'TxByteExp      = 8                                      'dump 256 bytes
    'TxByteExp      = 14                                     'dump 16K bytes
    'TxByteExp      = 16                                     'dump 64K bytes
    
    
    
    DAT
    'MainProg ==============================================
    'Fast serial ASCII receiver dumps to main ram at 5 Mbits/sec (2 usec per byte) in one continuous stream
    'Then re-transmits the received dump for oscilloscope confirmation of data
    
                  org       0
    MainProg      mov       dira,#$FE                       'port bit 0 input
                  or        outa,#TxLine4                   'set transmit uart to stop condition
    
    ReceiveInit   mov       HubAddr,#1
                  shr       HubAddr,#RxHubAddrExp           'start dump into main   
                  mov       ByteCtr,#1
                  shl       ByteCtr,#RxByteExp              'read selected number of receive bytes
                  mov       SearchCtr,#RxSearchLong         'how long to wait for receive data before returning
                  call      #HubRx5Mbs              wz      'clear zero and for start in receive stream from other prop
    
    TransmitInit  mov       HubAddr,#1
                  shr       HubAddr,#TxHubAddrExp           'start dump from main  
                  mov       ByteCtr,#1
                  shl       ByteCtr,#TxByteExp              'dump selected number of transmit bytes
                  xor       outa,#TxCommence5               'show transmit string commence pulse on scope
                  call      #HubTx5Mbs              wz      'clear zero and send the stream
                  jmp       #ReceiveInit                    'do it again
                  
    
    'Receive Routine =======================================
    HubRx5Mbs     rdbyte    Shifter,#0                      'sync hub
                  sub       HubAddr,#1                      'pre-dec address
                  nop                                       'set hub sweet spot
    StartSearch   jmp       #SrchForStart                   'entry point
    OneBit        mov       SearchCtr,#RxSearchShort        'load number of loops to search for        nop
    FirstBit      and       RxLine0,ina             wc,nr   'parity sample into carry              
                  rcr       Shifter,#1                      'pull sample into shifter
                  djnz      BitCtr,#OneBit                  'test for 7 bits done
                  and       RxLine0,ina             wc,nr   'parity sample bit 8 into carry              
                  rcr       Shifter,#25                     'pull sample into shifter and bit0 justify
                  wrbyte    Shifter,HubAddr                 'save byte in main ram buffer
                  djnz      ByteCtr,#SrchForStart           'track received bytes
                  jmp       #HubRx5Mbs_ret                  'exit on all received            '
    SrchForStart  and       RxLine0,ina             wc,nr   'test for low start condition
            if_c  djnz      SearchCtr,#SrchForStart wz      '2x oversample start bit... zero on time-out
                  mov       BitCtr,#7                       'how many bits... 8th bit is unrolled
                  add       HubAddr,#1                      'next address
            if_nz jmp       #FirstBit                       'look to receive a byte
    HubRx5Mbs_ret ret                                       'exit on search timed out
    
    
    'Transmit Streamer Routine ============================
    TxOneBit      xor       outa,#TxBitTime6                'optional scope bit time indicator.. replace with nop
                  shr       Shifter,#1              wc      'get bit
                  muxc      outa,#TxLine4                   'output it
                  djnz      BitCtr,#TxOneBit                'test for 8 bits done
                  sub       ByteCtr,#1              wz      'keep track of how many done
    HubTx5Mbs     or        outa,#TxLine4                   'stop condition
                  rdbyte    Shifter,HubAddr                 'get value from Hub RAM
    'optionally   rdbyte    Shifter,HubAddr          wz      'get value from Hub RAM and exit on zero terminated string
                  add       HubAddr,#1                      'next byte address
    OneByte if_nz andn      outa,#TxLine4                   'start condition
                  mov       BitCtr,#8                       'how many bits
            if_nz jmp       #TxOneBit +1                    'loop for another byte
    HubTx5Mbs_ret ret                                       'done
    
    RxLine0       long      1                               'receive pin mask... Pin0
    HubAddr       long      0                               'location in main RAM
    ByteCtr       long      0                               'how many bytes to receive/transmit
    SearchCtr     long      0                               'keep track of search time for START condition
    BitCtr        long      0                               '
    Shifter       long      0                               '

  19. #19
    frank freedman's Avatar
    Location
    Phoenix Az -- Hmmm, kinda runs hot & cold
    Posts
    1,033

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

    Quote Originally Posted by turbosupra View Post
    I've tried going beyond 115200 and not had success, has anyone done this besides viewport which I believe is around a gbps.

    Does something in the actual object need to be modified as well? I'd like to go up to 250000 or 460800, I need to compare a bunch of data all at once to chase down an issue I'm having.
    Just an aside since a fast scan of this thread revolves around hacking the serial object without mentioning some other limitstions.

    You should take a look at the RS-232 standards regarding handshake and the fact that you must derate the speed as the line distance increases. Since your project seems to be instrumenting and controlling an engine, in another thread, depending on how you lay out your comms may affect the speeds you can communicate to your data collection system (laptop?) You may need to implement hardware rts/cts or software (xon/xoff) so that you don't overflow and get giberish.

    Although it costs more it may be worth going CAN for the speed, increased distance and noise immunity inherent in CAN. NXP or TI may be a good source of sample devices. I may be mis-crediting, but it seems Jonnymac has threads regarding CAN as well. All of the OEM medical imaging systems I work with use CAN for high-speed non-real time data.

    FF

  20. #20

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

    I went through this code, how would you suggest I test it with spin, I noticed in your last response to that post (quoted below) that no one ever tested it for you with spin.

    I'd like to do that, but what are you looking for me to test with? Just a loop that does a cnt print screen? Am I missing something? They seem pretty close?


    Quote Originally Posted by regularPST
    73008
    73040
    73008
    73040
    73008
    73040
    73008
    73040
    73008
    73040
    73008
    73040
    73008
    73040
    73008
    73040
    73008
    73040
    73008

    Quote Originally Posted by fastPst
    80080
    69520
    70528
    80080
    69520
    70528
    80080
    69520
    70528
    80080
    69520
    70528
    80080
    69520
    70528

    Quote Originally Posted by pjv View Post
    Turbosupra;

    Some while ago I made some improvements to the Full Duplex Serial driver to speed it up a bit. The following thread speaks about it.

    http://forums.parallax.com/showthrea...rial-to-921600

    Cheers,

    Peter (pjv)
    Quote Originally Posted by pjv in 2010
    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)

+ Reply to Thread

Similar Threads

  1. Is it possible to make the pst faster than spin?
    By turbosupra in forum Propeller 1 Multicore Microcontroller
    Replies: 10
    Last Post: 03-22-2012, 01:08 AM
  2. How to make boe-bot roll faster
    By TBP in forum Robotics
    Replies: 4
    Last Post: 10-27-2010, 11:07 AM
  3. Make a Faster I/O (Advanced Programmers Only)
    By Humanoido in forum Propeller 1 Multicore Microcontroller
    Replies: 11
    Last Post: 09-18-2010, 06:56 AM
  4. transleting code to make it faster
    By nicolad76 in forum Propeller 1 Multicore Microcontroller
    Replies: 7
    Last Post: 04-12-2008, 03:31 AM
  5. how can i make my robot go faster?
    By lobo in forum BASIC Stamp
    Replies: 4
    Last Post: 12-04-2005, 03:29 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts