As above, so below, part 2. Bare metal Rust generics
ecorax.net
ecorax.net
Is this standard practice? Everyone knows that one should write only on previously erased units (sectors/blocks/pages/whatever). Maybe it's just for the sake of the example, but I think it's kind of insane to produce a routine to check for EVERY BIT and see if it's 1 AND if we can fit whatever we want to write. What are the chances one can overwrite (for example) a string TWICE?
There are some particularities of the data we're writing that make this case more common than usual, and in any case the time spent in the bit masking routine is negligible compared to the flash erase time, so it works out well (keep in mind that the `all()` consumer will short-circuit as soon as two bits differ, so in the general case it's cheap, and in the erased case it isn't too different from verifying every byte is 0xFF). We're also really, really strongly optimizing for flash life above speed, as this code is meant to run very rarely for FOTA upgrades.
For a general purpose storage flash driver, I'd definitely erase every sector.
You might often want to write less than a full block. In that case, if you always erase, you have to read the full block to ram, make your change, then erase, then write the full block. If you write byte by byte, that's a lot of erase cycles. So you add a check to see if the bytes you want to write are already in the erased state. But it's not much more work to check if the desired state is attainable instead of just if the current state is erased. Isn't it just if Current & New == New?
Those would be partially-charged cells, and should be erased properly before writing, lest you start getting temperamental read errors later.
But repeatedly erasing blocks just to add a byte will wear out the block, as well as take a long time as you point out.
I think the solution to these two constraints is filesystem-like book-keeping of which regions are in which states.
I'm not very familiar with the ATSAM* series so compatibility-wise this might be wrong, but you could likely add ATSAML support to that repo reasonably easily.