2020-07-29 12:16 AM
Hello,
Currently, the generated binary file is 1 MB but with 96% of '0'.
Obviously, it's quite long to transfer via CAN to update the firmware, mostly for 'nothing'.
I can see that the 'end' of my code is:
1000 0000 0100 0000 4078 7d01 0000 0000
Is it a specific information informing about the end of the code?
I also see that the end of the file is:
0000 0000 0000 0000 0000 0000 0000 0501
Regards,
2020-07-29 01:41 AM
I think the zeros are part of your binary image. you can change the code and see that image file size vary. so the size is related to your code.
An option is to compress your binary file > send through CAN > decompress it. It is faster. For compression there is fast and light weight algorithms like variants of LZ algorithm.
2020-07-29 01:43 AM
Ok, thanks I'm going to see with the developper if there is something related to declared memory size or something like that..
2020-07-29 11:25 AM
Check the map file generated by the linker to see what objects are taking up that much space.
2020-07-29 02:11 PM
A large block of "almost 0s" at end of the binary can be initialized data, which is initialized mostly by 0s.
For example: long foo[1000] = {1,2,3};
Look if such variables can be initialized in runtime instead, and moved therefore from the data section to bss.
Also, consider compression.
-- pa