Post Reply 
How does flash memory work on wp 34s?
05-10-2018, 09:46 PM
Post: #1
How does flash memory work on wp 34s?
It seems like there is potentially more memory available to store programs in flash. There is a conservative limit of 10,000 flashes before the FM fails.

I assume you can call user functions from flash memory (without having them stored in ram? Because prebuilt programs in the FM catalogue appear to work that way), but should you? Is the 10,000 limit only for writing to the FM? how many reads can the drive handle? Are there any kind of programs that should not be stored to flash?

Basically I'm in the process of designing and testing a program that has three built in MISO solvers. Would this type of program be a good candidate for FLASH storage?
Find all posts by this user
Quote this message in a reply
05-11-2018, 02:06 AM
Post: #2
RE: How does flash memory work on wp 34s?
Reads have negligible (essentially zero) effect on flash content. Once you reach the point where the code is stable and unlikely to change, you can save it to flash.

~Mark

Cui Bono?
Find all posts by this user
Quote this message in a reply
05-11-2018, 03:39 AM (This post was last modified: 05-11-2018 03:40 AM by burkhard.)
Post: #3
RE: How does flash memory work on wp 34s?
(05-11-2018 02:06 AM)mfleming Wrote:  Reads have negligible (essentially zero) effect on flash content. Once you reach the point where the code is stable and unlikely to change, you can save it to flash.

~Mark

Yeah, I wouldn't worry about reads. Virtually every car engine worldwide sold in the last couple of decades (hundreds of millions of them) runs on ROM that's physically stored in flash. There are gobs and gobs of reads to those addresses occurring every 10ms or faster the whole time the engine is running.

Even reflashing for your own development is pretty safe. I wouldn't worry about that 10,000 limit, (which is a spec. minimum—the real figure is probably much higher). In my job, we flash modified software to controllers many times during its development. I don't recall having one ever with the flash that got "used up". Not saying it can't happen, but using it the way it is designed; it is pretty robust.

What I wouldn't do is make code the itself repeatedly writes to flash as a scratchpad or otherwise treating it as RAM. That is what real RAM is for. But storing programs (especially mostly completed, stable ones) is no problem.
Find all posts by this user
Quote this message in a reply
05-11-2018, 11:54 PM
Post: #4
RE: How does flash memory work on wp 34s?
I'm in agreement. Reads cost nothing (except a bit of time). Writes are the limitation.
Thus, store your programs in flash and run them at will.


Pauli
Find all posts by this user
Quote this message in a reply
05-12-2018, 12:08 AM
Post: #5
RE: How does flash memory work on wp 34s?
Is it even possible to have a program store variables to flash memory?

If you execute a program from FM with the command STO 00, the calculator would always store the number to the 00 register on the ram? (In contrast to the 00 register on the FM?)
Find all posts by this user
Quote this message in a reply
05-12-2018, 01:04 AM
Post: #6
RE: How does flash memory work on wp 34s?
(05-12-2018 12:08 AM)gomefun2 Wrote:  Is it even possible to have a program store variables to flash memory?

With a processor having a Harvard architecture (separate data and program address spaces) the answer is (a qualified) no. That architecture usually allows reads from flash to access constants in a table, but not direct writes.

Microchip had a routine for its PIC processors that allowed a program in RAM to erase and rewrite a block of program flash so it could simulate EEPROM. The program had to be in RAM of course because a program in flash would no longer be able to access itself once the flash erase/ update process began!

~Mark

Cui Bono?
Find all posts by this user
Quote this message in a reply
05-12-2018, 02:08 AM
Post: #7
RE: How does flash memory work on wp 34s?
(05-12-2018 01:04 AM)mfleming Wrote:  Microchip had a routine for its PIC processors that allowed a program in RAM to erase and rewrite a block of program flash so it could simulate EEPROM. The program had to be in RAM of course because a program in flash would no longer be able to access itself once the flash erase/ update process began!

~Mark

A bit off topic, but some PICs and I suspect other controllers can write over the top of the code that is actually doing the writing. The MultiCalc software did this for awhile until I needed to change things. The trick is that the new code, once written, does not affect the required execution in any way. The PICs will stop executing code once the write process has begun, then continue on as normal at the current PC value when the write has completed.

If lots of write cycles are required for a flash system, then if possible, it is best to use a block pointer to move that data to different areas of memory to spread the load. The memory will last longer.

cheers

Tony
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)