Many devices have provision for IAP programming of Flash code memory.
These need you to erase a page, then write your data.

Some devices have specific byte programmable Eeprom memory. These are very convenient for single-chip designs. You can update cells individually for configuration data.

void update_eeprom(uint16_t location, uint8_t val)
{
    uint8_t old = read_eeprom(location); 
    uint8_t diff = val ^ old;
    
    if (diff == 0) return;     // eeprom value unchanged

    if ((val & diff) == 0) {   // are bits blown?
        write_eeprom(location, val); // only bits 1 -> 0
    else {                     // need to erase page
        uint16_t page = location & ~511;
        uint16_t i;
        for (i = 0; i < 512; i++) {
            xbuf[i] = read_eeprom(i + page); // copy page to XRAM
        eeprom_erase(page);
        xbuf[location - page] = val;  // update XRAM copy
        for (i = 0; i < 512; i++) {
            write_eeprom(i + page, xbuf[i]); // write new page
    }
}

 

This seems costly in terms of 512 byte of valuable RAM, and risky since the writing could fail part way through.

Another approach could be to maintain shadow pages in Flash. At power-up, you can test for equality.

Time is seldom an issue. Page-writes tend to be a 'similar' time as byte writes. However, all that copying seems untidy.

Devices with 1k of byte-writable eeprom are very useful.
A P89C51RD2 has very large page sizes if you were to use Flash as IAP non-volatile data storage.
The Chinese STC12C5Axxxx chips are extremely attractive with up to 32k 'eeprom'. However the page 'update' involves copy, erase, write.

Another strategy might be to 'alloc' fresh eeprom until you run out. Then garbage collect.

Any comments?

David.