Slymeat
Move on, nothing to see.
The following is a well written article explaining how WeebitNano ReRAM is a far superior technology to FLASH. It’s only a 2 minute read and does not get technical.
Non-volatile memory considerations for data logging
In addition to explaining the critical aspects of ReRAM NVM well, ( as compared to FLASH—ReRAM is faster, cheaper, more resilient to heat and radiation, uses less power, operates at much lower voltage, less susceptible to cyber attack, lasts longer, can be embedded in sub 40 nm architecture etc.) the article touches on a point that I feel is the crux to why FLASH simply can’t compete in longevity with ReRAM and simply must be replaced by it in ALL applications that read and write data frequently. Aside from the fact that ReRAM has at least orders of magnitude improvements in read/write cycles (the number of times you can read and write data to it) FLASH suffers the problem of requiring a “page erase cycle” before programming a new page. That means, even when writing a single bit, an entire page of bytes is taken through one of their precious write cycles.
And this is why Weebit’s selector is so important.
Here’s some supporting technical data I found on the internet regarding the page erase cycle required by FLASH.
1 instruction = 3 bytes = 2 addresses
erase page = 1024 instructions = 3072 bytes = 2048 addresses
write page = 64 instructions = 192 bytes = 128 addresses
Even to the layperson, that appears to be a hell of a lot of wasted effort (and energy), just to write a piece of data.
The above is from a reasonably old answer (2016) on the Microchip forum but I figure FLASH is an old technology and hasn’t been improved much.
This 2021 article from Silicon labs suggests flash pages can be anywhere from 512 bytes to 4096 bytes, in their particular module. So clearly, things haven’t changed much.
Reading and writing FLASH is actually far more complicated, as discussed briefly in Wikki. The world is full,of workarounds, both in code and in hardware, and simply MUST be looking for a viable replacement—bring on ReRAM.
So in a nutshell, with FLASH, you can remove the need for an erase block cycle iff the new data being written ONLY replaces existing “1”s with “0”s. i.e you can write (without erase) 1110 over the top of 1111. But then this requires a read cycle and a calculation to determine if it is possible. And if not possible, all that effort is purely wasted.
ReRAM requires merely a single write cycle, regardless of whatever the value is and regardless of what is currently stored.
Non-volatile memory considerations for data logging
In addition to explaining the critical aspects of ReRAM NVM well, ( as compared to FLASH—ReRAM is faster, cheaper, more resilient to heat and radiation, uses less power, operates at much lower voltage, less susceptible to cyber attack, lasts longer, can be embedded in sub 40 nm architecture etc.) the article touches on a point that I feel is the crux to why FLASH simply can’t compete in longevity with ReRAM and simply must be replaced by it in ALL applications that read and write data frequently. Aside from the fact that ReRAM has at least orders of magnitude improvements in read/write cycles (the number of times you can read and write data to it) FLASH suffers the problem of requiring a “page erase cycle” before programming a new page. That means, even when writing a single bit, an entire page of bytes is taken through one of their precious write cycles.
And this is why Weebit’s selector is so important.
Here’s some supporting technical data I found on the internet regarding the page erase cycle required by FLASH.
1 instruction = 3 bytes = 2 addresses
erase page = 1024 instructions = 3072 bytes = 2048 addresses
write page = 64 instructions = 192 bytes = 128 addresses
Even to the layperson, that appears to be a hell of a lot of wasted effort (and energy), just to write a piece of data.
The above is from a reasonably old answer (2016) on the Microchip forum but I figure FLASH is an old technology and hasn’t been improved much.
This 2021 article from Silicon labs suggests flash pages can be anywhere from 512 bytes to 4096 bytes, in their particular module. So clearly, things haven’t changed much.
Reading and writing FLASH is actually far more complicated, as discussed briefly in Wikki. The world is full,of workarounds, both in code and in hardware, and simply MUST be looking for a viable replacement—bring on ReRAM.
So in a nutshell, with FLASH, you can remove the need for an erase block cycle iff the new data being written ONLY replaces existing “1”s with “0”s. i.e you can write (without erase) 1110 over the top of 1111. But then this requires a read cycle and a calculation to determine if it is possible. And if not possible, all that effort is purely wasted.
ReRAM requires merely a single write cycle, regardless of whatever the value is and regardless of what is currently stored.