To me, it's a little strange for someone to be asking such things, because datasheets should have all the info you need to design your project with. But nobody's talking datasheets so far, so I'd just like to point it out to you.
Look at the Pico board datasheet (or whichever board you are using). Find the SPI NOR part. I found a Winbond W25Q16JVUXIQ. Download the datasheet. Page (256B) programming time is 0.4ms typical 3ms worst. Sector (4KB) erase time is 45ms typical 400ms worst. A fresh NOR flash should have typical timings, and I expect worst-case to happen when it is wearing out (much more than 100K cycles, most application will never go near that.) That's pretty much all the timing info you need. Design your project to meet the specs. Say, for low rate data logging, 256B at a time seems to be easy enough. I'd just give the NOR flash a generous time segment to do whatever it needs to do.
You can also test the NOR flash, just to get actual data points. The input latch or buffer is 256B, say you plan for programming units of 256B. Study the SDK, write a program and try out the flash. Measure the write timings and you can dump it to serial USB, most likely the timings will be typical, plus the usual run-from-NOR jitter whatnot. There will be a spread, of course. Do the same for erase blocks (write some data first, otherwise it's possible some on-chip programming algo might finish early). Then you'll have all the timing data you need.
No need to fiddle with the entire 2MB. Also, learn more about NOR flash chips. Program and erase have different timings -- might be important if you have extreme performance requirements.
Look at the Pico board datasheet (or whichever board you are using). Find the SPI NOR part. I found a Winbond W25Q16JVUXIQ. Download the datasheet. Page (256B) programming time is 0.4ms typical 3ms worst. Sector (4KB) erase time is 45ms typical 400ms worst. A fresh NOR flash should have typical timings, and I expect worst-case to happen when it is wearing out (much more than 100K cycles, most application will never go near that.) That's pretty much all the timing info you need. Design your project to meet the specs. Say, for low rate data logging, 256B at a time seems to be easy enough. I'd just give the NOR flash a generous time segment to do whatever it needs to do.
You can also test the NOR flash, just to get actual data points. The input latch or buffer is 256B, say you plan for programming units of 256B. Study the SDK, write a program and try out the flash. Measure the write timings and you can dump it to serial USB, most likely the timings will be typical, plus the usual run-from-NOR jitter whatnot. There will be a spread, of course. Do the same for erase blocks (write some data first, otherwise it's possible some on-chip programming algo might finish early). Then you'll have all the timing data you need.
No need to fiddle with the entire 2MB. Also, learn more about NOR flash chips. Program and erase have different timings -- might be important if you have extreme performance requirements.
Statistics: Posted by katak255 — Wed May 01, 2024 4:24 am