Here it is boiled down to two lines, but this same behavior takes place in the (larger) original code which does compile when ZH is renamed ZHE;
compiling:
#define ZH 168
byte x = ZH;
results in this error message:
sketch_oct12a:2: error: 'r31' was not declared in this scope
But compiling:
#define ZHE 168
byte x = ZHE;
does not.
Yes, ZH is defined in common.h, an include file that's part of the AVR-LIBC libraries. It represents register R31 in the AVR architecture (when writing AVR assembly).
You can either "#undef ZH" before your code or just work around it.
--
The Gadget Shield: accelerometer, RGB LED, IR transmit/receive, light sensor, potentiometers, pushbuttons
Here it is boiled down to two lines, but this same behavior takes place in the (larger) original code which does compile when ZH is renamed ZHE;
galanter:
While RuggedCircuits is likely correct (I'm going to take his word for it), there's a greater question that should be addressed:
What does "ZH" (or "ZHE") stand for?
This isn't a trivial question. When writing code, the code should be as self-documenting as possible. When self-documentation isn't possible, then comments should be added to the code to accurately describe what is happening in the code.
For instance, which is easier to understand (trivial example, I know) - this code:
#define VMA 1000
#define VAC 100
int f;
void setup() {
f = VMA * VAC;
}
void loop() {
}
...or this code:
// Trivial program to calculate the force on a vehicle given mass and acceleration (f=ma)
#define VEHICLE_MASS 1000
#define VEHICLE_ACCELERATION 100
int force;
void setup() {
// calculate the force (f=ma)
force = VEHICLE_MASS * VEHICLE_ACCELERATION;
}
void loop() {
// code intentionally omitted
}
???
While the above is a trivial example, you can easily see how properly defining your constants and your variables, along with proper commenting, can assist you (and other programmers - including your future self two years later when you want to update the code) in understanding the functionality of the code.
Also, by giving descriptive names, you will generally avoid clobbering on other code (especially "system" code - which tends to use very abbreviated naming conventions for various things).
Maybe I need to write a tutorial about all of this (though I am sure someone already has - I hope)...
RuggedCircuits, I thought it looked like it might be a register reference of some kind but didn't know where it might be. Is there a way to turn on more detailed error messages that might have made this clearer? I miss being able to get tables of which function calls which, where variables are typed, etc.
cr0sh, I understand the sentiment but it doesn't apply here so much. The value of ZH is a byte code for a phoneme used by a speech chip. There are 70+ of them defined and documented in my code like so:
#define IY 128 // See, Even, Feed 70 Voiced Long Vowel
#define IH 129 // Sit, Fix, Pin 70 Voiced Short Vowel
#define EY 130 // Hair, Gate, Beige 70 Voiced Long Vowel
These two (or four) letter mnemonics are used throughout the chip documentation so I'd rather not rename them.
Phil " I've been programming since 1972 
" Galanter
RuggedCircuits, I thought it looked like it might be a register reference of some kind but didn't know where it might be. Is there a way to turn on more detailed error messages that might have made this clearer?
Unfortunately, no. That is one of the criticisms of the C language use of the preprocessor -- things are hidden and you have to dig to find out what's really going on. The preprocessor usage is deprecated and unnecessary in C++, and doesn't even exist in Java.
You could compile the code outside the Arduino environment and use the -E flag of the avr-gcc compiler to just get the output of the preprocessor, then dig into that and see where ZH is originally defined, but that's a fair bit of work.
--
The Quick Shield: breakout all 28 pins to quick-connect terminals
Use an enum or const int instead. That's what they were invented for they will get rid of your problem immediately.
Korman
cr0sh, I understand the sentiment but it doesn't apply here so much. The value of ZH is a byte code for a phoneme used by a speech chip. There are 70+ of them defined and documented in my code like so:
My appologies then. In that case (and the fact that you are documenting via comments) - such short declarations make sense (although prefixing with a "PH_" or similar would help you get around conflict issue - though if it is just the single phoneme bytecode causing issues, tacking an extra character on is likely better).
If you looked at your initial post - you might understand why I called this out; your post looks real similar to a "newbie" question; not a lot of detail, no insights as to what the code is for, no comments on the code, etc - plus your low number of comments seemed to indicate to me "newbie" - which is why I posted what I did.
While it may not apply to this situation - it is good form to practice in general.
You posted a "boiled down" version of your code to get to heart of the problem; I understand that now - but at the time, I thought maybe your code was filled with stuff like that, which is a common newbie mistake, thus my comments.
My appologies again - I see you've been programming longer than I've been alive, so I will defer to your experience!