When does -1 != -1 ?

If I run the code as is, the led is on. If I add a Serial.begin(), it stays off. Not helpful!

dxw00d: If I run the code as is, the led is on. If I add a Serial.begin(), it stays off. Not helpful!

Indeed. Same behavior here.

#define TEST_VALUE -1
int foo = TEST_VALUE;

void setup(void)
{
    pinMode(13, OUTPUT);
    digitalWrite(13, LOW);
    if (foo != TEST_VALUE) digitalWrite(13, HIGH);
}

void loop(void)
{
}

has the light end up on, I was making sure it wasn't a left over on state some how from something before.

#define TEST_VALUE -1
int foo = TEST_VALUE;

void setup(void)
{
    pinMode(13, OUTPUT);

}

void loop(void)
{
   digitalWrite(13, LOW);
   if (foo != TEST_VALUE) digitalWrite(13, HIGH);

   while( true) {};
  
}

light is on again (seeing if it has to do with being in loop vs. start up)

#define TEST_VALUE -1
int foo = TEST_VALUE;

void setup(void)
{
    pinMode(13, OUTPUT);
    Serial.begin(9600);
}

void loop(void)
{
   digitalWrite(13, LOW);
   if (foo != TEST_VALUE) digitalWrite(13, HIGH);

   while( true) {
     Serial.print(TEST_VALUE);
     Serial.print('\t');
     Serial.print(foo);
     Serial.print('\n');
     delay(100);
   };
  
}

light is off, serial monitor shows "-1 -1"

commenting out the code inside the while loop still has light off commenting out the serial.begin line also causes light to be on.

Attached output from: avr-objdump -d -S foobar.cpp.elf >objdump.txt

If those are not the correct options, please advise.

objdump.txt (18.4 KB)

@lefty, I'm not familiar with the diode trick.

It's a sometime problem caused by the auto-reset function where a positive voltage spike on the reset pin seems to put the AVR in a 'stalled condition". The Uno on some later release added a pull-down resistor to the DTR signal and made the problem more possible with that board. So just stick any old diode in the reset pin and +5vdc pin with cathode on the +5vdc pin. May not be the problem, but the results of this symptom is so bizzare and unreproducible at times, it's worth a quick test before burning up too many brain cells.

Lefty

May not be the problem

It's not because the behavior is repeatable when you just press the reset button, so it is not the reset latch up problem.

Easy enough to test the diode thing. Tried a 1N4148 on both the real Uno and on the breadboarded ATmega328P. No difference with either.

#define TEST_VALUE -1
int foo = TEST_VALUE;

void setup(void)
{
    pinMode(13, OUTPUT);
    if (foo != TEST_VALUE) digitalWrite(13, HIGH);
}

void loop(void)
{
}

and

int foo = -1;

void setup(void)
{
    pinMode(13, OUTPUT);
    if (foo != -1) digitalWrite(13, HIGH);
}

void loop(void)
{
}

both turn the LED on for my uno but not on my duemilanove.

Can you add a Serial.begin() and then do the avr-dump again. Then we can see if there is a difference.

Can you compare the ELF files for the Uno and the Duemilanove? What happens if the flashed CPUs are switched? Will the error move with the CPU or will it stick to the board?

Will the error move with the CPU or will it stick to the board?

Why do you think it will stay with the board? It will go with the processor because that is what is doing the processing.

If I change the -1 to -2, then the LED stays off. I compared the avr-objdump output from the two and only found the following, which is about what I’d expect. Scary.

Compare: (<)C:\Documents and Settings\Jack\Desktop\objdump-2.txt (18814 bytes)
   with: (>)C:\Documents and Settings\Jack\Desktop\objdump-1.txt (18814 bytes)

134c134
<  112:	8e 5f       	subi	r24, 0xFE	; 254
---
>  112:	8f 5f       	subi	r24, 0xFF	; 255

objdump.txt (18.4 KB)

objdump-2.txt (18.4 KB)

Attached is avr-objdump output with Serial.begin added as follows. Edit: The code generated by the if statement appears the same, except for different addresses, which would be expected.

#define TEST_VALUE -1
int foo = TEST_VALUE;

void setup(void)
{
    Serial.begin(9600);
    pinMode(13, OUTPUT);
    if (foo != TEST_VALUE) digitalWrite(13, HIGH);
}

void loop(void)
{
}

objdump-serial.txt (39.3 KB)

That seems reasonable. It is loading a pair of registers with the contents of foo, then subtracting TEST_VALUE (in two operations), which is either 0xFFFF, or 0xFFFE for -1 or -2, then doing a branch if equal to zero.

So the if translates to exactly the same instructions after adding the Serial.begin(), but the results differ. Weird.

dxw00d: So the if translates to exactly the same instructions after adding the Serial.begin(), but the results differ. Weird.

Yeah, that's the way I read it too. I'm running out of ideas.

[quote author=Jack Christensen link=topic=84243.msg631285#msg631285 date=1324578950]

dxw00d: So the if translates to exactly the same instructions after adding the Serial.begin(), but the results differ. Weird.

Yeah, that's the way I read it too. I'm running out of ideas. [/quote]

Do you own a diode. ;)

If it had something to do with the diode, or lack thereof, why would the change of TEST_VALUE from -1 to -2 make a difference?

retrolefty: Do you own a diode. ;)

LOL, yes, several hundred I believe. Didn't make any difference. Posted that earlier, look up a few posts... XD

WizenedEE: both turn the LED on for my uno but not on my duemilanove.

Got me to thinking. Loaded the sketch with ICSP, LED stays off. Burned the ATmegaBOOT_168_atmega328.hex bootloader (Arduino Duemilanove or Nano w/ ATmega328) and loaded the sketch with the bootloader, LED stays off.

Something funny with Optiboot?