mjhjmtu

I'm new to Arduino and embedded, but understand that it is often better to use global instead of local variables (such as here or here).

I have this simple code (from here):

//Libraries
#include <DHT.h>;

//Constants
#define DHTPIN 2 // what pin we're connected to
#define DHTTYPE DHT22 // DHT 22 (AM2302)
DHT dht(DHTPIN, DHTTYPE); //// Initialize DHT sensor for normal 16mhz Arduino


//Variables
float hum; //Stores humidity value
float temp; //Stores temperature value

void setup()

 Serial.begin(9600);
 dht.begin();



void loop()

 //Read data and store it to variables hum and temp
 hum = dht.readHumidity();
 temp= dht.readTemperature();
 //Print temp and humidity values to serial monitor
 Serial.print("Humidity: ");
 Serial.print(hum);
 Serial.print(" %, Temp: ");
 Serial.print(temp);
 Serial.println(" Celsius");
 delay(2000); //Delay 2 sec.

My ancient C programmer training (Unix servers) says I must move variables hum and temp to loop(), or is it better on Arduino to leave them as globals?

No. If you have the choice, locals are usually better, because they
minimize the risk of name collision, and they help make the program
clearer by keeping the variable definition close to the place where it
is used. In your example, hum and temp should be locals, as there is
no good reason to make them globals.

However, sometimes you don't have the choice. If a variable is used in
both setup() and loop(), then it needs to be global. This is the
case of dht in your example.

Sometimes a variable is used in many functions. Even if you can make it
local, by passing it around through function parameters, doing so
doesn't make the program more readable. In that case you may also prefer
to keep it global.

Sometimes a variable that is used in only one function needs to be
statically allocated in order to preserve its value across calls to the
function. In this case the variable could be a static local. However,
since the static keyword is somewhat obscure for beginner programmers,
Arduino tutorials tend to use globals whenever static storage is needed.
You are not required to follow this practice, although you may want to
if you are writing for an audience of novices.

In any case, the take away of your first two links is not that you
should prefer globals: it's that sometimes there is a good reason for
making a variable global, and that's fine.

The general rule of good practice is to minimize the scope of a variable to necessary minimum. Write the code to be readable and maintainable, don't do premature optimization.

The variables hum and temp should be defined only in loop(). The compiler can optimize it by putting them to global space or using MCU registers only, to avoid repeated creation on stack.

Not an answer, but I thought some of you may be interested in the C coding standards of some projects in the 1990s (based on the EDS standards, if I remember correctly).

A summary of the rules is:

• No goto


• No global variables


• All functions (including main) to return an integer which is either SUCCESS or FAILURE


• All variables declared at start of function


• All variables declared on a separate line


• No "in-line" initialising of variables


• All variables initialised, usually to zero, including mallocs


• No in-line if's


• Probably more things that I can't remember

An example program:

#include <stdio.h>
#include <stdlib.h>

#define SUCCESS 0
#define FAILURE !SUCCESS

int log_error(char *msg) 
 int rv;

 rv = SUCCESS;

 fprintf(stderr, "%sn", msg);

 return(rv);


int function2(void) 
 int rv;

 rv = SUCCESS;

 return(rv);


int function1(void) 
 int rv;
 int i;
 char *mem;

 rv = FAILURE;
 i = 0;
 mem = 0;

 if(NULL == (mem = malloc(400))) 
 log_error("Malloc error");
 else 
 for(i=0; i<400; i++) 
 mem[i] = 0;
 
 if(SUCCESS != (rv = function2())) 
 log_error("function2");
 else 
 rv = SUCCESS;
 free(mem);
 
 
 return(rv);


int main(int argc, char **argv) 
 int rv;

 rv = FAILURE;

 if(SUCCESS != (rv = function1())) 
 log_error("function1 error");
 

 return(rv);

Bit different to the way K&R wrote UNIX, and perhaps not too relevant to embedded? I'm not sure which I prefer, I guess both styles have their place depending on the makeup of a team :)