If I run Particle: Cloud Compile it will return a bin file. I can then use Particle: Cloud Flash to flash the bin file. Am I correct in thinking that the bin file can only be used to flash through the cloud? The bin file cannot be used to local flash?
Particle: Compile application (local) - When this is run I see that a target folder is created which contains the compiled? files of the application and also creates a cpp file based off of the ino file. I’m guessing that the cpp file is created because the ino file isn’t actually used by the controller, the cpp file is instead? When a local flash is done, it is actually using the files in the target folder?
When it comes to local compile and flash options there is application, application & DeviceOS, and application for debug, question is when to use which? I would assume that application for debug would be if one were using a ST-Link or such for debugging whereby the code is compiled in a certain way to allow to allow interaction with the ST-Link. I’m assuming if I compile/flash application it’s doing just that, takes my application, compiles it, flashes to the controller, whatever version of the DeviceOS that is already on the controller isn’t affected? And then compile/flash application & DeviceOS will compile my application and DeviceOS version as called out in the particle.firmwareVersion setting and flash both to the controller?
To compile a project with the cloud takes less time than compiling it locally. When I compiled an empty project in the cloud it took 15 seconds, when I compiled the same project locally it took 50 seconds, does that sound right?
If I run Particle: Cloud Compile it will return a bin file. Am I correct in thinking that the bin file can only be used to flash through the cloud?
No, the .bin file can also be flashed by USB using a command like:
particle flash --usb firmware.bin
Particle: Compile application (local) - When this is run I see that a target folder is created which contains the compiled? files of the application and also creates a cpp file based off of the ino file.
A .cpp file is created from the .ino file because the gcc-arm compiler doesn't understand .ino. The .ino files are just .cpp with #include "Particle.h" secretly included, and forward declarations for functions used later in the file generated for you. There's a preprocessor turn .ino into .cpp.
When a local flash is done, it is actually using the files in the target folder?
Yes.
When it comes to local compile and flash options there is application, application & DeviceOS, and application for debug, question is when to use which
You are correct in your interpretation. Application is the fastest, since it only rebuilds your user code. Application & Device OS assures that your device is in sync with your firmware, upgrading or downgrading the system firmware. Debug is for use with the source level debugger (ST-LINK or Particle Debugger).
To compile a project with the cloud takes less time than compiling it locally. When I compiled an empty project in the cloud it took 15 seconds, when I compiled the same project locally it took 50 seconds, does that sound right?
It depends on many factors, but that is possible. One thing: because of the way the compiler is executed, it's way faster on Mac OS and Linux (what the cloud compile farm uses). Windows is way slower at this time.
The cloud compile and the local compile binaries might not be binary identical, but they’re functionally identical and are interchangeable.
Yes, the user firmware binary is copied into that slot, verbatim.
When you cloud flash, it’s actually copied into the OTA slot, the device rebooted, then when it reboots it discovers there is a binary and swaps the OTA slot into the user firmware binary spot. This is necessary for two reason:
If the transfer is interrupted for any reason, the device will still be usable
The STM32 process does XIP (execute in place). The code runs right out of flash memory, not copied into RAM. Since the user firmware runs during OTA flash, you can’t replace the currently running code.