String Seperation

I am reading in an ASCII string through Bluetooth. I get the string. I need to be able to separate out info. The string format is as follows;

"t=00 b=000 r=00 st=00000 sp=00000"

I want to be able to put each 'number' into a variable. For example I receive

"t=12 b=222 r=12 st=05000 sp=10000"

then I want to take t=12 and store '12' in variable 'Threshold', b=222 will go into 'Buffer', r=12 into 'Retard', st goes to 'Start' and sp will be moved into 'Stop'

I was thinking something about doing something like

SERIN 1,N2400,["t="],Threshold
SERIN 1,N2400,["b="],Buffer
SERIN 1,N2400,["r="],Retard
SERIN 1,N2400,["st="],Start
SERIN 1,N2400,["sp="],Stop

How will it know to only store 12 in 'Threshold' after the first line of code and not store everything after t= into 'Threshold?

I just found out when I search for String Parsing instead of String seperation, I get a hell of alot of ideas!!!

Something like this might get you started, your string is "t=12 b=222 r=12 st=05000 sp=10000"


t var byte
b var byte
r var byte
st var word
buffer var byte[18] 'array variable to hold incoming string
serin 1,n2400,[STR buffer\18] 'get 18 bytes, store in buffer (I'm assuming that the
'quotation marks are part of the string.)
t = buffer[3]
b = buffer[7]
r = buffer[11]
st.highbyte = buffer[16]
st.lowbyte = buffer[17]

Ok, so now you have your string in the buffer. To parse it out you can get at the individual bytes like so; buffer[0] holds the ", buffer[1] holds the letter t (actually it holds the ascii value, 116, buffer[2] holds the equal sign, ascii 61, buffer[3] holds (hopefully,) the variable, which in your example string is 12. Buffer[7] holds the variable 222, etc. I haven't used serin, I always use hserin, and I can't lay my hands on a Picbasic manual to check the syntax, but I think you get idea. You can do something like lcdout $fe,1,"t= ",dec buffer[3] if you have an lcd connected to see the variable, in case I counted wrong.

Good Luck,

Jerry.

By the example Jerry has given, the buffer would hold the ASCII values of the numbers you are interested. You then have to convert the ASCII strings to numbers.

Also note that your st and sp numbers are limited to 0-65535 range since they are WORD variables. If they can get values of more than this, PBP 2.50 might help you, I am not sure since I did not upgraded yet.

Another option is to use the SKIP modifier of the SERIN2 and HSERIN commands but this might mess things since common characters are appearing inside the string two times. The 't=' and 'st=' could confusse the modifier if timing is lost.

Ioannis

Can't you do something like this as it is coming in?

T VAR BYTE
B VAR WORD
R VAR BYTE
ST VAR WORD
SP VAR SP


SERIN2, 1,N2400,[DEC2 T,DEC3 B,DEC2 R, DEC5 ST,DEC5 SP]



To my way of reading the book but not having tested, this would break up a string of 11222334444455555 into 11 in T, 222 in B, 33 in R 44444 in ST and 55555 in SP

So long as ST and SP are not larger than 65535 I reckon that should work??
However I could be wrong of course.
That is what I would start playing with and take it as it comes.

Unless I got the string wrong and it is EXACTLY "t=00 b=000 r=00 st=00000 sp=00000"

Then I would try something like:

SERIN2 1,N2400,[SKIP2, DEC 2 T, SKIP 3, DEC3 B, SKIP 3, DEC2 R, SKIP 4, DEC5 ST, SKIP 4,DEC5 SP]


So, that should skip the "t=" grab the 00 into T, skip the " b=" grab the 000 into B, skip the " r=" grab the 00 into R, skip the " st=" grab the 00000 into ST, skip the " sp=" grab the 00000 into SP

Once again the numerical sizes would apply as would the experimenting.
Anyway, that's where I would start playing.

SKIP is good but the Serin2 must be well synchronized at the beginning of the transmision.
CASE Else the variables will me messed up!

Is there a start sentinel before the "t=00 b=000 r=00 st=00000 sp=00000" so that a WAIT modifier can be used?

Ioannis

Ioannis,

I was assuming that not all of the bytes would be in ascii, I have a device that I communicate with that sends ascii labels like "b=" and then sends hex values as the variables change. That's why I suggested that he might want to send the buffer[3] byte out to an lcd, just to make sure. I know I went nuts testing with hyper-terminal, because it kept taking the hex values and converting them to ascii characters and printing out nonsense.

Jerry.

Quote:

---

Originally Posted by b1arrk5

...
I know I went nuts testing with hyper-terminal, because it kept taking the hex values and converting them to ascii characters and printing out nonsense.
...

---

Yes, I understand what you mean... 8-)

Ioannis