How do I tell the compiler to stop messing with my variables?

I have a routine that draws pixels of variable colours on a 320X240 TFT SPI LCD. The library is ILI9341_due.

The original routine worked exactly as programmed though, because the logic didn't test the if the pixels had already been drawn, there was a lot of unintended overwriting of pixels.

The routine decided the co-ordinates of each pixel through complex decision making but (apart from the overwriting) the routine worked perfectly.

The routine decided where to draw each pixel and drew it, perfectly.

I decided to "readPixel" at the co-ordinate (x,y) to check the pixel was "empty" before I drew each pixel (to (x,y)) and the routine just stopped working altogether.

On debugging I found out the compiler inserted code that reset the values of integers "x" & "y" to their values at the "setup" stage.

I set "x = 319" and "y = 0" then manipulate x & y to be equal, for instance, to 310 & 9.

If I drawPixel at x & y it goes into (310,9) correctly.

If I, however, readPixel(x,y) first the "read" is correct but the compiler resets x & y back to their initial values of 319 & 0 and the following drawPixel goes into (319,0).

I declared x & y as volatile but that didn't change the compiler action, it still reset them to their initial values.

How do I tell the compiler to stop messing with my variables and leave them at the value they were recomputed to?

I have spent hours on this code but can't effect what the compiler does.

I have spent hours on this code

But couldn't be bothered spending a few seconds posting it.

How do I tell the compiler to stop messing with my variables and leave them at the value they were recomputed to?

Write your code properly!

louwin:
On debugging I found out the compiler inserted code that reset the values of integers "x" & "y" to their values at the "setup" stage.

Very very very unlikely for the compiler doing this. You have one or more bugs in your code. Maybe your Arduino is being reset. Maybe you are overwriting the variables by writing beyond the end of an array. Maybe you have run out of RAM. There are a million things I would suspect before blaming the compiler.

louwin:
On debugging I found out the compiler inserted code that reset the values of integers "x" & "y" to their values at the "setup" stage.

My wild guess is that you have local and global variables with the same name.

...R

Robin2:
My wild guess is that you have local and global variables with the same name.

...R

+1

Just quickly while I analyze all the magnificent replies.

(stowite) It is on a Due and I am using 9% of the program area (512K) and probably almost nothing of the 96K of RAM.... :smiley:

Here is the routine.... :smiley:

  tft.fillScreen(BLACK);//Clear for checking
  r = g = 0; b = 1;
  count=0;
  volatile int rx=0, ry=0, rz=0, gx=319, gy=0, gz=0, bx=0, by=239, bz=0, ox=319, oy=239, oz=0;
  volatile int rc=0, gc=0, bc=0, oc=0;//counts 10416 43184 10416 1519 = 65535
  while(!(r==0 && g==0 && b==0)) {//LOTS of overwriting at the corners!!!!
    if(r>g && r>b) {//primarily RED?  Top RHS
      while(tft.readPixel(rx,ry)) {//Check destination before putting....
        if(rx--<0) {rz++; rx=rz; ry=0;} else ry++;
      }
      tft.drawPixel(rx,ry,nextcolour()); rc++;
    } else {
      if(g>b && g>r) {//primarily GREEN?  Top RHS
        while(tft.readPixel(gx,gy)) {//Check destination before putting....
          if(gy--<0) {
            gz++; gy=gz; gx=319;
          } else gx--;
        }
        tft.drawPixel(gx,gy,nextcolour()); gc++;
      } else {
        if(b>r && b>g) {//primarily Blue  Bottom LHS
          while(tft.readPixel(bx,by)) {//Check destination before putting....
            if(bx--<0) {bz++; bx=bz; by=239;} else by--;
          }
          tft.drawPixel(bx,by,nextcolour()); bc++;
          if(bx--<0) {bz++; bx=bz; by=239;} else by--;
        } else {//Mixture   Bottom RHS All RGBs of equal value?
          while(tft.readPixel(ox,oy)) {//Check destination before putting....
            if(ox++>319) {oz++; ox=319-oz; oy=239;} else oy--;
          }
          tft.drawPixel(ox,oy,nextcolour()); oc++;
        }
      }
    }
  }
  delay(1000);

The reason I didn't post the code is because it is quite involved and the product of a BASIC programmer (rofl)

(Robin2) As far as I can see rx, ry, rz, gx,gy,gz,bx,by,bz,ox,oy and oz are ONLY defined in the routine :smiley:

I also forgot to mention, my debugging confirmed my claim that the compiler was reseting the "x" & "y" values. That is the beauty of playing with a 320X240 LCD, you can send debug displays to it :smiley:

I "printf" the changing values of bx, by, r, g and b when I stepped through the code with and without the readPixel "call". Without the readPixel routine x & y displayed what they should have been with the readPixel "call" they just displayed 319,0 :frowning:

I hoped the "volatile" would have fixed it but it didn't :frowning:

  volatile int rx=0, ry=0, rz=0, gx=319, gy=0, gz=0, bx=0, by=239, bz=0, ox=319, oy=239, oz=0;
  volatile int rc=0, gc=0, bc=0, oc=0;//counts 10416 43184 10416 1519 = 65535

I was going to ask why these are volatile, but

I hoped the "volatile" would have fixed it but it didn't

Wishful thinking rarely does. You should now go research WHY you would use volatile.

And then post ALL of your code.

I have already researched "volatile", it is to do with Interupt service routines. I didn't just a throw it in. The operative word is routines.... I hoped it would preserve variable values when a routine "calls" another routine.

