Shop OBEX P1 Docs P2 Docs Learn Events
SERIN and the scratchpad — Parallax Forums

SERIN and the scratchpad

WriglyWrigly Posts: 9
edited 2005-10-12 15:34 in BASIC Stamp
Have a B2SE, my question concerns using SERIN and the scratchpad area. I need to take a text string rather long and put it in scratchpad area and then send it back out (SEROUT) a little later . I have seen the PUT and GET commands but see that they are byte only. I am familar with the arrays and was wondering if it was possible to still do this with the scratchpad. Needles to say I am rather new to stamps but so far very excited by them so far, any help would be great.

Thanks Wrigly

Post Edited By Moderator (Dave Andreae (Parallax)) : 10/10/2005 8:23:03 PM GMT

Comments

  • Jon WilliamsJon Williams Posts: 6,491
    edited 2005-10-10 22:39
    When you buffer to the Scratchpad you must know how many bytes are coming in. If you do, the rest is easy: you write a loop (for the number of characters you need) that iteratest from 0 to N-1 (N is the length of your string), uses GET to retrieve a byte form the SPRAM and SEROUT to send it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • WriglyWrigly Posts: 9
    edited 2005-10-11 12:05
    Ok to add a twist of take it a step further into the app, I have no way of knowing the exact length of the string it can be 4 to 40 bytes but I can add a EOM (end of meesage) indentifier to the incoming ASCII text coming in thru the SERIN. Would this help with not knowing the exact length and thanks for the reply.

    Wrigly
  • StampUSRStampUSR Posts: 48
    edited 2005-10-11 14:06
    "Have a B2SE, my question concerns using SERIN and the scratchpad area. I need to take a text string rather long and put it in scratchpad area and then send it back out (SEROUT) a little later."

    If the text stream is coming in pretty quickly this is much more likely to work on any of the 'P' series Basic Stamps. They can basically write directly to scratchpad from SERIN. If you try doing it byte by byte SERIN then PUT you may miss characters if you aren't using flow control.

    As far as dealing with a variable length string that is pretty easy on the 'P' series. First thing to do is set the entire scratchpad ram to 0x00 in bytes.

    Then perform the SERIN redirected to scratchpad of up to 126 bytes. Include a timeout in that call and have both a full buffer and a timeout go to the same section of code. In that code read the first word out of scratchpad, if it is equal to 0x00 then no data has arrived and you loop.

    If it is not 0x00 you can find out how many bytes were received by checking the scratchpad till you hit 0x00. From there you can do whatever you need to do with the byte string you have received. After you are done clear scratchpad and start over.
  • Bruce BatesBruce Bates Posts: 3,045
    edited 2005-10-11 14:38
    Wrigly -

    An EOM (end of message) character is an excellent idea, so long as it's well chosen, and won't appear elsewhere in the data. Any other method of fielding a data stream of unknown length, which has no inherent length field within, that doesn't consider the incoming data is ripe for failure under the right set of circumstances.

    Beside all that, knowing the end of data delimiter beforehand makes scanning the string much easier from a programming point of view. In fact, if possible, and depending on the application, you might want to consider stuffing the (binary) length in (only one byte required), next to the EOM character either on the incoming input data or in the output, if it's written back out for further processing down the line. This can used to validate the data, and also to ease some of the programming if the length of the incoming data is needed.

    Just some thoughts.

    Regards,

    Bruce Bates
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2005-10-11 19:04
    Unless you've got lots of pacing time between bytes you're probably not going to get them into the Scratchpad. The reason is tha the SPSTR modifier requires a specific length and does not look for a terminating character like STR does. I've used SPRSTR with GPS data know that I could trucate the input and not have any problems -- but that doesn't seem to be the case here.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-10-11 20:04
    StampUSR said...(trimmed)
    As far as dealing with a variable length string that is pretty easy on the 'P' series. First thing to do is set the entire scratchpad ram to 0x00 in bytes.
    Then perform the SERIN redirected to scratchpad of up to 126 bytes. Include a timeout in that call and have both a full buffer and a timeout go to the same section of code. In that code read the first word out of scratchpad, if it is equal to 0x00 then no data has arrived and you loop.
    If it is not 0x00 you can find out how many bytes were received by checking the scratchpad till you hit 0x00. From there you can do whatever you need to do with the byte string you have received. After you are done clear scratchpad and start over.
    Hello,

    ·· I wanted to make sure you understood how the SPSTR function works.· If you're using it to bring a fixed length string into Scratchpad RAM then you cannot rely on 0x00 to determine the end of the string, nor to terminate it, since 0x00 could be within the characters being stored.· The SPSTR function will input the number of characters you specify into the Scratchpad RAM starting at location 0 regardless of value.· The only thing you can do is use what you know, which is the number of characters brought in, since you specify that anyway.· Just wanted to clarify that for everyone, I got the impression you were referring to that command since you mentioned the BS2p in the sentence prior to that.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • StampUSRStampUSR Posts: 48
    edited 2005-10-12 14:15
    "I wanted to make sure you understood how the SPSTR function works. If you're using it to bring a fixed length string into Scratchpad RAM then you cannot rely on 0x00 to determine the end of the string, nor to terminate it, since 0x00 could be within the characters being stored. The SPSTR function will input the number of characters you specify into the Scratchpad RAM starting at location 0 regardless of value. The only thing you can do is use what you know, which is the number of characters brought in, since you specify that anyway."

    Chris,

    Except that the length of characters he needs to grab is variable... IOW unknown. So you can't just specify a length for SPSTR and then work off that length as what may be received is less then that. Without a timeout you won't get the return from SERIN until enough packets come in to hit the length of the call. Likely in many situations waiting for x number of packets won't really work well.

    Hence the need to use a timeout in the SERIN command along with SPSTR.

    Once you introduce the timeout you then need a way to find out if you actually received any data or not. As you can hit the timeout with or without receiving any data. SERIN doesn't return how many bytes were actually received by the call.

    Hence the need to set Scratchpad to some value that won't be received in SERIN and check against that.

    If the first byte/word of scratchpad is that null value you then know no data was received on that SERIN call.

    However if the first byte/word isn't that null value you know data has arrived. By then checking Scratchpad byte by byte till you hit the null value you then know the number of bytes returned by SERIN and can then act accordingly on the data.

    Once you are finished with the received data and want to wait for the next data packet you reset Scratchpad completely to the null value and loop to the SERIN command again.
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-10-12 15:08
    I see what you're saying there, as I said, I just wanted to make sure nobody misunderstood the way that function worked.· I guess maybe I read too much into your original message.· You weren't referring to using the SPSTR function, but rather lopping the characters in, one at a time.· In this case it is also possible to tell how many characters were received, since you need to know where you're writing the data to in ScratchPad RAM, so you already know the number of characters received.· Or am I misreading your statement again?· =)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • StampUSRStampUSR Posts: 48
    edited 2005-10-12 15:16
    " You weren't referring to using the SPSTR function, but rather lopping the characters in, one at a time. "

    I was refererring to using the SPSTR function actually. Like you said if you deal with it byte by byte you already know what has been received.

    I was using the SPSTR function because at higher baud rates that is the only way I was able to get reliable data reception. Trying to deal with data byte by byte as it came in resulted in lost bytes.

    With the SPSTR I was getting reliable rececption up to 115,200 as long as the packet was 126 bytes or less.
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2005-10-12 15:21
    Okay,

    ·· I think I see what you are suggesting...Correct me if I am wrong here.· I figured if I was confused by what you meant, so would the OP, and others.· Let me know if I have this now...

    ·· You are using the SPSTR function to get data into the ScratchPad at high speed.· When it times out, you go to read what was stuffed in there, not knowing how many bytes.· So now what needs to be done is he will need to find a unique character to identify the end of the data.· 0x00 may not work.· Needs to be something that won't normally come in via serial.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • StampUSRStampUSR Posts: 48
    edited 2005-10-12 15:34
    "You are using the SPSTR function to get data into the ScratchPad at high speed. When it times out, you go to read what was stuffed in there, not knowing how many bytes. So now what needs to be done is he will need to find a unique character to identify the end of the data. 0x00 may not work. Needs to be something that won't normally come in via serial."

    That is pretty much it. You would want to fill the Scratchpad with a value you likely won't be receiving from SERIN. To further help avoid accidentally triggering this checking I ended up looking for the end in WORDs. In other words looking for a WORD value of 0x00 0x00. So even if I received a Byte of 0x00 in the middle of the SERIN string that wouldn't trigger the end of string checking because the word value wouldn't be 0x00 0x00.

    There is also one additional check that if I haven't found the END by byte 126 of the Scratchpad ram then exit and work with what I have as the receive filled the Scratchpad.
Sign In or Register to comment.