- FirmwareVersion = "arbitrary string that changes every single time it's built differently"
- InterfaceVersion ="family / code name string + space + numeric version"
- FirmwareName = "arbitrary string that never changes for a single firmware" (for FreeEMS releases from me, it'll always be "FreeEMS Official" or vanilla or pure or certified or similar)
- FirmwareVersion = "arbitrary string that changes every single time it's built differently"
- InterfaceVersion ="numeric version of form N.N.N etc with at least one N and number of dots = number of Ns minus one"
- FirmwareName = "arbitrary string that never changes for a single firmware" (for FreeEMS releases from me, it'll always be "FreeEMS Official" or vanilla or pure or certified or similar)
- FirmwareVersion = "arbitrary string that changes every single time it's built differently" (this lets us track bugs to specific code versions and is expected to change often without necessarily changing the config of api versions)
- CommAPIVersion = "numeric version same as above but related to the serial functions and their formats" (this tells us how data and functionality access in the device is implemented and when changed requires a code change in the tuning software to match it
- ConfigFormatVersion ="numeric version of form N.N.N etc with at least one N and number of dots = number of Ns minus one" (this tells us about what data is available and in which locations which functions are.)
- Check the FirmwareName and if unknown, refuse to function, if known, but not supported, say so, or if supported, continue.
- Given a known and supported FirmwareName:
- Check the CommAPIVersion and if unknown, refuse to function, if known, but not supported, say so, or if supported, continue.
- Given a known and supported CommAPIVersion:
- Check the ConfigFormatVersion and if we give the different parts special meaning, proceed with caution, proceed advised against, or refuse to proceed on the basis of likely corruption.
For the config format version we could do the same thing, ie, micro/patch/incremental version changes mean addition of new data in a previously unused place and/or removal of usage of data such that bogus data in those locations does not affect existing functionality as it would if moved there. Thus micro version changes could be supported by external tools with no change. Minor version changes denote non backward compatible changes that require redoing the mappings from data to functionality to avoid corruption of configuration possibly leading to engine damage.
Note, we'll need these anyway because it's unreasonable to assume that a tuner will definitely be able to pull config from the device and indeed to assume that the firmware will have the config in it, imagine cut down versions running on smaller less capable chips such as my incomplete FreeMS2 fork.
The name is simple, either you know about it or not, and support some of it or not. Easy.
The firmware version is just an identifier, it can't and shouldn't be used to distinguish anything of interest except for which firmware has which bug in it.
Fred.