FlashStorage RAM requirement problem

I was trying to use this library for an Arduino Zero compatible circuit:

But I couldn't use the public interface, because the flash data didn't fit into RAM twice, so I couldn't use the FlashStorage::read function. Is there a better library?

My current workaround is kind of ugly, using the internal interface of the library. I have a config array in RAM, which I need to save to flash and compare with the RAM config. I define the RAM array and the array in flash like this:

#define CONFIG_SIZE 18432

__attribute__((__aligned__(8192))) const uint8_t savedConfig[(CONFIG_SIZE+8191)/8192*8192] = { };
FlashClass savedConfigClass(savedConfig, CONFIG_SIZE);

uint8_t config[CONFIG_SIZE];

That's a neat trick, to define the flash memory with a "const" variable, which is used in the macro of the library you would normally use.

Then I can write to the flash like this, when I want to save my config data in RAM to the flash:

void saveConfig() {
  savedConfigClass.erase();
  savedConfigClass.write(config);
}

For using the saved config, I can just access the savedConfig array, and it reads the flash. I use it like this:

    // compare result with saved reference
    bool error = false;
    for (int i = 0; i < CONFIG_SIZE; i++) {
      if (savedConfig[i] != config[i]) {
        error = true;
        break;
      }
    }

I guess alternatively I could have defined a struct with the fixed array size, to then use it as the type for the FlashStorage macro, and then the internal generated name for the variable pointing in the flash area. But this would be still ugly on another level.

Would be nice, if the private FlashStorage implementation could be cleaned up. This would be a 3 layer concept: the current public interface for the usage as explained now in the documentation, then a more direct interface as I used it, and then the private implementation to deal with the low-level flash write functionality. Best would be if it could be implemented without macros, but this might be difficult.

Looks like other people have similar problems, see for example here:

While this could be solved by defining a struct, it would be better to have the public middle layer, which allows just to save a byte array and access the pointer for reading.