Let's Make Robots!

Arduino IDE - what's wrong with versions 0019 onward?

Ever since the release of the new Arduino PCB's there have been at the time I wrote this 4 new versions of the IDE. As far as I can tell none of them work very well. All of my code is written on version 0018 and works fine. Open the same program in later versions such as version 0022 and you get an error when verifying the code.

Here is an example.

Below is what you get when you try to compile the "Wild Thumper Controller" code on the later versions. I have checked that the board type was set correctly as I have been caught before with code written for one board such as the Arduino Mega not compiling when the board type is set to something like Arduino Nano.

In file included from Wild_Thumper_Controller.cpp:8:
C:\arduino-0022\arduino-0022\hardware\arduino\cores\arduino/WProgram.h:52: error: expected unqualified-id before numeric constant
C:\arduino-0022\arduino-0022\hardware\arduino\cores\arduino/WProgram.h:53: error: expected unqualified-id before numeric constant
C:\arduino-0022\arduino-0022\hardware\arduino\cores\arduino/WProgram.h:54: error: expected unqualified-id before numeric constant
C:\arduino-0022\arduino-0022\hardware\arduino\cores\arduino/WProgram.h:55: error: expected unqualified-id before numeric constant
C:\arduino-0022\arduino-0022\hardware\arduino\cores\arduino/WProgram.h:56: error: expected unqualified-id before numeric constant

I have had a number of customers now asking why their robots won't work and all I can do for now is advise them to stick with version 0018. Has anyone else had problems with versions 0019 onward? Did you find a solution other than sticking with version 0018?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I also get errors on my Xubuntu Linux installation. IDE v.18 always worked, but I have a Uno Board so I can't use v.18

But I got Arduino IDE v.21 working on my Vista laptop! So now I have to use Windows :(.


http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1288376213   - for more info on mine problem, paste this in your adressbar

(sorry insert hyperlink function didn't work!)


When (in my line of work) I publish my code (or instructions or whatever) to others AND when I have tested that on a specific platform, I always make sure to list the circumstances under which it works for me. In my case it would the exact versions of operating system and CPU architectures, for example. In your case it would be IDE versions and MCU types.

Not so much a disclaimer or caveat, but a gentle help for the user. That way he knows how to recreate my success and where to start isolating his specific bug. Or he knows which relevant differences to report when asking for my help.

With each newer revision of my work, I usually see the list grow because my colleagues report back to me about their experiences. My version history would read something like "now with fewer IDE dependent bugs!".

Tt seems that Wild_Thumper_Controller.pde is compiled fine with latest Arduino 0022 if you comment out definitions of A1-A5 in the IOpins.h


Ok, sounds like definitions like A1, A2 etc are being used by some new command.

I hate it when they do stuff like this because it makes the code so hard to debug.

I am running 0021.

What I find where you are having the trouble is that it is the #esle for this condition

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)

and defines the constants for A0 to A7.
Are A0 - A7 already defined?


In the Wild Thumper controller the processor is an ATmega168. The board type is an Arduino Nano using the 168.

I only mentioned the Arduino Mega and Nano as an example of one board having different hardware to another and thus causing errors.

In this case the correct board type has been selected


Have you tried other board types? Something that is current and compatible? Even a board type that wouldn't work, just to see if it compiles, so you know if that is the problem.


EDIT - just saw Zupa's reply, which confirms my earlier suspicion - some of the analog pins were already defined.