P1 to P2 conversion question - solved
DiverBob
Posts: 1,108
I have a piece of parsing code that I have used successfully for a long time on a P1 but am getting strange results running the code on the P2.
pub extractfield(n, pstr, sep):result | len, val, sign, flag, k 'routine designed by Jon McPhalen
' returns decimal value of filed n
' pstr is source string/buffer
' sep is seperator character
' look for start of field
len := strsize(pstr) ' maximum length to search
repeat while (n > 0)
if byte[pstr++] == sep ' if character is seperator
--n ' decrement field count
if (--len == 0) ' if end of string
return 0
' extract value
val := 0
sign := 1
flag := false
repeat len
k := byte[pstr++] ' get character from string
case k
" " : if (flag) ' if already in field
quit
"-" : ifnot (flag) ' if not in field
sign := -1 ' set sign
else
quit
"0".."9" : val := (val * 10) + (k - "0") ' convert ascii to decimal
flag := true ' mark entry to field
other : quit
return val * sign
When feeding a string ( n = '4' pstr = "$,900,0,0,-4,0,0" sep = ",") into the function it works perfectly until it gets to a negative entry (-4 in this case). It returns a value like 5532 instead of -4. if I remove the '* sign' from the final return statement then I get the positive value of the entry (4).
So it appears to be a problem with the "return val * sign" code. Does the P2 not process returns the same as the P1? I did try putting 'val := val * sign' just before the return statement with return only returning val but got the same response which makes me feel the problem may be in the sign variable instead. But the code is pretty straightforward so I'm not seeing where to go from here. Anyone see what I am missing?
Comments
I have a vague recollection about spin2 having numeric variables unsigned by default. Not specifically remembering, though.
Are you using Prop Tool, Pnut, or FlexSpin?
Using PropTool 2.5.3
If I call your methode from this main program, I get
-4as the result.PUB main() | x x := extractfield(4,string("xx,yy,123,55,-4,e"),",") debug(sdec(x)) repeatAndy
I’ll try that out and report back. I didn’t try using Debug, I’ve been sending the results to PST, could that be an issue….
Is this in a secondary cog? Are you running out of stack?
I did a little clean-up of my old formatting and it seems to work.
pub run_extraction() | x repeat x from 0 to 4 term.dec(extract_field(x, @Message, ",")) term.tx(13) term.tx(13) repeat x from 0 to 6 term.dec(extract_field(x, @BobTest, ",")) term.tx(13) dat Message byte "10, -5, 167, -2000, Jon", 0 BobTest byte "$,900,0,0,-4,0,0", 0 pub extract_field(n, p_str, sep) : value | len, sign, flag, k len := strsize(p_str) repeat while (n > 0) if byte[p_str++] == sep --n if (--len == 0) return 0 sign, flag := 1, false repeat len k := byte[p_str++] case k " " : if (flag) quit "-" : ifnot (flag) sign := -1 else quit "0".."9" : value := (value * 10) + (k - "0") flag := true other : quit value *= signThanks for looking at the code Jon, I’ll re-enter the routine with your changes.
Jon, I ran your update with some sample data and it output correctly when running it by itself as a test. However I still get the erroneous response to negative numbers when I run it in my program. The input data looks good when I examine the string and Cluso's multiport serial driver program display to the PST works with the test data. I increased the input buffer size with no change. I need to come up with another idea since obviously it isn't the extraction code or display code.
I've tried several variations of the code but keep getting the same output value of 5532 when a -4 is the parsed value. I'm sure it's a mistake on my part so now I just have to narrow it down. Time to hang it up for the night and come at it fresh tomorrow. Thanks for the help so far everyone.
I think it may have to do with your output variable type, or something that's affecting it. I did this:
...and the output is 65532. If you're doing some sort of formatted display that is only using four digits, you'd get 5532.
I hadn’t thought of that Jon. I’ll get down and check that out.
I did try to figure out how you'd ever get from -4 to 5532. Truncating to 16 bit first and then to 4 digits did not come to mind...
Though that's a cascade of two unrelated things going very wrong, which seems unlikely.
I'm of the idea this is a set of events that would be easy to encounter.
That’s exactly the code layout for the PST to display the value. I changed the display string to display 5 digits and got 65532 as a value. Once I changed the variables to longs, I get the correct output.
Jon, you are a Spin coding savant! Last night after I got into bed I thought the only thing I hadn't checked was the type of variable. You had the answer when I checked this morning. Thank you once again for the heads up!
I'm glad you got things sorted, Bob.
That's kind, but the truth is that I've stumbled through enough potholes that I can spot them more easily now.
There can be a valid reason to use a word instead of a long, but still recover the sign. On a control project for JonyJib we send signed words over RS-485 from the controller to the driver. You can use signx in the P2 to convert to a long or correct for display.
Test post