Delta programming (restrict uploads to changes only)

[navnavnav]

Currently, when programming the target, we upload the entire program to the target.

But how often does the entire program change between uploads? I think it's safe to say that in most cases, only relatively small changes are made between uploads. This means that we're wasting time updating parts of program memory that hasn't changed.

I believe we could drastically improve upload performance by generating a diff of the current binary and the new binary provided by GDB, and then only applying the changes to program memory whilst ignoring the rest.

First few points that come to mind:

• We could make use of the program memory cache as a means to keep track of changes
• The first upload for each debug session will still be slow, as the program memory cache will not be populated at that point
• We'll need a way to disable/ignore GDB's erase packet. GDB sends an erase packet to Bloom at the beginning of each programming session. Servicing this would mean the entire program memory would need to be updated, rendering this feature useless.
• This feature will make little difference for IDE users. At least for the IDEs that restart Bloom whenever the user wishes to rebuild the program (as CLion currently does). I've already brought this up with JetBrains, so it might be worth putting this on hold until they address that issue.
• This feature will not be suitable for programs that can alter the target's program memory (such as bootloaders). It should be optional

More to follow

[navnavnav]

Thinking about this some more: This will only work for debugWire targets, because there's no requirement for a chip/section erase before programming. For other targets (PDI, UPDI and JTAG), we must perform a chip/section erase before we can program the target. So we'll have to write the whole program binary for every programming session.

This is not worth the effort if it only works on debugWire targets.

I'm going to leave this open for the time-being, as it may be appropriate for a new target family I'm looking to support at some point.

[navnavnav]

This is appropriate for the RISC-V targets that I plan to support in the next feature release (see #96).

With those targets, we're able to perform partial page writes to program memory without having to erase the entire chip. This means we can perform 'delta programming' on these targets.

Not sure when I'll get to this, or if it will be included in the next release, with the initial RISC-V support. Will keep the ticket updated,