Keep in mind that with C/C++ the initialization order for global space variables is undefined. This includes constructor execution of global class instances. I can’t say if this is related to your problem but it is an important consideration. Be careful of interdependencies.
and that now compiles, no issues there, but the solution to my problem is still elusive:
const int myPin = A4; // i am guessing that the compiler is smart enough to demote the int to uint16_t??
Fade led1(myPin, 5);// faderPin speed 5 ms/ step
unsigned long startMillis;
pinMode(myPin, OUTPUT); //<<<<<<<<<<<< comment this out and it doesn't output
led1.write(255); //fade to max
if (millis() - startMillis > 5000UL)
toggle = !toggle;
led1.write(toggle? 255 : 0);
Serial.println(toggle? "up" : "down");
startMillis = millis();
so there are monsters out there… is there a way to avoid the issue of the initialization order? I’m not sure that I could categorize what I am attempting to do in the constructor as creating an interdependency. Is there some kind of compiler directive I can add to push the treatment of my constructor to the end of the line?
Like @mdma mentioned, I have a workaround and that is simply setting the pinMode in setup() so for now I’m fine.
On the Core this is definitely the case since the system and application are combined into one C++ module - initialization order between the system and application code can bite can cause unexpected bugs.
On the Photon this isn’t the case - the system globals are guaranteed to be fully initialized before the application globals are initialized since they are separate, dynamically loaded modules.
Thanks @mdma I suspected that with the Photon they would be separate. One must still be aware that within the process the ordering is not guaranteed. The OP showed an int initialization followed by a class instance initialization that depended on the int going first. While it may work (and probably will work) there are no guarantees.