All global variables are initialised* before
setup() is entered.
(And more specifically, before
main() is entered.)
Consequently, at this point
arduboy.begin() won’t have been called, hence none of the IO peripherals will have been initialised (the screen, the speaker and so forth) and the intro animation will not have played, among other factors.
(For more specific details, read the documentation and/or source code for
arduboy.initRandomSeed() will not have been called so the pseudo random number generator will not have been initiated and any calls to
rand() will produce a predictable value.
(*Being pedantic: declaration is merely a compile-time concept, initialisation is the action that may have a runtime impact, though how much of an impact if any will depend on the details of the expression used to initialise the variable.)
Perhaps, but not necessarily.
It depends on the details of the expression used to initialise the variable.
The compiler has a lot of freedom to reorganise and eliminate assignments if it can prove that a variable’s value has not been read before a particular assignment.
Whilst that is less likely in a larger program targetting a desktop environment, on an embedded system the compiler has more freedom to optimise because it can know the whole extent of the program without having to concern itself with extreneous factors like other threads.
That said, initialising a global at the point of declaration is probably more likely to result in less code and is certainly the more readable approach as pairing the initialisation with the declaration makes the code easier to reason about.
As mentioned before, initialising globals at the point of declaration is better mainly for reasons of readability.
Any memory savings from using one approach over the other would probably be small enough to be negligable until the point the program is actually struggling for progmem.
I should probably mention that you can in fact circumvent
loop() and write a
main() function as you normally would in C++.
Arduino already defines a
main() that calls
but it uses a compiler extension to make the definition ‘weak’ so that it may be replaced in user code by an alternative implementation.
If you were to attempt this, you should first examine and understand how Arduino already defines
main() and be sure that you aren’t removing anything important:
(Also note that the
main function must have no parameters.)