Code That Won’t Compile

Your code might fail to compile when you click on the Verify (checkbox) button or the Upload button (see Chapter 1). This is indicated by red error messages in the black console area at the bottom of the Arduino software window and a yellow highlight in the code if there is a specific point where the compilation failed. Often the problem in the code is in the line immediately before the highlighted line. The error messages in the console window are generated by the command-line programs used to compile and link the code (see Recipe 17.1 for details on the build process). This message may be difficult to understand when you first start.

One of the most common errors made by people new to Arduino programming is omission of the semicolon at the end of a line. This can produce various different error messages, depending on the next line. For example, this code fragment:

void loop()
{
  digitalWrite(ledPin, HIGH)    // <- BUG: missing semicolon
  delay(1000);
}

produces the following error message:

  In function 'void loop()':
  error: expected ';' before 'delay

A less obvious error message is:

expected ',' or ';' before 'void'

Although the cause is similar, a missing semicolon after a constant results in the preceding error message, as in this fragment:

const int ledPin =  LED_BUILTIN    // <- BUG: missing semicolon after constant
void loop()

The combination of the error message and the line highlighting provides a good starting point for closer examination of the area where the error has occurred.

Another common error is misspelled words, resulting in the words not being recognized. This includes incorrect capitalization—LedPin is different from ledPin. This fragment:

const int ledPin =  LED_BUILTIN;

digitalWrite(LedPin, HIGH);   // <- BUG: the capitalization is different

results in the following error message:

  note: suggested alternative: 'ledPin':
  error: 'LedPin' was not declared in this scope

The fix is to use exactly the same spelling and capitalization as the variable declaration, as the suggestion indicates.

You must use the correct number and type of parameters for function calls (see Recipe 2.10). The following fragment:

digitalWrite(ledPin);   // <- BUG: this is missing the second parameter

generates this error message:

 error: too few arguments to function 'void digitalWrite(uint8_t, uint8_t)'
 error: at this point in file

The cursor in the IDE will point to the line in the sketch that contains the error.

Functions in sketches that are missing the return type will generate an error. This fragment:

loop()               // <- BUG: loop is missing the return type
{
}

produces this error:

 expected constructor, destructor, or type conversion before ';' token

The error is fixed by adding the missing return type:

void loop()               // <- return type precedes function name
{
}

Incorrectly formed comments, such as this fragment that is missing the second “/”:

digitalWrite(ledPin, HIGH);   / set the LED on (BUG: missing //)

result in this error:

 error: expected primary-expression before '/' token

It is good to work on a small area of code, and regularly verify/compile to check the code. You don’t need to upload to check that the sketch compiles (just click Verify button in the IDE). The earlier you become aware of a problem, the easier it is to fix it, and the less impact it will have on other code. It is much easier to fix code that has one problem than it is to fix a large section of code that has multiple errors in it.

Code That Compiles but Does Not Work as Expected

There is always a feeling of accomplishment when you get your sketch to compile without errors, but correct syntax does not mean the code will do what you expect.

This is usually a subtler problem to isolate. You are now in a world where software and hardware are interacting. It is important to try to separate problems in hardware from those in software. Carefully check the hardware (see Appendix E) to make sure it is working correctly.

If you are sure the hardware is wired and working correctly, the first step in debugging your sketch is to carefully read through your code to review the logic you used. Pausing to think carefully about what you have written is usually a faster and more productive way to fix problems than diving in and adding debugging code. It can be difficult to see faulty reasoning in code you have just written. Walking away from the computer not only helps prevent repetitive strain injury, but it also refreshes your troubleshooting abilities. On your return, you will be looking at the code afresh, and it is very common for the cause of the error to jump out at you where you could not see it before.

If this does not work, move on to the next technique: use the Serial Monitor to watch how the values in your sketch are changed when the program runs and whether conditional sections of code run. Chapter 4 explains how to use Arduino serial print statements to display values on your computer.

To troubleshoot, you need to find out what is actually happening when the code runs. Serial.print() lines in your sketch can display what part of the code is running and the values of your variables. These statements are temporary, so you should remove them once you have fixed your problem. The following sketch reads an analog value and is based on the Solution from Recipe 5.6. The sketch should change the blink rate based on the setting of a variable resistor (see the Discussion for Recipe 5.6 for more details on how this works). If the sketch does not function as expected, you can see if the software is working correctly by using a serial.print() statement to display the value read from the analog pin:

const int potPin = A0;
const int ledPin = LED_BUILTIN;
int val = 0;

void setup()
{
  Serial.begin(9600);       // <- add this to initialize Serial
  pinMode(ledPin, OUTPUT);
}

void loop() {
  val = analogRead(potPin);    // read the voltage on the pot
  Serial.println(val);         // <- add this to display the reading
  digitalWrite(ledPin, HIGH);
  delay(val);
  digitalWrite(ledPin, LOW);
  delay(val);
}

If the value displayed on the Serial Monitor does not vary from 0 to 1023 when the pot (variable resistor) is changed, you probably have a hardware problem—the pot may be faulty or not wired correctly. If the value does change but the LED does not blink, the LED may not be wired correctly.