Local vs Cloud Compile Differences and/or Bad Coding Practice

There are differences between the local compiler and cloud compiler during runtime.
In my main.ino file:

void DoSomething();
static void DoSomethingElse();
void DoSomething()
{
    DoSomethingElse();
}

static void DoSomethingElse()
{
}

and in an extra.h file I have a reference/declaration of the DoSomething() function like this:

extern void DoSomething();

If I compile locally, when extra.h calls DoSomething(), it runs like normal and DoSomethingElse() is called by DoSomething().

If I compile via the cloud, when extra.h calls DoSomething() all is well until it tries to call DoSomethingElse() at which point the device freezes.

And another thing, if DoSomething() tries to call a function withing extra.h (when DoSomething() is called from extra.h) it also freezes if compiled via the cloud, but runs fine if compiled locally.

Is this bad coding practice and why?
And also, why is the cloud compiler compiling differently to the local compiler?

Note: removing “static” doesn’t fix the issue.

1 Like

The most common reason something compiles differently in Workbench local compile vs. cloud compile has to do with modified local libraries. If you modify the source in lib, the modified version is used locally, but if you build in the cloud, the official version is used, unless you remove the library from project.properties.

If you are comparing Workbench local vs. CLI compile, the most common reason is target differences. In Workbench, the target version of Device OS is specified by Particle: Configure Project for Device. For CLI, it’s the latest LTS version (currently 2.2.0) unless you use the --target <version> command option.

The difference is similar for Web IDE, except the version is specified by clicking on Devices (target icon), selecting the device, then the target version from the popup.

The reason the target Device OS version matters is that different versions of Device OS use different versions of the gcc-arm compiler, and these can cause differences. There also might be differences in warning levels. For example, in Device OS 3.1 and later, the warning level is increased to error on a missing return value, which can cause a SOS+1 hard fault. This uses to be just a warning, and warnings are not always displayed for cloud compiles.

As for your specific situation, it’s hard to tell from that bit of code. Can you distill the problem into actual compilable code that demonstrates the problem?

1 Like

Thanks for the quick response. I figured out the problem late yesterday. I was calling a function from an object/class, in an interrupt called by that object. Still a mystery why it worked if i compiled locally but not if i compiled via cloud. I would’ve assumed it would break no matter how it was compiled. Problem is fixed now though, I had to change the way the code worked a bit.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.