MK3S 3.9.0 compiled firmware does not match Prusa release
 

MK3S 3.9.0 compiled firmware does not match Prusa release  

  RSS
ANTALIFE
(@antalife)
Eminent Member

As title says, compiled firmware from 3.9.0 git branch (MK3_3.9.0) does not match Prusa release

 

I tried compiling on Windows 10 but had issues like other people. So I installed Fedora 5.7.14-200 on my laptop and followed the Linux compile instructions from Prusa. I seem to compile without any issues, but when I compare the size (and contents) of my hex file to the one from Prusa the two are different (see below for files). Could anyone tell me how this can be?

 

Sample files: https://drive.google.com/drive/folders/1QXONciumbPcrTrNbyJ1rokzDtNl7zqIO

Github issue: https://github.com/prusa3d/Prusa-Firmware/issues/2799

This topic was modified 2 months ago 2 times by ANTALIFE
www.antalife.com...
Posted : 12/08/2020 1:27 pm
vintagepc
(@vintagepc)
Noble Member

the official firmware also contains language data for non-English .

While possible to assemble locally it's an extra step that doesn't happen if you follow the standard build instructions. 

Posted : 12/08/2020 2:34 pm
ANTALIFE
(@antalife)
Eminent Member

@vintagepc

Yup, when I compile I also produced hex files for a bunch of other languages. But the one I am comparing is for ENG

www.antalife.com...
Posted : 12/08/2020 10:13 pm
jsw
 jsw
(@jsw)
Prominent Member

Having been involved in many software development projects over the decades, I can say that it's very common for intermediate files (.hex, etc.) and executable files that have been built on different platforms, and even on the same platform at different times, to differ.  There are so many variables in the process.

Posted : 13/08/2020 9:07 am
ANTALIFE
(@antalife)
Eminent Member

@jsw

Hmm, I would understand if it was only the timestamp that was different, but with me there is way too much ?_?

Again I don't see any unexpected errors during compile (see "Fedora-terminal.txt"), but there seems way too much different. Plus when I upload my FW ("My-firmware.hex") to printer a few options become disabled, like spool join which shows as N/A
https://drive.google.com/drive/folders/1TPdhWBeQHGp1Y5BMv2ibwR_NSoT-6x5e?usp=sharing
www.antalife.com...
Posted : 13/08/2020 11:01 am
vintagepc
(@vintagepc)
Noble Member
Posted by: @jsw

Having been involved in many software development projects over the decades, I can say that it's very common for intermediate files (.hex, etc.) and executable files that have been built on different platforms, and even on the same platform at different times, to differ.  There are so many variables in the process.

hex files are not "intermediate", the are the final executable binary for the target platform. Unless you have differing compiler configurations (optimizations etc), they should be identical regardless of the machine it was built on, excepting "baked-in" things like the date/time the firmware was compiled or the host's name.

 

Posted : 13/08/2020 2:52 pm
towlerg
(@towlerg)
Honorable Member

The problem with hex format is that a small change will generate apparently wildly different output. Are you sure you are comparing like with like eg. debug mode, newer external libraries and other stuff I can think of now)

Posted : 14/08/2020 5:06 am
jsw
 jsw
(@jsw)
Prominent Member
Posted by: @vintagepc
Posted by: @jsw

Having been involved in many software development projects over the decades, I can say that it's very common for intermediate files (.hex, etc.) and executable files that have been built on different platforms, and even on the same platform at different times, to differ.  There are so many variables in the process.

hex files are not "intermediate", the are the final executable binary for the target platform. Unless you have differing compiler configurations (optimizations etc), they should be identical regardless of the machine it was built on, excepting "baked-in" things like the date/time the firmware was compiled or the host's name.

 

We may have to agree to disagree here.  🙂 I've done a lot of low-level machine control stuff over the decades and I know of countless cases where things like module link order, compiler and linker switches, word/page/etc. alignment, etc. will cause identically-working executables to differ considerably when compared.

Posted : 14/08/2020 7:40 am
ANTALIFE
(@antalife)
Eminent Member
Posted by: @jsw
Posted by: @vintagepc
Posted by: @jsw

Having been involved in many software development projects over the decades, I can say that it's very common for intermediate files (.hex, etc.) and executable files that have been built on different platforms, and even on the same platform at different times, to differ.  There are so many variables in the process.

hex files are not "intermediate", the are the final executable binary for the target platform. Unless you have differing compiler configurations (optimizations etc), they should be identical regardless of the machine it was built on, excepting "baked-in" things like the date/time the firmware was compiled or the host's name.

 

We may have to agree to disagree here.  🙂 I've done a lot of low-level machine control stuff over the decades and I know of countless cases where things like module link order, compiler and linker switches, word/page/etc. alignment, etc. will cause identically-working executables to differ considerably when compared.

Yea I think you are spot on here. After quite a bit of discussion with 3d-gussner on GitHub, the closest I can get it to Prusa's hex is:

 

 

===================================================================================

The different lines are:

:1072C000553253004E4F4D4B3353002E01417567DD
:1072D000203133203230323000436F6D70696C657D
:1072F0006C7420636F6E6669672900417567203181
:107300003320323032302032313A31333A3539009D
:109450002E2073656E736F7220762E3A0041756709
:109460002031332032303230004533447636667551
:10966000008813000010101020FFFFFFFF4D37305F
:10000000A55AB44BF6256D01000073636D01000025
:1025F000656E69205A00A55AB44BB62B6D010000D8
:1026000065646D010000EA023C034D035D03640351
:1051B000852A6D01000073656D010000EA02360367
:107C300000A55AB44B8A2C6D01000072666D0100DC
:107C400000EA023603460356035C0362037503B57C
:10A8C0002B6D01000074696D010000EA023503463A
:10D3C000A55AB44B27286D0100006C706D01000058

Which translates to:

�rÀU2SNOMK3S.�AugÝ�rÐ 13 2020Compile}�rðlt config)Aug 1��s3 2020 21:13:59���P. sensor v.:Aug �� 13 2020E3Dv6fuQ������� ÿÿÿÿM70_�¥Z´Kö%m�scm�%�%ðeni Z¥Z´K¶+m�Ø�&edm�ê�<�M�]�d�Q�Q°�*m�sem�ê�6�g�|0¥Z´K�,m�rfm�Ü�|@ê�6�F�V�\�b�u�µ|�¨À+m�tim�ê�5�F:�ÓÀ¥Z´K'(m�lpm�X

===================================================================================

Also what really helped is compiling with "./PF-build.sh" instead of "./build.sh" like the Prusa Linux instructions say

www.antalife.com...
Posted : 14/08/2020 9:51 am
Share:

Please Login or Register