Firmware update tool [CPP-724]

[samvrlewis]

Still a WIP but opening now in case anyone has feedback on the overall design. This turned out to be a bit of a bigger refactor than I was hoping, but I think it has made it a bit cleaner. I've tested it in the CLI and in the console over TCP and updates still work but the extent of the change probably necessitates properly rerunning the UAT for updates. 😬

The ugliest thing about this at the moment is that there isn't really any nice way to show proper progress. We can get a nice progress bar from the FileIO upload of the binary, but all progress post that comes from MsgLogs from the device. This is true in the console itself too, but IMO looks dodgier when run on the CLI. At the moment I'm just printing everything to the console so it looks like this:

$ swift-update-tool ~/Downloads/PiksiMulti-INTERNAL-v3.0.2.bin --tcp 192.168.22.100:55555
> Reading firmware file from path, /home/sam/Downloads/PiksiMulti-INTERNAL-v3.0.2.bin.
> Transferring image to device...
> 
[00:00:45] [===================>] 99/100% (1s remaining)
> Image transfer complete.
> Committing image to flash...
> installing to region B
> erasing mtd3 0x000c0000 - 0x00100000...
> 0 % complete
> ok
> erasing mtd4 0x000c0000 - 0x00100000...
> 0 % complete
> 100 % complete
> erasing mtd7 0x00000000 - 0x01c00000...
> 0 % complete
> 0 % complete
> 1 % complete
(etc)

But I was thinking maybe it would be nice if we could keep some sort of rolling buffer of the last 5-10 log messages so that users can still see that progress is happening without having all the logs spewed out at them. I don't think parsing the logs is worth the headache - each flash partition gets its own progress and the output format looks like its changed slightly between v2.4 and v3.0 on the Piksi.

Still todo:

• General tidy up
• Better CLI help/arguments (believe Rai/apps are going to send requests through for this)
• CI building of the new binary
• Cleaning up the update progress bar/log (and maybe thinking of some nice way to show updates)
• Convert the current update unit tests to work post refactoring (I think this will likely be failing the build for the moment)

[john-michaelburke]

I think the Apps team would want to weigh in on the choice to drop the current "no newline". As far as I can tell it looks like the thing that looks the worst is the "complete %" message so maybe we could reduce the logic to just occur on this message? Here is an example of what it looks like:

[john-michaelburke]

Looks good to me this was a much needed refactor! Tested it out on usb connection and the update worked well.

[samvrlewis]

I think the Apps team would want to weigh in on the choice to drop the current "no newline". As far as I can tell it looks like the thing that looks the worst is the "complete %" message so maybe we could reduce the logic to just occur on this message?

Good idea, I've done this now - probably the best of both worlds! Only downside is I guess it's a little brittle on the format of those log messages. But probably unlikely that they'll change on Piksi (and worst case, if they do, it'll just spew out all the messages for a slightly worse UX):

[silverjam]

looks great, a few comments and suggestions

[samvrlewis]

Ended up removing the progress bar as it was probably a bit weird that there was a progress bar for the upload but not for each of the writes that the Piksi spits out percentage done messages. The end result looks like this now, which is still a little janky but at least gives the user an idea of progress:

firmware_update.mp4

[samvrlewis]

Have incorporated @RaiBearG's CLI help/args feedback now, so I think this should be good to go once the CI all passes. 🎉