Shop OBEX P1 Docs P2 Docs Learn Events
Parsing input parameters — Parallax Forums

Parsing input parameters

bryan costanichbryan costanich Posts: 29
edited 2007-02-14 17:09 in BASIC Stamp
hey all, i have a .net 2.0 winforms app that send info to the basic stamp and the stamp does some stuff based on the input. this works just fine. right now it's making an LED blink based on the number passed in. in the bs2 file i'm using:
SERIN 16, BAUD_9600, [noparse][[/noparse]DEC numberOfBlinks] ' receive one byte

like i said, this works fine. however, i want to send in multiple parameters. and before i go off writing a routine to parse input parameters and types and was wondering if anyone had already solved this in pBasic. if you have, i'd love to see your code, rather than having to sit down and write it myself.

also, if anyone wants the source code to the winforms app, i've attached it. note that it also listens for the output from the stamp (i'm sending back the iteration it's on) and displays that in the app.

i've also attached the bs2 file if you're interested.

Comments

  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2007-02-12 16:37
    Bryan,

    One thing you could do is to pad your packet with a Header and use the WAIT modifier to catch that header and input a specific number of bytes and possibly a checksum value. Starting from a known point you could input multiple bytes into different variables for your different needs. I hope this helps. Take care.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2007-02-12 18:28
    Hi Bryan, I have used a one byte instruction in a similar set up where I will send the byte as hex and use the high nibble as the device select and the low nibble as the command, this allows for 16 devices with 16 commands, for example F4 would be device 16 command 4 then catch it at the Stamp with a Case Select. It's a bit limiting just depends what your wanting to do.

    Jeff T.
  • bryan costanichbryan costanich Posts: 29
    edited 2007-02-12 22:14
    code anyone? [noparse]:)[/noparse] there are a million ways in theory to parse input params, but i'm interested in seeing people's actual code solutions.
  • TechnoRobboTechnoRobbo Posts: 323
    edited 2007-02-13 03:47
    Here's an example···

    Your program waits for a "?" character from the Stamp indicating it's ready to receive data.
    Your program sends data in this format:
    first·string (1 character header)·= "!"
    second string(1 character) indicates servo to adjust(1 thru 8)= "1"
    third string indicates position to set servo(4 characters)= "0025"
    fourth string indicates speed of rotation (2 characters) = "09"

    The command string looks like this:· "!1002509"


    The Stamp code looks something like this:

    Redo:
    ······· DEBUG "?",CR· 'stamp requests·data from your program
    ······· SERIN 16, $4054, 5000, Redo,[noparse][[/noparse]WAIT ("!"),DEC1 servo,DEC4 position,DEC2 speed]




    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Have Fun


    TR

    Post Edited (TechnoRobbo) : 2/13/2007 4:12:04 AM GMT
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2007-02-13 18:26
    This is from the example I mentioned, I don't have a header as TR and Chris suggested but that could easily be added in there. It takes an input of a two character string in hex format and places it in one byte. It's usefulness lays in the fact the high nib and the low nib represent two different instructions contained in one byte. And like you said there are a million ways to achieve the same result, but simple is good. One of the things that initially gave me a problem with such a program was the echo from port 16, once I had devised a routine to remove each echo I was able to get two way communication between the Stamp and PC, but as you are already sending data back to your app I see you already have that solved.

    SERIN 16,16468,[noparse][[/noparse]HEX2 in_byte]
    device=in_byte.HIGHNIB
    command=in_byte.LOWNIB

    Jeff T.
  • bryan costanichbryan costanich Posts: 29
    edited 2007-02-14 07:19
    how are you removing the echo in your solution?
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2007-02-14 09:44
    Gents -

    If you don't use pin port 16, you won't have that problem (echo). Use another pin port, since the echo will only appear on the programming port (pin port 16).

    Regards,

    Bruce Bates

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    <!--StartFragment -->
  • UnsoundcodeUnsoundcode Posts: 1,532
    edited 2007-02-14 17:09
    Thats a good point Bruce, something I didn't realize for quite a while and well worth pointing out. There are still many times I want to use P16 though so to answer Bryan's question this is how I handle the echo in my routines.

    I make sure the input buffer is empty

    I hold the length of my transmit string in a variable

    then I wait for the input buffer to equal the length of the last transmit string

    I discard that string as the echo

    the next data recieved should be valid

    Jeff T.
Sign In or Register to comment.