> as far as I can tell that's not useful for low-power computing—the NAND Flash chip is going to use an order of magnitude more power than the CPU
Agreed that the NAND can consume a ton more than the CPU, so duty cycle has to be kept low. There's a few places where XIP NAND excels: it's big, it's cheap, and it can saturate the XIP memory bus just like NOR for large reads - it's a great place to store bitmap graphics. One downside is that the random access latency is pretty terrible.
> with XIP you can't predict or even really measure how much you're accessing it
There are a couple incomplete options here:
Just for measuring, you can fence off the XIP address range to generate MPU access violations, then work out a duty cycle.
The cache has performance counters, but at the cache level they don't tell you anything about internal flash vs XIP flash.
> The (non-SPI!) NAND I'm going to attempt to use only uses 18μW in standby
There are similar low standby QSPI parts available(10uA@1.8v typical), like W25N01GV.
Agreed that the NAND can consume a ton more than the CPU, so duty cycle has to be kept low. There's a few places where XIP NAND excels: it's big, it's cheap, and it can saturate the XIP memory bus just like NOR for large reads - it's a great place to store bitmap graphics. One downside is that the random access latency is pretty terrible.
> with XIP you can't predict or even really measure how much you're accessing it
There are a couple incomplete options here:
Just for measuring, you can fence off the XIP address range to generate MPU access violations, then work out a duty cycle.
The cache has performance counters, but at the cache level they don't tell you anything about internal flash vs XIP flash.
> The (non-SPI!) NAND I'm going to attempt to use only uses 18μW in standby
There are similar low standby QSPI parts available(10uA@1.8v typical), like W25N01GV.