Shop OBEX P1 Docs P2 Docs Learn Events
Fastest way to communicate with a PC — Parallax Forums

Fastest way to communicate with a PC

FredBlaisFredBlais Posts: 380
edited 2010-08-04 05:25 in Propeller 1
Hi, I need to send three LONG values and receive three LONG values at a constant·rate of exactly 1kHz between the prop and a PC. Is the full duplex serial object is able to do it? What is the fastest known way of passing values btw a pc and the prop (if I wanted a comm faster than 1kHz)?

Comments

  • K2K2 Posts: 693
    edited 2010-08-03 19:11
    Fast is easy. Deterministic is another matter. Windows (and DOS before it) is the polar opposite of a RTOS. If you don't provide buffering of some sort, you are sure to lose data because the PC will not respond to your instantaneous demands except on freak occasions when it feels like it. The PC is more about queueing up large DMA events than it is about being interrupted cada nada just to fetch three LONGS.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "Let's not bicker and argue about who killed who."
  • Dave HeinDave Hein Posts: 6,347
    edited 2010-08-03 19:44
    If you do the math you get (3 longs) * (4 bytest/long) * (10 bits/byte) * 1 KHz = 120,000 buad.· A Spin program will not keep up with this rate unless you use bytemove to move the data.· That's assuming you send the data as raw bits.· If you send it as hex digits the rate would be 240,000 baud.
  • laser-vectorlaser-vector Posts: 118
    edited 2010-08-03 19:48
    if my math is right.. then theoretically at a baud rate of 115200,

    115200 / 32 'bits per long long =

    3600 / 3 'three longs = 1200hz

    [noparse][[/noparse]edit]

    oops, dave already got this one

    Post Edited (laser-vector) : 8/3/2010 7:56:01 PM GMT
  • laser-vectorlaser-vector Posts: 118
    edited 2010-08-03 19:58
    looks like i may have been missing something in my formula,

    Dave, could you explain the (10 bits/byte) part?
  • Dave HeinDave Hein Posts: 6,347
    edited 2010-08-03 20:23
    I'm including start and stop bits with the 8 data bits.
  • FredBlaisFredBlais Posts: 380
    edited 2010-08-03 22:21
    laser-vector said...
    looks like i may have been missing something in my formula,

    Dave, could you explain the (10 bits/byte) part?

    Hahaha, indeed, it looked really strange [noparse]:)[/noparse]
  • JasonDorieJasonDorie Posts: 1,930
    edited 2010-08-03 22:24
    Are the values you're sending actually using all 32 bits? If you're only using a portion of the range, you can just send 8, 16, or 24 bits per value, and sign extend back up on the other end. Or, if the values DO use all 32 bits, but change slowly, you could send a 16-bit delta from whatever the previous value was. Will something like that work for you, or are the values not that well behaved?

    Jason
  • FredBlaisFredBlais Posts: 380
    edited 2010-08-04 01:07
    Hi Jason, you're right... I may not need full 32 bits precision, 16 bits may be more than enough. And the data will change somewhat slowly.
    I'm seeking a project for my final year EE, and I was wondering if developing an haptic feedback system with the prop would be do-able. I have recently worked with professional haptics, but they cost in the 10k-40k$ range. see
    www.sensable.com/documents/images/PhantomDesktop_Large.jpg
    These are 6-7 degree of freedom devices. A 3 dof system would need to send XYZ position to a remote computer and receive force feedback on the 3 dof. I've been told that data need to be isochronous at 1kHz for the system to behave realistically. On the computer side, scene graph API exist to use the haptic device. see www.h3dapi.org/

    back to data transfer, I still wonder if the full duplex serial can do it. or maybe Micah usb host? Maybe there is an interface chip that could handle high speed serial transfer like firewire...

    Post Edited (FredBlais) : 8/4/2010 2:37:43 AM GMT
  • $WMc%$WMc% Posts: 1,884
    edited 2010-08-04 01:49
    FredBlais

    PropBasic can send it at 230K4 Baud with a 5MHz xtal PLL set to 80MHz......TX_Baud CON "T230400"

    I think this will catch/send all 3 longs in the time frame your after.

    You'll need a buffer on both ends

    You can also use a 6.25Mhz Xtal if code overhead slows things down.·= Prop at 100Mhz

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    The Truth is out there············___$WMc%___···························· BoogerWoods, FL. USA


    want speed?·want·to use the Propeller?·want to stay with BASIC___www.propbasic.com___


    You can feel stupid by asking a stupid question or You can be really·stupid by not asking at all.



    Post Edited ($WMc%) : 8/4/2010 1:57:37 AM GMT
  • pjvpjv Posts: 1,903
    edited 2010-08-04 02:12
    Hi Fred;

    With a small scheduler and assembler code you can make a single cog do deterministic simultaneous transmit and receive at the rate Dave indicated 120,000 baud. Note however that 120,000 is not a "standard" speed for the PC, but perhaps you can live with the standard 115,200, and all will be well. I trust that transmitting and receiving will be simultaneous.

    If you are interested in this approach, I can guide you to achieving this..... I could, but probably should not write the code for you as that way you will not learn as much. But surely I can get you there.

    P.S. The fastest deterministic speed is about 5 Megabytes per second; one cog for transmit and one for receive. Not sure how that ligns up with the available PC speeds.

    Cheers,

    Peter (pjv)

    Post Edited (pjv) : 8/4/2010 2:18:13 AM GMT
  • JasonDorieJasonDorie Posts: 1,930
    edited 2010-08-04 05:25
    You could always use two separate FullDuplex objects, and modify them to be "single direction". I read recently that doing so can get them to run at up to 230,000bps. Really, you should be able to push data to the PC at a VERY high rate - serial comms use a lead bit to synchronize to, and the remaining bits only have to be within 5% of the actual speed. You should be able to read data -really- fast for short bursts. You could probably write a custom serial send routine that'd push a byte out by just using a few shift and set instructions, maybe using NOPs or WaitCnt instructions in between. Use a cog for send and another for receive - it'd take some work, but it'd be fast.

    J
Sign In or Register to comment.