I am using gnu-arm to generate the .hex files for my MCU. I want to send firmware updates over the air, using a limited bandwidth channel, so the idea is to just send an incremental update, using the difference between version. Is it possible with gnu-arm (or anything else) to generate an .hex version that differs as little as possible from another one?
Asked
Active
Viewed 64 times
0
-
There are various techniques to transform the image; see bsdiff and [delta encoding](https://en.wikipedia.org/wiki/Delta_encoding). Various patented algorithms search for 'branch' instructions. Something outside a 'basic block'; these are typically redundant offset changes which result in a large amount of differences in a binary delta. By looking at assembler of the original, you can mark all 'PC' altering op-codes and label the target address. The 'delta' encode can say by how much to increase/decrease these labels which will also greatly reduce bandwidth. – artless noise Mar 29 '18 at 15:12
-
To make the difference smaller, you code pad/custom code a linker script to minimize the address churn of unmodified code. PC relative build options would also probably reduce the changes in binary to un-modified code due to execution address. – artless noise Mar 29 '18 at 15:14
-
as far as two builds of a project, for example add a single nop to the bootstrap of your project and change nothing else, see how it affects the project (moves everything up by 2 bytes, causing a ton of changes, not all can be diffed/shifted out). so gnu has nothing to do with it you the programmer adding and removing code will result in few to many changes even with one line of code changed. – old_timer Mar 29 '18 at 20:13
-
its possible to have every function be separate objects (or whatever is required) so you can define each in the linker script, then so long as you dont go past what you have allocated for a specific function you are changing, that should do minimal damage to the overall binary compared to a prior build. – old_timer Mar 29 '18 at 20:13
-
building with different versions of gnu one should also expect the same code to vary anywhere from no difference to lots of differences. (not just a gnu thing just how compilers evolve/improve) – old_timer Mar 29 '18 at 20:14