I guess that for most applications those are not serious tradeoffs. Also, you need to configure wait states if the clock is running faster than 8 MHz. Also, there needs to be 10us after coming out of some sleep modes before you can save again to FRAM. Saving to FRAM takes more energy than RAM. (Or on the MSP430, just keep them there.) There are some power usage costs. So you could dump variables stored in static RAM into FRAM. You might be asking, what is the point of that? Well, the upside is that FRAM stores data when the processor goes into its deepest sleep (LPM5 I think). Each time you re-load the code, it gets wiped out. The PERSISTENT pragma works out of the box, but it has a gotcha. It would be effortless to have an array that overruns into another memory location. The idea is that if something terrible happens, the locked FRAM is not accidentally overwritten. Locking and unlocking the FRAM is a quasi-optional step. In this example, I am just incrementing the value each time the program runs. Accessing variables that exist in FRAM is no different than variables in RAM. Lines 04 enables writes to FRAM, while line 06 disables the writes. (In this example, it is set to 0.) A linker command file defines that memory space. The variable initialization is similar to initializing a variable in RAM.
Lines 01 and 02 set up the variable "var." The pragma PERSISTENT tells the compiler that it needs to locate the variable "var" in a specific memory space.
0 kommentar(er)
