This seems strange...

CannibalRobotics

Is this weird or a bad assumption.
I have several veriables defined as BYTEs. in the VAR section. One of them is adjacent a string as follows.

VAR…
…
BYTE Count
BYTE StringName[15]
….

Count goes from 0 to 14 so to save space I dimensioned it as a BYTE.

The string was misbehaving, whenever I wrote something to it then went back to read it I got garbage or nothing. After considerable frustration I fixed the problem by the defining count as a LONG. Apparently when the statement Count :=0 was executed the first byte of StringName became 0 too. Thus reading as an empty string to 0-terminated string operations.

So I pose the question, if you set a BYTE to 0 with code "Count := 0" does it assume 'Count' is an integer and set 4 bytes to 0 starting at the memory address of 'Count'?
Is this true of other integer operators? If I bump a BYTE with ++ is it actually incrementing the LSB BYTE 3 doors down?

Seems odd but I have no other explanation?

John Abshier

This code

CON
        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000

VAR
  byte count
  byte StringName[15]
   
OBJ
  SIO      : "Parallax Serial Terminal"
  
PUB main  | i, j
  SIO.start(115200)
  waitcnt(clkfreq * 2 + cnt)
  bytefill(@StringName, $ff, 15)  ' fill string name
  repeat j from 0 to 4
    count := j
    Sio.dec(count)
    Sio.char(9)
    repeat i from 0 to 14
      Sio.hex(StringName[i],1)
    Sio.char(13)
      

produced this output

0       FFFFFFFFFFFFFFF
1       FFFFFFFFFFFFFFF
2       FFFFFFFFFFFFFFF
3       FFFFFFFFFFFFFFF
4       FFFFFFFFFFFFFFF

You should post your code to let us try to find an error.

John Abshier

Phil Pilgrim (PhiPi)

If the string can have 15 characters, it needs to be dimensioned as 16 to make room for the zero terminator. When you changed Count to be a long, you forced the string to a long boundary, which bought you the extra byte at the end, even though you didn't specify it.

-Phil

Duane Degn

CannibalRobotics wrote: »

Seems odd but I have no other explanation?

I agree with John. You should post your code to see if we can come up with a different explanation.

There are some operations that do strange things if you use a byte instead of a long but setting the variable equal to zero isn't one of them.

If there's a chance the number can be negative, IMO, it's a good idea to use a long. I also use longs for numbers that will have bitwise shifts and rotations.

Some of your post is a bit cryptic. You mention "memory address" but a byte isn't large enough to hold most memory addresses. It could hold the array index number though.

Again, the mystery will probably be resolved with your posting the code.

CannibalRobotics

Posting the code in it's entirety would violate some IP contracts unfortunately.
@Phil, per the length of the string, the count goes from 0 to 14 which would be the 15 slots allocated? This is actually padded by 3 extra bytes just for good measure since I know all of the possible strings content and the longest one, including terminator 0 is 11. Anyway, the problem is at the front end of the string.
The anomoly was also solved by moving the 'BYTE Count' decleration to another position in the line up of the VAR definitions, weird?
@John, I know, it should not have behaved this way and in a vacuum, that piece of code does the same thing on my props. But when changing the type from BYTE to LONG or Moving the BYTE definition stops the changing of adjacent content, makes one go 'hum'. What I posted below is a more accurate representation of the situation.
@Duane, when I used the term 'memory address' I was talking about the physical address of 'Count' not the address in 'Count' - bytes too small for that.
So for now, the behavior is eliminated but the cause is still a bit of a mistery....

Thanks all.

CON
        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000

VAR
  byte count
  byte StringName[15]
   
OBJ
  SIO      : "Parallax Serial Terminal"
  
PUB main  | i, j
  SIO.start(31,30,0,115200)
  waitcnt(clkfreq * 2 + cnt)
  bytefill(@StringName, $A5, 15)  ' fill string name
  count := 0
  repeat 14
    Sio.dec(count++)
    Sio.char(9)
    repeat i from 0 to 14
      Sio.hex(StringName[i],2)
    Sio.char(13)

kuroneko

@CannibalRobotics: That sample looks (and acts) perfectly fine (apart from the start method call). Which basically means your actual problem is somewhere else and I suggest you find and solve it before it does more than just corrupt a string.

Mike G

So I pose the question, if you set a BYTE to 0 with code "Count := 0" does it assume 'Count' is an integer and set 4 bytes to 0 starting at the memory address of 'Count'?
Is this true of other integer operators? If I bump a BYTE with ++ is it actually increment the LSB BYTE 3 doors down?

No, a byte is a byte. Count := 0 sets the byte (pointed to by the label "Count") to zero. However, equating count to another variable like, Count := myResult, sets Count to the LSB of myResult. Variables declared in a method default to a long data type. Local variable not initialized or validated when assigning to a global byte variable can cause unexpected results.

VAR sections are reordered on compile. Long are grouped with longs, bytes with bytes. Changing Count to a long moved the variable in relationship to StringName. I'm sure the bug still exists it's just better masked.

I've had this situation described in post #1. What helped me solve the problem is accepting the horrible truth... I write bugs from time to time.