Build IDE - .cpp files no longer pre-processed!

1

Hey Guys!

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

#include "application.h"

Thanks!
David

9 Likes
2

This topic is now pinned. It will appear at the top of its category until it is either unpinned by a moderator, or the Clear Pin button is pressed.

4

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 :wink:

5

This topic is now pinned. It will appear at the top of its category until it is either unpinned by a moderator, or the Clear Pin button is pressed.

6

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.

7

Hmm. Does it do this everytime you flash that firmware over the air, or is it just sometimes?

8

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.

9

Ahh, okay, sorry, I see that now.

Any chance you can share your code somewhere? Maybe we can help spot what’s causing the problem?

10

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.

11

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.

Thanks!
David

2 Likes
12

Thanks @Dave , that fixed the issue. Now I can continue to debug gps signals.

1 Like
13

@dave, @zachary

There seems to be 2 issues that are creating bad user experiences and “negative drag” on the community with repetitive posts in multiple threads.

On a build would it be difficult to grep the source and give an error message ‘Missing #include “application.h”’?

Also if the libs or some repo or build artifact is/are newer then the file(s) in the webIDE why not just rebuild on the request to flash?

Am I missing something or would it make good sense do this sort of preemptive fixing?

1 Like
14

Hi @david_s5 ,

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.

Thanks,
David