Project Ideas

Streamline flash writes

We currently allocate 3x the flash-chip size on the heap by default. One time for the file contents to be written, one time to track the current flash chip contents, and another time to be able to tell if anything changed, should writing fail. This becomes worse and worse for embedded environments with our ever growing flash-chip sizes. Flashing a 64MiB image would at least need a system with 256MiB RAM.

Possible solutions (incomplete)

Use checksum to compare failure state

The third allocation is only used for a binary decision: Display a fatal or non-fatal help message. We could as well calculate a checksum over the original flash contents and compare that.

Allocate per touched erase block

The second allocation could be much smaller if we'd consider every erase block individually. This would mean we have to return to write per block first. Though, that should be a manageable refactoring. Downside: We still would have to allocate a full flash size if flashprog decides to erase the whole chip.

Split the write into smaller chunks

Instead of writing per erase-block as suggested above, split the write into a pre-defined chunk size. Overall probably more code, but might be cleaner and guarantees small allocations.

Use stream objects for the input

The first allocation for the data to be written is currently required because we want to keep the libflashprog API free from file i/o (not every environment has <stdio.h>). However, we could implement our own stream objects that can hide if the data comes from a file, memory, or maybe even the flash (e.g. if the objects would be used for reading as well).