The numeric processor somewhere in the PICC / XC8 compiler toolchain produces different values to the preprocessor. This means that a defined value can be e.g. 7 as far as the preprocessor is concerned, and 0 (zero) from the compiler/assembler's point of view.
The PICC assembler is known to be weak in regards to evaluating numeric expressions, as it pays no heed to operator precedence.
**broken link removed** I'm not sure if this has been fixed in subsequent releases, but when I raised a support ticket with HiTech in 2005, they weren't concerned that the assembler wasn't correct, and that the C preprocessor should be used to do any calculations of compile-time constants (which of course isn't possible).
The following code snippet should not compile if
MIN_MISSED_PULSES != 7, yet it does, and it compares the variable
missedPulseCount against 0 rather than 7.
Code:
while(1)
{
missedPulseCount++;
#if MIN_MISSED_PULSES != 7
#error Preprocessor broken
#endif
if(missedPulseCount == MIN_MISSED_PULSES)
{
missedPulseCount--; // value of missedPulseCount is zero, when it should be 7
missedPulse = 1;
}
}
From a few quick tests, it appears that the preprocessor uses a different precision variable to evaluate expressions than the compiler/assembler.
The attached code illustrates the bug. The variable on line 29 will have a value of 0, when it should be 7. Uncommenting line 11 and commenting line 12 will provide correct program function.
The preprocessor also cannot handle expressions containing floating-point numbers, which is pretty lame, although not a bug.