They aren't evil per se, but they do tend to get overused where there is no good reason to use them.
There are plenty of times when global variables are advantageous. Especially since programming an Arduino is, under the hood, vastly different to programming a PC.
The biggest benefit to global variables is static allocation. Especially with large and ...
It's important to note that const int does not behave identically in C and in C++, so in fact several of the objections against it that have been alluded to in the original question and in Peter Bloomfields's extensive answer are not valid:
In C++, const int constants are compile time values and can be used to set array limits, as case labels, etc.
It's very difficult to give a definitive answer without seeing your
Global variables are not evil, and they often make sense in an embedded
environment where you typically do a lot of hardware access. You have
only four UARTS, only one I2C port, etc. So it makes sense to use
globals for variables tied to specific hardware resources. And indeed,
EDIT: microtherion gives an excellent answer which corrects some of my points here, particularly about memory usage.
As you've identified, there are certain situations where you're forced to use a #define, because the compiler won't allow a const variable. Similarly, in some situations you're forced to use variables, such as when you need an array of values ...
The main issue with global variables is code maintenance. When reading a line of code, it is easy to find declaration of variables passed as parameter or declared locally. It is not so easy to find declaration of global variables (often it requires and IDE).
When you have many global variables (40 is already a lot), it becomes difficult to have an explicit ...
Although I wouldn't use them when programming for a PC, for the Arduino they have some benefits. Most if it has already been said:
No dynamic memory usage (creating gaps in the limited heap space of an Arduino)
Available everywhere, thus no need to pass them as arguments (which costs stack space)
Also, in some cases, especially performance-wise it can be ...
As with everything (other than gotos which are truly evil) globals have their place.
e.g. If you have a debug serial port or a log file that you need be to able to write to from everywhere then it often makes sense to make it global. Similarly if you have some critical piece of system status information then making it global is often the easiest solution. ...
It is not clear, what the code actually should do (what behaviour you are trying to achieve), so I will only look into the obvious programming problems.
The following declarations at the global scope seem to be pin numbers:
int x = 45;
int y = 47;
int z = 41;
int w = 43;
int WaterIn = 40;
int WaterOut = 42;
int Pump1 = 25;
int Pump2 = 24;
int Pump3 = 27;...
It depends on the application. For something like a rechargeable torch, Arduino might exceed the specifications. For a weapons system, NEVER (and this is one of the specific prohibitions in the license agreement - see section 1.5 note: link currently broken). You also have to consider that there's literally thousands of armies in the world and they all have ...
Are they evil? Maybe. The problem with globals is that they may be accessed and modified at any point in time by any function or piece of code being executed, without restrictions. This may lead to situations that are, let's say, difficult to trace back and explain. Minimizing the amount of globals, if possible bringing the amount back to zero, is therefore ...
Global variables are never evil. A general rule against them is just a crutch to let you survive long enough to gain the experience to make better decisions.
What a global variable is, is an inherent assumption that there is only one of a thing (it doesn't matter if we're talking about a global array or map that might contain multiple things, that still ...
I'd throw that code away and start over from scratch; it's overly verbose and needlessly repetitious, which may account for the kinds of errors you are seeing.
A few notes:
• The contents of num_array_1 look identical to those of num_array_2. Ordinarily there is no need to have two copies of the same constant array, so get rid of one or the other.
• It ...
You can, but you don't have to.
Should you? That's up to you.
I do. That's because it's then simple to add another case at the end of the structure in the future if you want, and you don't have to remember to add the break to the existing last case.
As pointed out by Majenko in a comment, you can hardly define a standard
facility for error reporting when you don't know what kind of I/O
hardware will be available on any particular project. Printing to the
serial port is the most common method though, as it tends to always be
available during the development phase, while the Arduino is tethered to
chrisl made an excellent analysis of your program and the problems
therein. I would just want to add a point about how to handle the
Calendar() function. You have been given the suggestion to look at the
Blink Without Delay Arduino tutorial, and I second that suggestion.
This is indeed the first thing you should do.
However, once you have studied that ...
I would add to Chrisl's answer by saying that, if you wanted to make the code more compact, you could represent the 4 boolean variables by a single byte,
e.g. w HIGH + x HIGH + y LOW + z LOW = 1100.
e.g. w HIGH + x HIGH + y LOW + z HIGH = 1101.
Then it would be easier to implement a switch statement instead of if( digitalRead(x) == HIGH && ...
The first thing I noticed was that you had a capital I in your if-statement.
Secondly, button_state =(HIGH) should be button_state == HIGH. A single = sign means that you are assigning a value to the variable on the left - in this case button_state. It is a common mistake that I have made many times.
Also, because it is a boolean comparison, you can ...
You have two declarations of button_state. This won't cause a problem because the scoping rules will mean inside loop you are using the local one and everywhere else you are using the global one. Personally I would remove the global one since you aren't using it.
As mentioned in the comments you have mistyped the If keyword (but I think this is just on ...
OK, notwithstanding Majenko's excellent suggestion in the comments above, I played around with Arduino and GPS, so I can probably offer a few pointers.
All the GPS modules that I have played with give out a series of standard strings of information or "sentences". These sentences are defined by the National Marine Electronics Association (NMEA) ...
The SD card uses the SPI interface.
You can search on amazon/aliexpress/ebay or some electronic shop for an adapter, either to wire or to mount as shield.
The answer would have been one google search away.
Your question is broad. My first reaction is to say No. But in order to be very accurate (or fair), your should find the application standard. Military has an extensive library of standards ranging from manufacturing and testing. Therefore, take a look at the standard regulating your application. Only after this assessment, the question of whether Arduino ...
Your counter variables only have scope within the methods they are declared in. So initializing them in the setup() method will have no effect in other methods.
Instead, declare these variables as global or at least with "file" scope as you did with your array variables.
So far you have asked a lot of questions about your project which uses SoftwareSerial to send a lot of bits:
How to transmit more than 1 byte continually?
Basic Serial Transmission Protocol
Synchronization and Implementing hamming code on Software Serial
Encoding clock signal into linear block codes
How to fix baud rate when hardware capacity has a low ...
Yes you treat them the same, they are the same pins.
It looks like (in the photo) you're connecting a bluetooth module.
Be careful when uploading your sketch. If you connect something to TX/RX (pins 0 & 1) it may be necessary to disconnect it for arduino-uploading to work.
You may find it a more convenient solution to declare a SoftwareSerial on ...
For variables of a specified type which are not altered during execution, either can usually be used.
For Digital pin numbers contained in variables, either can work - such as:
const int ledPin = 13;
But there is one circumstance where I always use #define
It is to define analog pin numbers, since they are alphanumeric.
Sure, you can hard-code the pin ...