My debugging shows x and y computed correctly before the call to readPixel and gets reset after the call. Hence I concluded the compiler included code that reset X and y on return from readPixel.

The whole sketch is 2000 lines long.

This routine is self contained. It only calls nextcolour which just "bumps" rgb.

Before you ask why a 2000 line sketch only uses 9% I'll say I use a debug statement to ONLY compile THIS routine and nextcolour.

And yes, I HAVE written a working ISR in another sketch. I'm a newbie to C++ but have been a programmer for 40 years.

If you read up on "volatile" you will see the suggestion that the compiler does do funny things with variables under some conditions. I suspect calling two different routines with shared arguments could confuse the compiler.

The operative word is routines.... I hoped it would preserve variable values when a routine "calls" another routine.

That is NOT what volatile does. What it does is tell the compiler that the value can change at any time, so the compiler can not cache the value. It must fetch the data every time.

My debugging shows x and y computed correctly before the call to readPixel and gets reset after the call. Hence I concluded the compiler included code that reset X and y on return from readPixel.

Well, that's one conclusion.

The whole sketch is 2000 lines long.

Will it be any shorter when you get around to posting it?

I suspect calling two different routines with shared arguments could confuse the compiler.

Not at all.

It may be difficult to help you for the reason(s) indicated by a checked box (x) below:

() You posted without reading any threads, including the first one, "How to use this forum - please read".
() You posted a program without reading the second thread, "Read this before posting a programming question".
() You have not clearly stated the problem that you are actually experiencing.
() You haven't said what hardware your program is using.
() Instead of your complete code, you have only provided snippets of code for analysis, thus creating a Mensa puzzle.
() Your question has nothing whatsoever to do with the forum subject category.
() Your technical writing style is almost unintelligible (even though English is your native language).
(
) You obviously don't believe in reading standard manuals or online reference materials that have the answer to your question.
() You are presenting the work of others as if it is your own.
() You insist that you have a hardware problem when it is obviously a software problem.
() You insist that you have a software problem when it is obviously a hardware problem.
() Your very first program is 7,532 lines long and you just tested it for the first time because you continually massaged it to compile correctly.
() Your 7,532 line program is full of undocumented magic numbers like 0x48383838929 and mysterious variables like lx, _foo89, and puppyChow.
(
) The control flow of your program would make Mr. Spock cry.
() You believe that the computer should understand what you meant, not what you wrote.
(
) You are blaming the problems that you caused on the IDE/compiler/C++ standard/etc.
() You are trying to get other people to write your program for you for free.
() You are trying to learn to program by trial and error.
() You need to learn to program without asking for help every 2 minutes.
(
) You ask for help, but don't process the replies mentally.
(*) You ask for help, but then act defensive or smug when the advice that is given contradicts your beliefs.
() You believe that pleading, begging or whining will motivate people to help you.
() After way too many helpful replies, you still don't get it.

Self evaluation:
1-3 check marks: Noob
4-8 check marks: Will never learn
9+ check marks: Toronto Maple Leafs fan

(*) Your 7,532 line program is full of undocumented magic numbers like 0x48383838929 and mysterious variables like lx, _foo89, and puppyChow.

I must have missed the puppyChow variable... 8)

but have been a programmer for 40 years.

And yet you write stuff like if(ox++>319) {oz++; ox=319-oz; oy=239;} else oy--;

@aarg: my new favourite post. :smiley:

I'm sorry....

Would

if(ox++>319)
{
oz++;
ox=319-oz;
oy=239;
}
else
{
oy--;
}

Work any better?

It wouldn't work any better or any worse, but it would be easier to read.
It would also help if you'd posted it inside code tags, so we could be sure the forum software hadn't mangled it.

louwin:
I'm sorry....

Would

if(ox++>319)
{
oz++;
ox=319-oz;
oy=239;
}
else
{
oy--;
}

Work any better?

Ox is a large draft animal, oy is a Yiddish expression and oz is a place where Dorothy went. Use understandable variable names.

"bx" is the x coordinate of "blue" colour. "rx" red x coordinate. "oy" = other colour y coordinate. "gx" green x coordinate. "z" is a series of pointers for red, green, blue and other colour.

The names are completely meaningful to ME! The r is the R of RGB, same for the g and b....

The sketch is for ME so the names have to be meaningful only to ME. I never expect to release the code so it only has to be meaningful to me. It's recreation not work.

When I am finished I'll back it up and probably never look at it again.

Please stop faulting my technique, my formatting etc and just answer my query. Please.

and just answer my query

Which was, IIRC, why doesn't the code I didn't post doesn't work properly. Well, who the fuck knows. Or cares, anymore.

louwin:
The whole sketch is 2000 lines long.

See if you can write a 50 line program that demonstrates the same problem.

If you can't demonstrate the problem in a short program then the length of the program may be part of the problem.

If my first idea of duplicate local and global variables was wrong my next wild guess would be memory corruption - perhaps writing past the end of an array or using Strings (capital S).

louwin:
The sketch is for ME so the names have to be meaningful only to ME.

But you are asking US for advice.

...R

Please stop faulting my technique, my formatting etc and just answer my query. Please.

Please stop jerking us around and post the code, as you have been repeatedly asked.
Please.

We can't since the question does not make sense. The whole job of the compiler is to mess with your variables. The only time it resets variables to zero on its own is at the start of the program.