Shop OBEX P1 Docs P2 Docs Learn Events
SERIN data speed — Parallax Forums

SERIN data speed

jjohns63jjohns63 Posts: 9
edited 2009-03-12 03:18 in BASIC Stamp
Hi,

I'm trying to read data from a serial device, via the I/O pins with a 22kOhm resistor in series with the data line. I was poking around on how to use SERIN and found this website: www.emesys.com/BS2rs232.htm#SERIN and it notes that a device sending data at 9600 baud with 1 stop bit will clog up the BS2. Now i'm pretty sure that my device is sending data straight out with only 1 stop bit between each byte. So it looks like to workaround the limitations of the BS2 you can have it write the data to a string. So I have:
a VAR Byte(5)
SERIN 0,$54,[noparse][[/noparse]str a\5]



I know that to access each byte, I use a(x) where x is the index of the array that I want to access. My question is, will the above code work? That is, will it fill in the array with the first byte to the last byte?

Comments

  • stamptrolstamptrol Posts: 1,731
    edited 2009-03-10 17:47
    The success at 9600 will depend on a couple of things.

    One, the Stamp has no serial buffer so its up to your programming to make sure you start watching for data at the right time. For instance, with the code shown, if the Stamp started up while the data was already flowing, it would grab the first 5 bytes regardless of what they were.
    SERIN has a number of modifiers which help with this, especially the WAIT and SKIP directives. These will let you watch for some "marker" character, then grab a specific number of bytes. This is typically how I do it and it is very reliable, particularly grabbing the data as a string.

    Secondly, if you expect to be able to process the data on the fly, between reads of the serial line, you'll probably be a bit disappointed. A slower speed, say 2400 or 4800 gives the Stamp some breathing room. Alternatively, grab the right data then go and process it without worrying about catching every serial transmission. When processing is done, go back and get the next serial transmission. Again, this works best if your data has a known "marker" character. ( say a leading ! or (, for instance) which will help you get synchronized for the next transmission.

    There are provisions to use a handshake line which gives rock-solid communication even at very high speeds, but both devices need to be smart enough to use the feature. Really useful on Stamp-to-Stamp communication.

    Without fail, setting up the hardware and testing the actual circuits will get you up to speed the quickest.

    Cheers,

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tom Sisk

    http://www.siskconsult.com
    ·
  • jjohns63jjohns63 Posts: 9
    edited 2009-03-12 03:03
    Interesting, I didn't think about the wait() function. And yes, I do some processing but don't care about every single packet coming through, so long as I time it out to process it quickly enough.

    So my data is always preceded by 0x81, so something like
    serin 0,$54,[noparse][[/noparse]wait($81), STR a/4]
    



    I was previously using an IF statement to check for the 0x81 but this seems like it would work better, problem is, I connected everything and it's not working as expected. I have:

    ' {$STAMP BS2}
    ' {$PBASIC 2.5}
    
    a VAR Byte(4)
    DO
    
    SERIN 15,$54,[noparse][[/noparse]wait($81),STR a\4]
    
    DEBUG HEX a(0),":",HEX a(1),":",HEX a(2),":",HEX a(3),CR
    
    LOOP
    



    but only every once in a while do I actually get anything printed out to the debug console, and even then it's not what I expect.
    A sample of the expected data is:
    81:0F:7E:01:13

    And what's seen by the BS2:
    3F:78:A0:7F:76



    As a side note, the serial device I'm trying to use is a resistive touchscreen, and the touch controller does not have the ability to use a "handshake" line.

    Post Edited (jjohns63) : 3/12/2009 3:13:17 AM GMT
  • jjohns63jjohns63 Posts: 9
    edited 2009-03-12 03:18
    OK, it was just that I needed to use inverted mode. Now I get data, but it's still not what it should be.

    There's two problems,
    1) I'm missing the first byte after the 0x81
    2) The data is still not what I expect to see

    I'll keep playing around with it and report what I find
Sign In or Register to comment.