This is hopefully a welcome change for those developing sophisticated classes and libraries using the multi-file feature in the build site. The compiler should no longer pre-process files in your project except the main source file. This means if you’re using Spark functions in the .h and .cpp files you’ve added, make sure you include application.h
Just a reminder: When you are changing and recompiling your applications on the web IDE to pull in the latest enhancements rolled out for the core-firmware, remember to add this include to your libraries
After your WebIDE and Firmware update… I wasn’t able to reupload my program to core. It said something related to String object that it couldn’t understand. Then I added #include “application.h” everywhere I could… and compilation worked.
But After I upload my program to device… the sparkcore blinks purple and everything… green… connecting blah balh… then Main LED goes OFF… and Pin7 blue led turns On… and stays like that. Reseting doesn’t work… (even cutting energy and back on stays the same) so I have to Factory reset everytime
I have tried other simple programs and they works just fine… its my program that its making the spark core die like that. This didn’t happened before your last IDE and firmware update.
It does always... as I said, I tried a simple program.. and ir works just fine, and stays connected with dimming blue and all that.. but with my program.. which it was working fine before... it just drops dead, and I have to factory reset every time.
So the modified library im trying to make it compatible with SparkCore:
main spark core file is in /examples
modified libraries WiGPS.h and .cpp, I change everything to Serial1 instead of SoftwareSerial.
GPRMC.h and .cpp I didn’t touch anything except adding the application.h
WiGPS.cpp was actually retrieving data from GPS before.
It looks like you’re initializing the gps object outside of the setup function, which I think can cause problems on the core at the moment. If you modify your WiGPS constructor to be more like
WiGPS::WiGPS(int pw){
/*
* Creates a new SoftwareSerial port
* in the memory HEAP and assign a pointer
* to the serialPort member, then call the
* softwareserial constructor.
*/
//Port serial = new SoftwareSerial(rx,tx);
dataReady = FALSE;
return;
}
WiGPS::init(pw) {
Serial1.begin(9600);//serialPort->begin(9600);
powerPort = pw;
pinMode(pw, OUTPUT);
digitalWrite(powerPort, LOW);
}
and add that to your class, and modify setup to include:
void setup() {
gps.init();
}
it might help – since then Serial1, and your pinMode’s would get set inside the setup function. We have a bug logged for this, since it works on Arduino, and doesn’t work yet on the core. This is because your code is running alongside the core code, instead of being sandboxed, or running entirely on its own.
Hmm, good questions, I’m a fan of smart suggestions when detecting errors, but it gets tricky to detect all edge cases to be sure.
1.) Application.h will get added automatically if you’re coding in an ‘.ino’ file and it’s getting pre-processed. We could also just simply prefix every new file with #include "application.h" but that might get overzealous. We could just inject a “did you want to include … etc” alongside errors returned when compiling a “.cpp” file, but it might get frustrating if it wasn’t the proper fix.
2.) We’re intending to add tagging to cached builds like this, so we don’t have to advertise the “modify and rebuild” step, I agree that’s confusing right now, and making it harder for people to get the latest updates. I’m also tempted to just nuke the cache when we do a firmware push, which would also force the code to recompile.