-
-
Notifications
You must be signed in to change notification settings - Fork 898
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
initial go at flashing unified target with a config #1587
Conversation
Nice job @Docteh! And even though we doubled up I think we both solved different parts of the problem, so we can probably combine our solutions. My thoughts:
|
|
e5caa49
to
71baec0
Compare
We might want to translate the (Legacy) part. |
For sure... |
@Docteh: The idea is to only mark the non-unified targets for which there is a Unified Target as legacy - for the rest, the non-unified target is still current. P.S.: I like 'ye olde', we should keep it. 😀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is starting to look real good - the usability is getting to the point where the user won't notice.
Some points:
- I think we should be removing the target name from the 'Select firmware' drop-down entries. They did not add much in the past, and now with Unified Targets they are only adding confusion, if anything:
- we need to add a minimum version check, and display available firmware versions for Unified Targets only if they are 4.1.0 or better - currently flashing a pre-4.1.0 build with a Unified Target will happily flash the Unified Target only, sans configuration, which I don't think is something we want:
- tying into the above, we should probably also fail instead of flashing if we try to insert the configuration, and find that the loaded .hex does not support custom defaults.
src/js/tabs/firmware_flasher.js
Outdated
var unifiedConfig; // Unified target configuration loaded from the menu, used when throwing out a local config | ||
|
||
// Is there a list of these elsewhere?, used in parseUnifiedBuilds and ... look for unifiedTargets[0] | ||
var unifiedTargets = [ 'STM32F411', 'STM32F405', 'STM32F745', 'STM32F7X2' ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure we even need a list of Unified Targets worst case we load a non-unified target, discover from the .hex that it does not support custom defaults, then fail.
src/js/tabs/firmware_flasher.js
Outdated
return targetConfig; | ||
} | ||
var unifiedSource = 'https://api.github.com/repos/betaflight/unified-targets/contents/configs'; | ||
//unifiedSource = 'https://api.github.com/repos/betaflight/betaflight/contents/unified_targets/configs'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove commented out code, or add a comment indicating the reason it is left in.
src/js/tabs/firmware_flasher.js
Outdated
@@ -288,7 +370,7 @@ TABS.firmware_flasher.initialize = function (callback) { | |||
|
|||
var expertMode_e = $('.tab-firmware_flasher input.expert_mode'); | |||
expertMode_e.prop('checked', globalExpertMode_e.is(':checked')); | |||
$('input.show_development_releases').change(showOrHideBuildTypes).change(); | |||
$('input.show_development_releases').change(showOrHideBuildTypes); //.change(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll make a note to check, I either broke the relevant toggle, or I didn't.
src/js/tabs/firmware_flasher.js
Outdated
chrome.storage.local.get(storageTag, function (result) { | ||
let storageObj = result[storageTag]; | ||
let bareBoard = null; | ||
//bareBoard = 'STM32F405'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commented out code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job is being done here. I want something usable to give a real start to the unified targets.
I have commented about some spaces missing in the older code, but now that you have moved it, maybe we can fix it.
src/js/tabs/firmware_flasher.js
Outdated
return; | ||
} | ||
var date = new Date(release.published_at); | ||
var formattedDate = ("0" + date.getDate()).slice(-2) + "-" + ("0"+(date.getMonth()+1)).slice(-2) + "-" + date.getFullYear() + " " + ("0" + date.getHours()).slice(-2) + ":" + ("0" + date.getMinutes()).slice(-2); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, this is an old code, but if you can add spaces around +
operator the code left will be better than the original.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wow that is horrible looking code
81ab4aa
to
659db25
Compare
659db25
to
0c4e53e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to move along with this - this is now ready to go in.
One more thing we need to do is prevent flashing of Unified Targets with configurations earlier than 4.1.0, as these targets do not support custom defaults.
Ok, we can merge this and add the remainings things at a later PR. We must start with something :) |
Hi, sounds good to me. |
This adds a method to flash firmware and preload a unified target configuration directly from internet resources.
This builds on #1585 Applying the configuration automatically will be handled later.
In the above screencut MATEKF411 will use flash with the STM32F411 target and have the
MATEKF411.config
attached. selection ofMATEKF411 (Legacy)
will use the MATEKF411 target.To test this PR look at this list of configuration files, and pick one of them. After flashing take a look at
defaults show
or just punch indefaults
and see if the board comes back with a working ACCshow_development_releases
selected_build_type
are left in config.storage.local as there is some execution order issue that results in the builds list being downloaded twice on the tab load. Any change to those would need to be tested on both ChromeAPP and NWJS builds.Doubling up on lines like this is a giveaway:
Using cached release information for firmware releases.
Using cached release information for firmware releases.
Todo
options
in the version<select>
field with jQuery. I might have to eat my words but it seems like a dumb idea. Get:.data('summary')
Set:.data('summary', object)