WP34s&Co. - an internal flashdisk

[pito]

Hi, have you ever considered an internal Flashdisk for storing the programs?

Assuming you have the firmware under your control you may define a simple protocol towards a small flashdisk, connected via the serial (when accessible via your firmware) and you may upload/download programs/data anytime to/from the flashdisk.

For example even a 256kB FRAM - 8 pin SPI device (or any other SPI flash memory), may store a lot of programs (or any other data) for you easily, I guess.

All you need to build the flashdisk is a cheapo low power 14/16pin 8bit mcu (the flashdisk controller), and the SPI flash/FRAM/MRAM chip.

The controller and flash will be placed inside the calculator and will be powered from the internal 3V battery, sleeping all the time, woken up when the serial sends him a command and the controller will then write/return the data required (based on an agreed protocol) into/from the SPI flash. The programs are small, so low baudrate must not be a problem (for example with 4800baud it takes ~5secs to load a 2kB large file into the calculator, but I do assume you may set the baudrate even to 115k2 when using the 32kHz resonator for the PLL).

The CSF here would be the willingness of the developers to provide the stuff for the calculator's side.. The flashdisk controller firmware to create would be a peanut then

[Marcus von Cube]

(06-01-2014 02:31 PM)pito Wrote:  Hi, have you ever considered an internal Flashdisk for storing the programs?
...
The CSF here would be the willingness of the developers to provide the stuff for the calculator's side.. The flashdisk controller firmware to create would be a peanut then

We've a problem here: code space. We could sacrifice some of the library space but an external memory cannot readily replace the internal flash because the latter is directly addressable while the former would either need a store/recall mechanism or a complicated work-around for fetching instructions.

WP 34S is free software. Feel free to resolve the issues and present your results here!

[pito]

Quote:We've a problem here: code space.

I see.. The space is always an issue. My initial thought has been an "XLOAD/XSTORE" to a flashdisk may still fit in. So maybe applicable with your next WPxy..
P.

[Thomas Radtke]

Some battery powered SRAM would be nice for a dedicated platform. Consumes much less power on writing than flash memory and therefore could keep automatically generated (frequent) backups. I.e., opening PRGM generates an image of the current program space. Something like that.

[Paul Dale]

(06-01-2014 02:31 PM)pito Wrote:  Hi, have you ever considered an internal Flashdisk for storing the programs?

Yes we did and using FRAM too. There is no need for a MCU in there, the 30b CPU & circuit board has decent SPI exposed (from memory, might be I2C). It should be possible to page code from the FRAM into RAM and execute it from there. It would be a long and painful path however -- there isn't much RAM.

As Marcus mentioned, there isn't much space for more code in the firmware image. This really is the limiting factor to my mind.


- Pauli

[Paul Dale]

(06-02-2014 08:22 AM)Thomas Radtke Wrote:  Some battery powered SRAM would be nice for a dedicated platform. Consumes much less power on writing than flash memory and therefore could keep automatically generated (frequent) backups.

FRAM is the way to go. Essentially zero standby power, low power to read and write and decent lifetime. A bit on the expensive side but that wouldn't matter in this application.


- Pauli

[pito]

(06-02-2014 08:30 AM)Paul Dale Wrote:  ..A bit on the expensive side but that wouldn't matter in this application.
- Pauli

The FRAMs are getting cheaper- ie. Fujitsu's MB85RS2MT 256kx8 8pin ~$5 single q.
The Cypress' FM25H20 256kx8 is still expensive ~$20 single q.
The exposed SPI is a good news for me (I do not posses the wp34s yet).
PS: with the FRAM you may emulate the sram (the fram is nonvolatile, with "unlimited" endurance, the write is immediate, no delays) - via the exposed SPI and something like 5-10MHz SPI clock you may achieve a decent r/w speed.
The same works with MRAM - ie Everspin's MR25H40CDC 512kx8 8pin, more expensive ~15$ single q., otherwise the same parameters as the FRAM.

[Paul Dale]

(06-02-2014 09:14 AM)pito Wrote:  The FRAMs are getting cheaper- ie. MB85RS2MT 256kx8 ~$5.

It has been a while since I looked. That is expensive for a mass manufacturing process but okay for a hobbiest.

Quote:The exposed SPI is a good news for me (I do not posses the wp34s yet).
PS: with the FRAM you may emulate the sram - via the exposed SPI and something like 5-10MHz SPI clock you may achieve a decent r/w speed..

It will clock up to 40MHz from memory.

Putting the registers in SPI FRAM would work, although you will want the stack in the internal RAM.

You could also put program memory in FRAM, but we're pretty liberal about large memory copies in the firmware. e.g. inserting a program step involves copying the rest of program memory to make space. The CPU in the 30b is very good at memory copies & it helps that there isn't much RAM. Doing this over the SPI bus won't be much fun.


- Pauli

[pito]

I worked with the above Cypress' fram and pic33. With 12MHz SPI clock I did random access r/w to a byte in 7us, to a larger block (ie. 64bytes) in ~1usec/byte.
I do not know what would does mean for wp34s, but with $5 nonvolatile 256kB sram your possibilities are virtually unlimited, moreover, the speed is not too important with pocket calculators, I think..

[pito]

Quote:You could also put program memory in FRAM, but we're pretty liberal about large memory copies in the firmware. e.g. inserting a program step involves copying the rest of program memory to make space.

You may use the fram for user programs, and the arm's sram for the calculator's engine.

It is my understanding you interpret the user code, so reading a random step from fram may take several bytes, that could be done in 5-7useconds/byte via the 10-15MHz SPI, for example.

Reading ~30k user's program steps/sec from the external SPI fram seems to be a good deal provided the actual calculation runs in arm's sram (and takes ~msecs maybe).

Inserting a new step would mean copying (and r/w) of a larger chunk from fram to arm's sram and back - that shuffling could be done in up to ~1usec/byte (a typical 1kB large program can be loaded/stored in 1+1=2ms from/to the fram at above clock).

Imagine 256kB of a nonvolatile sram for user's programs in the wp34s (an $5 upgrade)..

PS: to clarify the weird numbers above:
The serial SPI SRAM/FRAM/MRAMs have an overhead related to the write/read operation, as you have to send the byte's address and commands before the actual write/read of respective byte. In order to write/read a single byte you have to transact 6/5 bytes via SPI bus, to write/read 1000bytes you have to transact 1005/1004 bytes (as the memories feature an "address auto-increment" from the initial address set).