Saving user data on EEPROM & SD - development discussion

A suggestion for the Cookie Manager program:

  • the code exists in PokittoLib
  • the manager is fired up when there is no more space to save a cookie for a game
  • offers the user an UI to remove any existing cookie
  • when enough cookies has been deleted by the user the manager turns to “green” and saves the current cookie
  • Pokitto is restarted as the game screen might be messed up (optional)
1 Like

With such a manager, it’s almost a file system with tiny path haha

Linked how though?

Do the 7 bits of a crumb/block table entry indicate which key they correspond to?
E.g. if crumbTable[4] == 5 does that correspond to the crumb being owned by the key at keyTable[5]?

In your system, are blocks allocated contiguously or can a game have its blocks spread out?

Not quite.
In my system all the allocated blocks are contiguous and a game can claim more than 32 bytes.

So if a game claims 32 bytes (1 block), the header size means they only get 16 usable, but if they claim 64 bytes (2 blocks), they get 48 usable. If a game claimed 512 bytes (16 blocks), there would be the constant 16 bytes for the header and the remaining 496 bytes would be usable etc

Maybe this will make it clearer:

checksum (4 bytes)
id (4 bytes)
size (1 byte)
reserved (9 bytes)
data (((size * 32) - 16) bytes)

So to find a block by traversing the allocated blocks:

EeepromPointer findBlock(SaveId saveId)
{
  EepromPointer pointer = pointerToFirstByte;
  while(isValid(pointer))
  {
    SaveBlockSettings settings;
    EEPROM.read(pointer, settings);
    if(settings.saveId == saveId)
      return pointer;
    pointer += settings.size.getSizeInBytes();
  }
  return invalidEepromPointer;
}

Most likely an id of 0 would be used to indicate an unused block.

Hopefully we will have a system for backing up entries to SD card so you can treat the EEPROM as your active data and the SD card as your archived data.

Or manually to organise before loading a new game.

Essentially that kind of is what we’re doing.
These ideas are similar to how file systems usually work.

@jonne’s proposal is similar to the FAT family of file systems because it uses a table to track the block entries. Mine is closer to an algorithm that’s sometimes used to implement malloc (it’s more of a bare bones linked list with offsets instead of pointers).


After looking at FAT, one other idea I had was to have a table that stores the game id, an index and a size, with index and size being multiples of the block size.

struct TableEntry
{
  std::uint8_t gameId[6];
  std::uint8_t index;
  std::uint8_t size;
};

Then it could fit 64 entries in 512 bytes (or 42 for the extra 2 bytes in the name).
This would probably be a much easier system to perform reconfiguring operations on.

1 Like

I still don’t understand why people would rather use EEPROM than a file on SD…

3 Likes

Because EEPROM is cool.

2 Likes

To enable to save the state if Pokitto do not have an SD card at all.

FYI EEPROM savegame blocks system is almost working already

Going to finish it up tonight

2 Likes