I think it has a shot at replacing SRAM but Flash is currently used for MB storage. MRAM is another candidate commonly proposed for the same purpose, because of its high (also not unlimited) endurance. Both can also be disturbed by cumulative if not direct reads. I wonder which would be the preference.
My big concern is the write-ability: We've all had a pointer go blooie (which is less likely in high(er)-level languages like C than in assembler, but a 16k chip is probably going to see assembler). Do they provide some way to lock/protect the code portion of the memory?
The devices in the MSP430FR59x/FR69x series can protect portions of code using a couple of built-in modules. The Memory Protection Unit (MPU) monitors and supervises memory segments as defined in software to be protected as read, write, execute or a combination of the three. What's more, these devices have built-in IP Encapsulation (IPE) capabilities to lock sections of code from access via JTAG, BSL or Direct Memory Access.
@resistion: Each read takes a cycle as well, you still have to write after read.
But reading from any form of memory (Flash, EPROM, FRAM) doesn'd degrade it and doesn't count as part of the total number of cycles -- when they say Flash can support only 10,000 cycles, for example, they are talking about erase-&-write cycles, not read cycles.
FRAM based controllers from TI are really a very nice design and provide improvement both in terms of speed and power. Many small size embedded systems are adopting these controllers especially in biomedical equipments.
My Mom the Radio Star Max MaxfieldPost a comment I've said it before and I'll say it again -- it's a funny old world when you come to think about it. Last Friday lunchtime, for example, I received an email from Tim Levell, the editor for ...
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...