Prevent issues with corrupted firmware using outdated configurator

[haslinghuis]

• Configurator should not be able to connect to newer unsupported firmware versions, i.e. 10.10 should not be able to connect to 1.47 firmware. We cannot change earlier versions of configurators as I think we should start doing it now.
• Configurator 10.10 should be compatible with firmware 4.0 - 4.5 so there is no reason to use an older configurator besides firmware 3.x users.
• Main problem is users just ignore the dialog and don't know what is wrong.
• This PR does not allow 10.10 to work with 4.7 and so on.
• Please ignore version number here - as this is the original dialog:

BEFORE:

NOW:

[ctzsnooze]

The message seems confusing. Where it says "please upgrade the configurator to version nnnn", shouldn't that version be a configurator version?

And the user indicated firmware version should be a 'user friendly' text like
'4.5'?

Perhaps this should just be a warning, not a block on progressing further?

[HThuren]

I suggest this only act in non expert mode, since experts likely know what to do with different versions.

[ASDosjani]

I suggest this only act in non expert mode, since experts likely know what to do with different versions.

I disagree as everyone ticks expert mode even if they don't know what it does.

[sugaarK]

Maybe we change the message to be a bit more aggressive? No please etc.. warning in capitalised red. Red things they seem to notice a bit better. Personally I’m in favour of blocking unsupported versions. When we go to 5.0 I think also we end the backwards compatibly. All the configurator team quip about how much easier it would be if we did this

[HThuren]

But remember to have a chance not stuck in deadend, ie firmware / configurator version combination where not able to make backup and/or not able to upgrade firmware.
Maybe in expertmode or something
...just saying :-)

[HThuren]

I suggest this only act in non expert mode, since experts likely know what to do with different versions.

I disagree as everyone ticks expert mode even if they don't know what it does.

yes, you have a point

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[github-actions]

Do you want to test this code? Here you have an automated build:
Betaflight-Configurator-Android
Betaflight-Configurator-Linux
Betaflight-Configurator-macOS
Betaflight-Configurator-Windows
WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!

[nerdCopter]

min & max MSP gating maybe. (emuflight/EmuConfigurator#383)

but this PR works too. will test soonish.

[nerdCopter]

it is based upon MSP (not version).
tested with version change only, then both. it only triggered due to MSP bump.

$ git diff
diff --git a/src/main/build/version.h b/src/main/build/version.h
index d1ff1cc54..bd42d3e81 100644
--- a/src/main/build/version.h
+++ b/src/main/build/version.h
@@ -25,7 +25,7 @@
 #define FC_FIRMWARE_NAME            "Betaflight"
 #define FC_FIRMWARE_IDENTIFIER      "BTFL"
 #define FC_VERSION_MAJOR            4  // increment when a major release is made (big new feature, etc)
-#define FC_VERSION_MINOR            5  // increment when a minor release is made (small new feature, change etc)
+#define FC_VERSION_MINOR            6  // increment when a minor release is made (small new feature, change etc)
 #define FC_VERSION_PATCH_LEVEL      0  // increment when a bug is fixed
 
 #define FC_VERSION_STRING STR(FC_VERSION_MAJOR) "." STR(FC_VERSION_MINOR) "." STR(FC_VERSION_PATCH_LEVEL)
diff --git a/src/main/msp/msp_protocol.h b/src/main/msp/msp_protocol.h
index c776ce3db..36a629641 100644
--- a/src/main/msp/msp_protocol.h
+++ b/src/main/msp/msp_protocol.h
@@ -62,7 +62,7 @@
 #define MSP_PROTOCOL_VERSION                0
 
 #define API_VERSION_MAJOR                   1  // increment when major changes are made
-#define API_VERSION_MINOR                   46 // increment after a release, to set the version for all changes to go into the following release (if no changes to MSP are made between the releases, this can be reverted before the release)
+#define API_VERSION_MINOR                   47 // increment after a release, to set the version for all changes to go into the following release (if no changes to MSP are made between the releases, this can be reverted before the release)
 
 #define API_VERSION_LENGTH                  2
 
## master...origin/master

results:

[nerdCopter]

also note that it required acc calib on first flash (not a second or third)

[HThuren]

@haslinghuis I can approve, if I'm allowed

[sugaarK]

@haslinghuis I can approve, if I'm allowed

if you deem It solid then go for it

[HThuren]

Seems stable, and I tried some combinations of 'bad' versions.