Investigating delta OTA update via LoRa

[tachin]

I was thinking about building a custom delta update system for OTA via LoRa (1-5 Kbps), super optimized for patch size, sending absolutely the bare minimum necessary.

I just did a test with a basic firmware that takes up 280KB.

Code: Select all

void setup() {
    Serial.begin(115200);
    Serial.println("Hello from ESP32!");  
}

The simple act of adding a second serial.print results in 26KB difference (accounting for displacements, shift, etc.) between one firmware and another.

Code: Select all

void setup() {
    Serial.begin(115200);
    Serial.println("Hello from ESP32!");
    Serial.println("ESP32 from Hello");
}

I'm wondering if this is actually the case or if I'm doing missing something since these size differences are out of range for my initial approach

[MicroController]

results in 26KB difference (accounting for displacements, shift, etc.) between one firmware and another.

Is that 26KB difference between the binaries, or is 26KB the size of the resulting (compressed) patch file?


Haven't tried delta OTA myself yet, but re:

these size differences are out of range

Obviously(?), the sizes of patches will not grow linearily with the amount of source code changes, like 26KB per line of code. The binary and with it the patch size should stabilize somewhat once changes become small relative to the previous version of the application.

You may also be able to reduce the amount of "delta" by directing your application code into dedicated sections which you then have the linker place at the end of the binary, so that a change in your code is less likely to force a relocation of unmodified "system" code.

[tachin]

Is that 26KB difference between the binaries, or is 26KB the size of the resulting (compressed) patch file?

I'm not doing yet the "patcher" , I am in the process of checking whether it is a viable option.

There are 26000 differents bytes, some of them in a row but most of them are isolated and spread throughout the file. I guess the compiler has decided to move some memory addresses here and there.

https://i.imgur.com/gJLwLwz.png

the sizes of patches will not grow linearily with the amount of source code changes, like 26KB per line of code. The binary and with it the patch size should stabilize somewhat once changes become small relative to the previous version of the application.

I'm not sure about that. The more things the compiler can change, the more likely there will be changes I made a quick test with a old code resulting in a 790Kb bin file, adding a Serial.println turns out on 36K bytes changes (fixing byte offsets)

In any case, if the minimum change is going to be 26KB, it is completely impractical.

You may also be able to reduce the amount of "delta" by directing your application code into dedicated sections which you then have the linker place at the end of the binary, so that a change in your code is less likely to force a relocation of unmodified "system" code.

Thanks for the tip! At first glance, it looks good.

I am investigating whether the compiler has any options to force the order; the overall firmware size or execution speed are not a priority.