Web IDE vs MS Code

Hello. I’m still getting oriented with the Particle tools. I was hoping for some direction on the best ways to standardize a workflow for Particle.

The main question is whether I should be using the web IDE or the MS Code / Particle Workbench IDE. Which is the “correct” way? I have struggled to get used to MS Code. I have many years experience working in MPLABX for Microchip PIC code and a bit of experience w/ Atmel Studio.

This MS code thing is all new - it appears Particle is a plugin to MS code?

Here are some points on my average project:

  1. I will often bring in straight .c and .h code, as I already have a ton of code written in C for PIC. My first realization upon installing MS Code is that it doesn’t let me just add .c and .h files to the project. It won’t compile them. (Not sure exactly what went wrong, just that it didn’t work). I was eventually able to get it to compile by changing the .c to .cpp and left the .h as it was.

So right now I have projects with file names with .cpp and .h. I don’t think that is correct, but it is compiling, loading, and working right now, though I still can’t use global variables defined on my attached code pages - any global vars need to be defined in my main .ino file for some reason to work.

Normally in MPLABX I just #include “extra_code_header_file.h” on each page of the code that needs those functions or global variables. I haven’t been able to get any of the Particle tools to do this yet.

  1. I haven’t done remote firmware update yet, but I will eventually be using Particle for regular updates to firmware on gateway Argon/Boron devices and Xenon mesh endpoints. I’m not sure how either IDE is tied to the update process, if one is better than the other, or if the web IDE is better for a fleet of live devices and the desktop IDE is intended just for development. So far I am just uploading code via USB cable from MS Code.

  2. I’m usually doing projects for clients, so whatever I write will be handed off to someone else at some point. I like the web IDE for this, but not if the web IDE will introduce other limitations in the future. I can always just send them a zipped up copy of the program folder from MS Code. The clients are generally non-code people - I tend to show them in person how to open files and upload things. If they have to install MS Code and set up and configure a toolchain just to get code on a device, then using a web link may be a lot easier.

Can the web IDE upload code via USB to a local device? I tried using the web IDE one time trying to upgrade the version of DeviceOS on a Boron. I followed the instructions and started the upload, but I think it went over cellular which didn’t make sense since it was connected via USB. It took about 20 minutes of of the Boron rebooting on its own, but eventually it shows the new firmware version.

Does the web IDE only update code over the air? That doesn’t seem usable for development.

I appreciate any thoughts or feedback.


Yes, there’s just a plug-in that enables Particle support in VSCode. While we have an all-in-one installer (Particle Workbench), you can just take a standard VSCode and add in the VSIX manually if you really wanted to.

There are two compiler options for VSCode: cloud compile and native gcc-arm compile. The cloud compiler does not support .c files, but you can rename them to .cpp and they will work properly. (You may need to add some extern “C” declarations in some rare cases.)

The Web IDE only flashes over-the-air, even when the device is connected by USB. It dates back to Wi-Fi devices when this was not as much of an issue. You can download the .bin files from the Web IDE and flash them over USB as a two-step process to save on data.

Using the particle CLI can also save on data. Doing a Device OS upgrade using particle update over USB is significantly faster and uses almost no data. Installing Particle Workbench using the installer also installs the Particle CLI.

The Particle CLI can also do cloud compile and flash over USB, which is handy if you want to use a different editor than VS Code.


The best option I’ve found for larger projects is Particle Workbench. Once things are set up, I use “Particle: Flash application (local).” This is pretty quick as it uses a local compiler to build and flashes locally. This most resembles the tool flow in tools like MPLABX.

The fact that Particle tools separate the application and DeviceOS makes it quick to iterate on application development as it only has to build and flash a small amount of the overall device.

Occasionally, if things don’t work, I’ll “Clean application & Device OS (local)”, and then “Flash application & DeviceOS (local)”.

I do most debugging with print statements, so I use the particle CLI and run the following command in a terminal window.

particle serial monitor --follow

This will automatically connect to an attached particle device and display serial console output. It looks like there is also a workbench command: “Particle: Serial Monitor”.

For more complex projects, I find a serial console/print statements more effective than a more traditional breakpoints/single-stepping debugger for debugging as they allow me to observe program behavior over time, timing, etc.

Thank you @rickkas7 and @cbrake that is helpful.

I haven’t figured out how to trigger a remote update / over the air update from Particle Workbench in the VSCode, and I need to figure out how to manage multiple projects at once. As it is, I can only open one project in VSCode (I think they call it a “folder”).

Often in my board layout software and MPLABX I have several projects down the side bar where I pick from bits of code in the other projects. I haven’t been able to replicate this with VSCode.

I guess you are looking for something called multi-root workspaces

e.g. here "Projects" and "Multi-root Workspaces" Strategy

@m_m would be the prime addressee for things related to Particle Workbench.

Yes, VS code has the concept of multi-root workspaces, so you can have multiple projects in the left-hand navigation, by opening a directory higher than the one your project is contained in. The downside is that it’s then ambiguous as to what you want to build, so whenever you use a compile or flash operation you’re asked which project you want to build.

For your specific use case, what I like to do is open two separate VS Code windows using the New Window option in the File menu. You open the project you are actively working on in one window as a single root workspace. You do your builds from that window. You then open all of your source in the second window as a multi-root workspace. This allows you to search and peruse all of the source easily in a single navigation.