write/erase time for a sector in 89V51RD2

It's trivial to rate code.

How to select which sector to use:

save_nonvolatile() {
    mon_debug("saving nonvolatile data.");
    build_sector_data(sector_data);
    for (;;) {
        sequence_count++;
        patch_sector_data_with_sequence(sector_data,++sequence_count);
        eval_crc_for_sector(sector_data);
        sector_num_to_use = sequence_count % num_sectors;
        program_sector(sector_num_to_use,sector_data);
        if (verify_sector(sector_num_to_use)) break;
        mon_debug("failed saving to sector %u - stepping to next.",sector_num_to_use);
    }
}

Potentially you could keep a list of known broken sectors to instantly skip, but that optimization might not be needed.

And trivial to find current sector too by reading all sectors, while ignoring all sectors with invalid crc. The highest sequence count found represent the surviving sector with newest data. sequence number+1 modulo sector count represents the next sector to use. Sequence number divided by number of sectors represents the amount of wear - divide by the rated wear count and you get how much of total life expectancy you have consumed.

So your life is less complicated if you rotate through the sectors. If you wear one sector at a time, then you need to add lots of "interesting" backup functionality for trying to recover after a sector failure. And remember that if sector n fails after 9000 writes, then sector n-1 contains 9000 writes old information which might represent days, weeks or months old data. With a continuous rotation around all sectors, then the previous sector is just one write old. So you might just step back in time 10 minutes by having to go back to the previous sector to recover.

Your variant with a sector at a time really is extremely complicated. You would need to add own ECC (error correcting code) in your sector data to give your code a chance to recover data even if there are a number of bit errors in the written sector data. And that ECC would still not help you if you lost the power just after you erased the sector but before you had time to write down the updated data. With a rotation scheme, a power loss at that time doesn't matter much becuase you haven't erased your previous save. So you have a safe restore point.

My solution is KISS - keep it simple stupid. Easy to implement and with excellent recovery options.

Your solution might sound KISS but is hard to implement and even when well-implemented still leaves situations you can't recover from without backing in time with a huge amount.

It's trivial to rate code.

How to select which sector to use:

save_nonvolatile() {
    mon_debug("saving nonvolatile data.");
    build_sector_data(sector_data);
    for (;;) {
        sequence_count++;
        patch_sector_data_with_sequence(sector_data,++sequence_count);
        eval_crc_for_sector(sector_data);
        sector_num_to_use = sequence_count % num_sectors;
        program_sector(sector_num_to_use,sector_data);
        if (verify_sector(sector_num_to_use)) break;
        mon_debug("failed saving to sector %u - stepping to next.",sector_num_to_use);
    }
}

Potentially you could keep a list of known broken sectors to instantly skip, but that optimization might not be needed.

And trivial to find current sector too by reading all sectors, while ignoring all sectors with invalid crc. The highest sequence count found represent the surviving sector with newest data. sequence number+1 modulo sector count represents the next sector to use. Sequence number divided by number of sectors represents the amount of wear - divide by the rated wear count and you get how much of total life expectancy you have consumed.

So your life is less complicated if you rotate through the sectors. If you wear one sector at a time, then you need to add lots of "interesting" backup functionality for trying to recover after a sector failure. And remember that if sector n fails after 9000 writes, then sector n-1 contains 9000 writes old information which might represent days, weeks or months old data. With a continuous rotation around all sectors, then the previous sector is just one write old. So you might just step back in time 10 minutes by having to go back to the previous sector to recover.

Your variant with a sector at a time really is extremely complicated. You would need to add own ECC (error correcting code) in your sector data to give your code a chance to recover data even if there are a number of bit errors in the written sector data. And that ECC would still not help you if you lost the power just after you erased the sector but before you had time to write down the updated data. With a rotation scheme, a power loss at that time doesn't matter much becuase you haven't erased your previous save. So you have a safe restore point.

My solution is KISS - keep it simple stupid. Easy to implement and with excellent recovery options.

Your solution might sound KISS but is hard to implement and even when well-implemented still leaves situations you can't recover from without backing in time with a huge amount.