Parsing Strings...

Printable View

- 10th February 2009, 03:55
TerdRatchett

Parsing Strings...

Hi Everyone,

I have written a big chunk of code an it is working well, but I am stuck on something having to do with strings.

I have received a string from a serial device which contains two target strings seperated by a comma. The data looks like this:

1432,765

the length may vary like this:

22567,8345

so the the comma is key as a locator. I can't figure out with what little documentation is in the users manual how to parse the string for these two numbers.

Thanks in advance!
TR
- 10th February 2009, 04:14
mackrackit

Look in the manual under SERIN2.

Look for the part something like:
WAIT STR\n followed by optional end character...for the first part and then use something like WAIT[,] to get the last part.
- 10th February 2009, 10:16
Jerson

Can you clarify what you mean when you say "I have received a string from a serial device" Does it mean it has been stored somewhere and you have to parse it from there? SERIN2 will not do that for you.
- 11th February 2009, 04:02
TerdRatchett

Thanks...

I appreciate all of your help!

I had written the code using Hserin to capture the raw data from my serial port into a single string of [10]. It works so now I need to separate the two values. So...

14575,354 would end up as two longs,

one with 14575 and another with 345. Either number could be as large as 99999 or as small as 1.

Thanks in advance,
TR
- 11th February 2009, 04:13
mackrackit

HSERIN uses the same syntax as SERIN2, so do the "separation" as the data is coming in.
- 11th February 2009, 10:57
Jerson

Ok, since you have the string to be parsed, you will need a parser too! I dont have anything ready at hand but, I'll give it a shot anyway. UNTESTED CODE FOLLOWS

Code:

' assume the string is TOPARSE ' it will return you 2 numbers, one from before the comma, one from after the comma Number1 var Long Number2 var Long Cntr var byte ' counter to index the string ParseNumber: Number1 = 0 ' start with 0 in both numbers Number2 = 0 'collect Number1 for Cntr = 0 to 10 ' you said your string is 10 places long if TOPARSE[Cntr] <> "," then Number1=Number1*10 ' x10 to make place for the new digit Number1 = Number1+TOPARSE[Cntr]-'0' ' I'm assuming this is an ASCII string else goto GetNum2 ' collect the remainder as number2 endif next return GetNum2: for Cntr=Cntr+1 to 10 if TOPARSE[Cntr] <> "," then Number2=Number2*10 Number2 = Number2+TOPARSE[Cntr]-'0' ' I'm assuming this is an ASCII string else return ' because, you said there are only 2 numbers ;) endif next return

You could modify this code to do a repetitive parse. Every time you call it, it would return you a number, but I'll leave that to you.

Good luck.
- 11th February 2009, 15:06
mackrackit

I still think separating the numbers on the way in is the way to go. Although Jerson's code is pretty slick.

Here is what I was thinking. Just tested it using SERIN2 as the chip I have on the bench is not set up for HSERIN right now.

The first WAIT is to keep garbage out.

Code:

N1 VAR LONG N2 VAR LONG LOOP: SERIN2 PORTD.2, 16416, [WAIT("X"),DEC N1,WAIT(","),DEC N2] GOTO DISPLAY DISPLAY: Serout2 PORTC.6, 16416, [ DEC N1, $d, $a] Serout2 PORTC.6, 16416, [ DEC N2, $d, $a] GOTO LOOP

If you need the data in an array just modify the above with STR...
- 11th February 2009, 18:41
TerdRatchett

Hmmm...

Both great suggestions for which I appreciate!!! I'm pondering....
- 13th February 2009, 05:08
TerdRatchett

No success...

I've tried dozens of ideas along those lines and no solution works....

Like:
hserIN 65535, oops, [STR smallp\5, WAIT(","), STR largep\5\13]

problem here is the string size I expect to receive is variable, but the STR forces you to put in the string length. If it's shorter the function doesn't return anything, yet it doesn't time out. I'm ending up with the comma in my first string, even though I'm only looking for it as a seperator and after I receive the first serial data, every time thereafter there is a non-acsii character in the first byte of smallp.

If the data was always the same length it would be a breeze...
- 13th February 2009, 05:43
mackrackit

From the manual:

Quote:

STR followed by a byte array variable, count and optional ending
character will receive a string of characters. The string length is
determined by the count or when the optional character is
encountered in the input.

[STR smallp\10\,]
See if that will get the first part correctly.

Does the data comming in have a qualifying character before the data you want? If so then the first example I gave will work. If it does not have a qualifying character then leave that part out.
- 13th February 2009, 15:25
TerdRatchett

