Flash chip access speed / restrictions

I’ve seen these asked in other threads but not answered yet (or maybe I missed the answers)

  • How fast is reading from the chip? (AVR cycles)
  • How fast is writing to the chip? (If different from reading)
  • Are there restrictions on read / write? e.g. must read or write in blocks of X bytes or aligned to certain addresses
  • Is sequential access faster than random access?
1 Like
  • Address setup: 4x18 cycles + register setup)
  • After address setup: 18 cycles per byte sequential read fastest

Slow. Writing to flash is not the same as to RAM. Writing to flash requires the old content be erased first (in 4K sectors) and then written in 256 byte pages.

When flash memory is erased all bytes are reset to FF when writing to flash only 0 bits are flashed. You can write over existing data if the new data contains only bits that changed to 0.



Thanks for the answers! It wasn’t clear to me before the complications for writing to flash. This is quite a significant problem if trying to treat the flash like extra RAM storage. (i.e. you can’t)

Unfortunately this means I can’t see a sensible way of expanding the playable map size in MicroCity. :cry:

I suppose that this also means you have to force the EEPROM / save storage space to be a multiple of 4K? i.e. even if you are only using a few bytes for a high score table or something then you’ll need to reserve the whole 4K so that can erase a sector without trampling on anything else


There are possibilities though. you can claim an extra 4K sector (for data <= 4K). So you can alternately write erase your data and use a pointer to point to the most recent data.

For example lets say your data takes 512 bytes and you write it to the beginning to the 4K sector then when the data changes you write it right after the the first 512 bytes and this process is repeated on each write untill the end of the 2nd 4K sector has been reached. The next write would erase the 1st sector , writes the data to the beginning of the 1st sector and ends by erasing the 2nd sector.

with 512 bytes, there will an erase cycle every 16 writes.

Yes. But since there are 4096 4K blocks in 16MB it’s not so bad.

1 Like

Yeah this did occur to me but then a ton of time is going to be spent just re-writing data (e.g. only a few bytes have changed but needs a whole new block to be written)

another possibility but harder word be zero bit writing. You could rewrite the same flash as long as the new data only contains bits that changed to zero. when a bit changes from 0 to one you would need a copy or erase cycle.

For example. Let’s say you have a value that has a range of 0 to 32 and only increases from 0 up. Then in flash it’s stored as 32-bit value FFFFFFFF as value 0 (0 bits cleared) then when the value increases it is overwritten by FFFFFFFE as value 1(1 bit cleared) and FFFFFFFC (2 bits cleared)

This technique also works well for gameflag array where flags can be set(cleared) randomly when a test has been achieved/unlocked

Are the 18 cycles the cycles needed by the spi code to shift in a byte from the spi?

Yes head to head 16 cycles for the bit shifting then 1 cycle to clock out the next byte and 1 more to sync up again to 8 MHz SPI clock (MCLK/2)

Ok. Do you have some simple library functions that we can use in our games?
I do not have the datasheet in mind, but the address programming is also on per page basis, right? From then on you can sequentially stream bytes from the first byte of the addressed page until we programm another page address (so after the first page got transferred it will seamlessly transfer the next). Is this correct?

I’ve cooked up this for a basic test. But will do more work on that ofcourse (Adding features optimize some things)

Reading can be done at byte level. Only writing on page basis. Erasing on 4K boundaries.
Sequential reading can be done continiously (or until the OLED display needs to be written too)

Technically you can simultanious read from flash and directly write it to OLED display. But this is only useful for full screen image animations.

@jhhoward you could consider neighboring cities stored in chunks? Like how cities skylines works where you are only editing one section at a time.

So you get to the edge of the map and you would hit a prompt to continue then loading screen.

This way you can keep your current implementation and just load stacks in and out of ram. It also would be a better convention than storing level data in eeprom, that. Even just changing the save data to go into external flash is a big win as it doesnt nuke data from other apps.

1 Like

Moved the MicroCity discussion to a new thread: