Closed knowledgejunkie closed 5 years ago
carlosperate
commented
5 years ago Have I missed something important as to why the string version of the firmware is necessary?
I can't say with certainty, but I always though that the main reason was portability of the module, as this way is easy to move around and integrate in other projects.
ntoll
commented
5 years ago What @carlosperate says is exactly the reason. It's a single file which can be moved around.
If there is a firmware update then the version number of uflash is also incremented.
knowledgejunkie
commented
5 years ago @carlosperate @ntoll Thank you both for the confirmation.
The MicroPython firmware will be packaged for Debian separately* to the uflash module/utility, which means locally patching uflash to use the "default-on-Debian" firmware file when called without reference to another firmware image. The _RUNTIME string will be removed with awk/sed.
knowledgejunkie
commented
5 years ago Close this as the packaging of uflash for Debian is now in the Debian NEW queue, pending FTP Master review.
Whilst packaging uflash and the MicroPython firmware, I've been wondering whether there would be a (significant) performance penalty during flashing if the firmware was always read from the local hex file (and the firmware string dropped from the uflash.py file)?
In selfish terms of downstream packaging of uflash, having only one copy of the firmware - in a separate file - would make managing firmware updates very straightforward. In Debian we'd use the Debian-built version of the firmware. Keeping the duplicate copy as an embedded string in the source code not only doubles the size of the package but also creates extra work "injecting" the locally-built firmware back into the source code after each update.
Is performance known to be okay reading the firmware hex in from the local file? Have I missed something important as to why the string version of the firmware is necessary?