Good questions — this is tricky stuff to get right.
The user firmware module binary includes an indication of which version of system firmware it depends on. If you type “s” over serial in listening mode you’ll get some cryptic JSON output describing the currently installed modules.
We’re working on automatic dependency resolution in the cloud right now. Within the next two weeks, we will deploy cloud changes that will send a sequence of OTA flashes of the system modules required by a user module automatically when dependencies are unmet. This will happen, for example, when you OTA flash a user app that depends on system modules version 3 if your device currently has system modules version 2.
Additionally, our compile service will, in about 2 weeks, be able to build against a variety of user-selectable platforms. This includes the Photon/P0, the Core, and the P1 of course, but it can also include other custom builds, even possibly from different repos. Exactly how we’ll roll this out or price it is still to be determined, but we are pushing hard on these features at the moment. Many cool things to come.
As you head into production, we can definitely provide what you need to keep your changes on your products, but you should continue to stay in close touch with @jonlogan.
One other thing to be aware of: you can build with
MODULAR=n in order to have one giant, monolithic binary instead of the separate user and system firmware modules. This means each OTA always contains all your changes, but it also makes the OTA flashes take a loooong time, minimum about 90 seconds instead of 2 seconds for just the user module.
Running monolithic firmware can get an OTA of monolithic firmware or an OTA of modular firmware concatenated together into a monolithic file to make the switch to modular. Modular firmware, however, can only get an OTA of modular firmware — you can’t go back to monolithic. If you want to go the monolithic route, you’ll need to stay monolithic until you’re ready to switch to modular permanently.
All of the above is a good set of reasons to get the changes into user code only without having to modify the system firmware. If you can make a pull request to the firmware repo of a generally usable feature for listening mode timeouts, e.g., as an additional argument to
WiFi.listen() that would not only make your life easier but would help the whole Particle community as well.
Lots of info. Hope it’s not too much. Keep asking questions. Cheers!