Discussion on managing firmware upgrades from desktop application
Added by J. Simmons almost 10 years ago
So, one of the big new developments is a companion desktop application to manage configuration in the Holoseat controller (walking trigger speed, key to press for walking). It simplifies the electronics and makes the Holoseat more flexible in terms of games support. It also enables us to consider automatic firmware updates for the controller. This thread is to capture/hash out how to implement firmware upgrades. Here are the initial concepts Bryan and I have been discussing.
Where to pull firmware from¶
- SVN Repo tags by version (contains all versions, would need to select correct one)
- SVN Repo releases directory (may contain multiple versions, but only if required to support older gen hardware)
- DMSF file download (new idea, not sure how it would be structured)
Determining hardware, software, and firmware compatibility¶
For everything to work, the hardware, software (so we can control configuration, partly done through compiling the firmware), and the firmware need to be compatible versions (though not necessarily the same version). Here are some initial ideas about how to identify versions for the various elements.
- Hardware
- ???
- Software
- Hard coded into the software (a constant in the source code)
- Firmware
- Declared in the common header used to control configuration
- Declared in a separate version.h
- Declared in both (config version and firmware version) so we can compare the two version numbers before flashing the firmware with an incompatible configuration
We also need to discuss how to identify when various versions are compatible with each other (that is the Desktop application will generate a compatible header file for the current firmware, or the firmware will work with the sensors on the Holoseat).
- Tag all three elements with a major.minor.patch release number scheme and enforce compatibility at the major version level (all 1.x.x elements will be compatible, otherwise we rev up the major version number on an element)
Finally, how will we know what version firmware we are downloading and that it matches the current hardware and software.
- Inspect tag or other SVN description before downloading
- Download firmware to separate directory from compiler working directory and inspect version info before moving it to working directory
Replies (1)
RE: Discussion on managing firmware upgrades from desktop application - Added by Bryan Christian over 9 years ago
SVN makes more sense to me, but that's because I've already integrated an SVN library and managed to get a connection. I just need to work on getting it to handle check-out correctly.
I'm thinking the versioning ends up like this:
Major.minor.rev
Major always breaks and requires reinstall and may break hardware compatability. Might need to include a hardware compatibility flag for once we get the hardware versioned.
Minor means the headers are no longer compatible. This requires update to the desktop application itself. Not sure how we handle this one. Perhaps have the application check SVN for an update to itself then launch a desktop updater app that will pull it down the new desktop app and launch the installer.
Revision means just a firmware update. No real issues here.
I'm thinking we need to do some sort of circuit we can poll and get a static value off of for determining hardware version. Something adjustable by something as simple as swapping out a resistor if possible.
(1-1/1)