Publishing particle firmware for others to use

My co-developer and I are getting ready to release an open source Photon-based project to the world. Source code will be on GitHub. Others who wish to use this code will need to get it into their Particle web IDE in order to compile it and flash it to their device. Obviously, they can just copy/paste the code into the web IDE or they can install and use the CLI. However, copy/paste is prone to error and installing the CLI is beyond the capability of most users of the project, who are not expected to be software makers or developers. So question: is there any other way of doing this? Something that a novice who can do no more than then get their Photon captured to their account and use Tinker to control the D7 LED can do? Is their some pubic location to post a full application to that anyone logged into particle build from any account can see? This is not a library; it is a full application.

You could ask the users to give you their access token, you could fetch a list of their devices using that and ask the user to select the one they want to use, which you then flash over the API.

It wont give them the option to change the code inside web ide though.

If you can host a webpage somewhere, you could have a page to which people log in using their own Particle credentials, after which they could select the device to which they’d like to flash said firmware. The ParticleJS library has a way to flash .bin files, which could be used for this purpose.
I’ve got an example of this over here, should you be interested. I’ve disabled the firmware buttons, since they’re outdated, but flashing Tinker should work for your Photons that are online.

Why don’t you make .h and .cpp files that just have some comments in them and provide your code as an example. That way, people can load in the web IDE by using your “library” (which does nothing) and clicking on “Use this Example”.


Thank you all for your ideas. I think that @Moors7 concept of downloading the binary and remotely flashing it using javascript will work best for our project, as the user’s client app is in javascript anyway and the user login to their account is already part of this (so that they can communicate with their photon using our client).

1 Like

Interesting. Does the spark.downloadBinary call take any URL in the first parameter? If so, we could keep the current release binary in GitHub and point the call to that.