initial go at flashing unified target with a config #1587

Docteh · 2019-08-19T04:55:14Z

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 of MATEKF411 (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 in defaults and see if the board comes back with a working ACC

show_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

Version and target choice need to show loading when loading.
UI Changes. Need to show an indicator if a user loads a .config locally, and have a way to throw it out.
investigate why data is being saved to the 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)
move the URL for unified configs to a better location.
localization pass (read through code and add strings where appropriate)
Amount of versions to show
Amount of (Legacy) to show

mikeller · 2019-08-19T12:32:45Z

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:

while I appreciate the approach to use the nrf-intel-hex package (I am surprised this comes as web ready), considering that we already have our own implementation of a parser / memory structure, which is tied into the programmer, I think we should go with extending this for now, and not transition in / out of the in-memory representation used by nrf-intel-hex. In the longer term, it would be nice to replace the proprietary implementation entirely with nrf-intel-hex though;
in my opinion, Unified Targets should work transparently to the user - we have done our job right if the user does not notice it when they flash a Unified Target for the first time. As part of this, my idea would be to, instead of having a 'Unified' channel, take the list of supported Unified Targets, and merge it into the list of supported targets, potentially changing the non-unified target of the same name to ' (legacy)' or similar. When being flashed, the target will then grab the required Unified Target .hex from the same firmware channel;
at a later stage, this could be pivoted, and the available targets shown in the top level drop down, and then later on the channels / versions available for the selected target;
n.b. that I am planning to move the Unified Target configurations into a separate repository, with the idea to set up an automated approval process to allow manufacturers to self-manage their Unified Target configurations.

Docteh · 2019-08-20T23:07:03Z

For the config files, I'll move the URL higher in the file. The current 66 files add up to 173,519 bytes. The API call to get a list of stuff in the unified_targets/configs directory is currently 71,431 bytes. The API returns 1000 files at a time. I'm hoping we can have only one version of unified target configurations, but if not we can deal.
I'll stick with my approach for now until I can just use your implementation. Looks like I just need to load the config file into var targetConfig. I tested it with STM32F405 STM32F411 and OMNIBUSF4.

Docteh · 2019-08-21T02:21:45Z

mikeller · 2019-08-21T11:17:44Z

@Docteh: #1585 is merged now, you can rebase and use the ConfigInserter.

Docteh · 2019-08-22T22:49:36Z

Do we want to do anything here? I'm already hiding the unified options when there is no STM32F411 build (3.3 maintenance)

Docteh · 2019-08-24T01:06:23Z

We might want to translate the (Legacy) part.

McGiverGim · 2019-08-24T06:57:39Z

We might want to translate the (Legacy) part

For sure...

Docteh · 2019-08-24T19:43:00Z

Another question, should all the old style ones be labeled Legacy, or just the ones where we have a unified target? In this screenshot we only have a config for MATEKF411.

Or do we want this second choice?

mikeller · 2019-08-24T23:07:58Z

@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.
For now we'll need to keep the 'legacy' targets around to give users a way to access older versions of the firmware, but I think we should consider pivoting the order of the drop downs, so that users first select the target, and then select what channel they want, which will allow us to go back to only showing one entry per target.

P.S.: I like 'ye olde', we should keep it. 😀

mikeller

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.