I appreciate your help! Very confused :(

hserIN 65535, oops, [STR smallp\10\","]

The first time thru I get the correct first part of the string. the device was sent 777,53 and smallp received 777.

The second time and every time thereafter the data is skewed. For example if the next packet that comes in is 766,59 smallp receives a 53766. The 53 from the last packet sent....
- 13th February 2009, 16:07
Charles Linquis

It would seem to be a lot easier to capture the whole sequence, then later scan the array for any commas and deal with it that way, especially since when you are using SERIN you have very little processing time available between characters.
- 13th February 2009, 16:19
TerdRatchett

I think that's a great suggestion and I agree. I have been unable to successfully parse it after the fact.
- 13th February 2009, 16:45
TerdRatchett

and to make matters worse I am unable to consistantly and correctly receive serial packets.
- 13th February 2009, 17:30
TerdRatchett

Well, I got the serial function working reliably by doing this:

hserIN 65535, oops, [STR smallp\12\10]

rather than this:

hserIN 65535, oops, [STR smallp\12\13]

aparently the linefeed was the last command sent, so by terminating with a carraige return, the linefeed that followed was polluting the serial stream for the next packet
- 13th February 2009, 18:22
TerdRatchett

So now that I'm just looking at a parsing issue I've changed the serial in code to:

hserIN 65535, oops, [STR smallp\5, WAIT(","), STR largep\5\10]

It doesn't work as expected. When receiving 1480,95...

STR smallp\5 actually captures 5 characters including the comma even though it's the "wait for" character. I can't make smallp\4 because sometimes the data received will be 5 characters. It could also be 3 or 2 or 1 characters.
- 13th February 2009, 18:27
Luckyborg

Why don't you try it this way
hserIN 65535, oops, [STR smallp\5\","]
hserIN 65535, oops, [STR largep\5\13]

then you have the values in 2 streams, each left justified-

David
- 13th February 2009, 18:37
Archangel

Second post

Wow, second post and you are already helping . . . <H2>WELCOME TO THE FORUM DAVID !
- 13th February 2009, 18:44
TerdRatchett

Hi David,

That would almost work. The problem is that neither string is guaranteed to be exactly 5 characters. So if the sent data was 1499,136 I would actually get 1499, likewise if the data is only 3 characters like 210,152 I would actually get 210,1

confusing!!
- 13th February 2009, 19:24
Luckyborg

That is what the option end character is good for. By setting the end character to a "," then the command will take up to but not necessarily 5 characters until it gets the "," or in the second line the Line feed. I put a 13-should be 10, as you mentioned earlier the line feed comes after the carriage return. So assuming you reset the stream before each update to all 0s if you sent the stream
1499,136(CR)(LF)
then
hserIN 65535, oops, [STR smallp\5\","]
would give you an array with "1"-"4"-"9"-"9"-0 in smallp and
hserIN 65535, oops, [STR largep\5\10]
would give you "1"-"3"-"6"-13-0 in largep

You would just then ignore the 13 or re zero it when you do your parsing

Thanks for the welcome Joe, I've been in the forum reading all week, mostly older threads. I'm finally sort of caught up on what is still relevant.
- 13th February 2009, 20:34
TerdRatchett

That was the way I read the manual as well. I thought that as soon as the function saw a character meeting the WAIT criteria it would terminate collecting any more characters. In fact what I'm seeing is that it continues to gather all 5 characters, so it collects the comma as well if the string is less than 5!

The manual says the string length is determined by the count OR when the optional character is encountered. Unfortunately that sentence can be interpreted two ways.
- 14th February 2009, 15:54
mackrackit

Hi,
Played with this some more...
Without a qualifier for some reason the buffer keeps the last data sent and returns it with the next. I guess you do not have a qualifier at the beginning of the string so use the LF or CR at the end.

This is what I am sending
123456789,987654321
and I have my terminal set to terminate the line with a CR LF.
The working code
###############

Code:

<html> <head></head> <body><pre><code> '18F6680 02/14/09 INFEED PARSE TEST BAUD 9600 DEFINE OSC 20 @ __CONFIG _CONFIG1H, _OSC_HS_1H @ __CONFIG _CONFIG2H, _WDT_ON_2H & _WDTPS_128_2H @ __CONFIG _CONFIG4L, _LVP_OFF_4L DEFINE LCD_DREG PORTG DEFINE LCD_DBIT 0 DEFINE LCD_RSREG PORTE DEFINE LCD_RSBIT 0 DEFINE LCD_EREG PORTE DEFINE LCD_EBIT 1 DEFINE LCD_BITS 4 DEFINE LCD_LINES 4 DEFINE LCD_COMMANDUS 3000 DEFINE LCD_DATAUS 150 '############################################### PAUSE 100 : LCDOUT $FE,1,"TEST" N1 VAR LONG:N2 VAR LONG START: N1 = 0 : N2 = 0 HIGH PORTG.4 :PAUSE 250:LOW PORTG.4 RCSTA.4 = 0 : RCSTA.4 = 1 'CHANGE LINE FEED AND CARRIAGE RETURN AS REQUIRED RCSTA=$90:TXSTA=$24:SPBRG=129:HSERIN[WAIT($a),WAIT($d),DEC N1,WAIT(","),DEC N2] LCDOUT $FE,1,DEC N1 : LCDOUT $FE,$C0,DEC N2 : GOTO START </code></pre></body> </html>
- 15th February 2009, 03:38
TerdRatchett

Hi Dave,

I think your latest solution might have worked, but I had already got it working by parsing it after the fact based on Jersons parse routine. I really appreciate everyones input. Here is what the working code looks like:

hserIN 65535, oops, [STR inputdata\12\10] 'get the serial data
gosub ParseNumber 'split the raw data into 2 numbers

ParseNumber: ' collect both pieces of the data in sep arrays
for Cntr = 0 to 10
if inputdata[Cntr] <> "," then ' Found comma? We've got first
smallp[Cntr] = inputdata[Cntr]
else

Cntr2 = Cntr 'marks where the comma was
'goto earlyexit
goto GetNum2 ' Now get the second number
endif
next
earlyexit:
return

GetNum2:
CNTR = Cntr + 1 'get past the comma
for Cntr = Cntr to 10
if inputdata[Cntr] < "0" then
RETURN
else
If inputdata[Cntr] > "9" then
RETURN
ELSE
largep[Cntr-Cntr2-1] = inputdata[Cntr] ' It's a valid number
endif
ENDIF
next

return

I had to modify the array pointer for the second number by subtracting the point at which the comma was found on the first pass from it's pointer. In other words the pointer for the input data can't be used directly to point to the second number.
- 15th February 2009, 04:13
Archangel

Proof Again There is more than 1 right way to do almost everything.