Shop OBEX P1 Docs P2 Docs Learn Events
For those of you that use or have used other microchips ... - Page 2 — Parallax Forums

For those of you that use or have used other microchips ...

2»

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2011-09-28 14:55
    I think the problem you're running into is that the Strings object uses an internal buffer to hold the results of the last operation. It's the address of this buffer that's returned from a lot of the method calls. If you call one of the Strings methods, the buffer's contents will likely be modified. If you want to save the contents of the last Strings operation, you have to copy the string. It's not enough to save the buffer address.

    Typically you'd do something like:

    variableName := strings.StrRev(@rxVariableNameTemp)
    bytemove(@otherStringTemp,variableName,strsize( variableName )+1)
    delimiterPositionForName := strings.StrPos(@otherStringTemp, delimiter, 0)
    variableName := strings.StrParse(@otherStringTemp, delimiterPositionForName + 1, byteLimit)
    bytemove(@yetAnotherTemp,variableName,strsize( variableName )+1)
    variableName := strings.StrRev(@yetAnotherTemp)
  • turbosupraturbosupra Posts: 1,088
    edited 2011-09-28 18:02
    Mike, thank you ... that was the answer. I can now enter in one variable=value at a time (in between prop power cycles), but when I enter a second/different variable=value after the code loops, everything bombs out. I'm guessing this is related to the previous issue of buffers. I tried using a bytefill at the beginning of the loop, but that is not fixing it. I'd like to clear each variable array after a final value is returned, for the next time it is used.

    I guess I've been a little spoiled with .net and the garbage collector ... is there a place I can read more about this, so that whatever is happening I can have a better understanding of?

    Thanks again.


    Mike Green wrote: »
    I think the problem you're running into is that the Strings object uses an internal buffer to hold the results of the last operation. It's the address of this buffer that's returned from a lot of the method calls. If you call one of the Strings methods, the buffer's contents will likely be modified. If you want to save the contents of the last Strings operation, you have to copy the string. It's not enough to save the buffer address.

    Typically you'd do something like:

    variableName := strings.StrRev(@rxVariableNameTemp)
    bytemove(@otherStringTemp,variableName,strsize( variableName )+1)
    delimiterPositionForName := strings.StrPos(@otherStringTemp, delimiter, 0)
    variableName := strings.StrParse(@otherStringTemp, delimiterPositionForName + 1, byteLimit)
    bytemove(@yetAnotherTemp,variableName,strsize( variableName )+1)
    variableName := strings.StrRev(@yetAnotherTemp)
  • Mike GreenMike Green Posts: 23,101
    edited 2011-09-28 19:20
    There's not really a place where this is written down other than in the comments of objects like strings. The problem is that we're not talking about a language feature. We're talking about adding features through the use of what are essentially library routines. Those can be written all kinds of ways with all sorts of assumptions. In any event, Spin, like C, doesn't really have any kind of built-in strings. Strings are simply byte arrays. There are no string values. What passes for a string value is just the starting address of a byte array containing the string. The fact that there's a built-in STRING function that allocates storage for a string constant and provides the address of the first byte of the constant just confuses people used to languages with built-in strings. To some extent the same thing is true for floating point. The Spin compiler supports floating point constants and constant expressions, but there's no such thing as a floating point variable and, although you can write floating point constant expressions, you can't do the same thing with a variable in the expression.

    I suspect you've still got a few places where you're still referencing the built-in result buffer in the strings object. Also make sure that all your strings (byte arrays) are long enough to hold whatever you're putting in them and make sure that all string values end with a zero byte. The strings object is supposed to take care of the zero byte, but I haven't looked through your code in detail to make sure it respects that.
Sign In or Register to comment.