You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
I understand... so we go after exactly the same problem... ;-)...
The details about the FRAM chip and its feature are described at the bottom of the very first post of the thread.
My problem raised from the fact that Espruino has quite limited memory. In my case I wanted to write a calibration / recalibration function for the resistive touch screen. Calibration is done by placing graphical X's in - for example 20 x 20 px - squares in all four corners and the center of the display and have the user to tap them. Based on the read resistances and the given screen size the, the mapping x/y-resistances of the touch screen to the x/y-coordinates of the display is adjusted. Before writing the X markers, the current display buffer content has to be saved and after using the X markers restored. On a ILI9341 controller - with 262K colors - each pixel uses 16 bits: 5 Red, 6 Green, 5 Blue. For 5 markers of 20 x 20 px square, 5 * 20 * 20 * 2 = 4kBytes - at least - have to be saved and restored (see post of Resistive Touchscreen directly (no touch controller) thread). It is 4kB when hving packed the color bits into tow bytes with shift/unshift/mask operations for the storing and using. Using one byte for each color makes the processing simpler, but the amount of data grows by 50% to 6kBytes.
In one of my code versions I show one calibration X and square after the other to reduce the amount of bytes to 400 respective 600 bytes at a time. I didn't want to put aside 600 bytes just in case for a user wants to recalibrate the touch screen, because some of my apps in which I planned to use the touch screen, have already run out of memory without that UI component imbedded... so I was thinking about a temporary storage. Of course, there are also savings in these apps by breaking them up into modules and load them minified. Btw, this approach of creating modules is helpful regarding memory consumption reduction in all apps, with the downside of running out of Google closure compiler services, which are a part of the IDE's uploading to the board (see too many compiles performed recently. Try again later).
I knew about serial EEPROMs, but knew also about the EEPOM limitations and cumbersome page writing. This made me look for some serial RAM, since I did not need the persistency aspect. Just by accident I stumbled on FRAM/MRAM technology. Even though - as just said - I did not need persistency, I liked it, because it would give me both: fast unlimited, simple RAM like read and write, and at the same time persistence, for - for example - storing any dynamic configuration... So I got myself 2 chips... of which one I fried after I just got it working :(((8888 . So I unsoldered the 1st one and soldered the 2nd one and rewired it and it working ever since.
I was asking for compatibility, because the the FRAM commands include EEPROM unique commands for the possibility to replace EEPROMs w/ FRAMs without having to change the driver software. This must have been a very early though, because EEPROM's capacity and capacity by price left FRAMs/MRAMs technology in the dark - especially FRAM. For MRAM it looks a bit better, but I could only find large capacity chips with Ball packaging... even though http://www.everspin.com has also 256Kb SMT chips - to mention the smallest. Btw, there are various parallel interfaces to these chips as well as the SPI interface... with a serial speed up to impressive 40MHz - no wait states in any operation.
With a FRAM chip working, I began the development of a memory manager - the (string) object store - which allows storing and retrieving strings in the serial FRAM. To not get lost in the details right from the beginning and slowed down by always pushing to the board, I developed a code reference model in the browser in javascript with visualization... which I attach to this post and you can play with in a browser. It is a single html file with embedded javascript. The nice thing is that the memory matrix and its content is displayed with a color scheme to see what is going on. In the code, the bare metal is to the left, and the visualization code is to the right about half a page indented. For now I have some happy paths, nothing optimized yet, and no error messaging... My plan is to move that later onto Espruino with the low level things into assembler/compiled functions.
Basically, the memory has 3 segments:
When segment 2 and 3 touch each other - in other words - memory rans out of new space on attempt of storing an object, a garbage collect of segment 2 happens with the hope to reclaim not anymore used space and complete the store operation. If after garbage collection there is still not enough space, the storing process ran definitely out of memory.
Usage example of the high-level browser app as implemented in the attached html file:
Step 1. After loading you see a - (shot) S01:
It shows a memory of 256 bytes / cells in 16 cols / 16 rows. The first 10 bytes are 5 double byte values are the memory descriptor, which describes the configuration and current usage of the memory.
@ 0000: 000A - length of the descriptor in bytes
@ 0002: 0100 - size of the memory (addr of last byte + 1) and begin of pointer heap
@ 0004: 000A - addr of first free byte for object storage / object data heap
@ 0006: 0100 - addr of last used object pointer / object pointer heap and object id
@ 0008: 0000 - addr of last freed object pointer (begin of chain of freed object pointers)
Step 2. After storing (writing) the first string - ABCD - to the memory - S02:
Enter a string ABCD in the Value field and press write button.
The store operation returns the object's id 00FE in the memory in ID, with which it can be retrieved, updated, and deleted.
(Check of space to trigger already implemented garbage collection and out of memory detection not yet implemented. They are the next thing).
@ 0004: 0013 - addr of the 1st new free byte for object storage
@ 0006: 00FE - addr of object pointer and object id as returned by the write operation
@ 000A..0012 - stored object containing the string ABCD and admin information
@ 000A: 00 - 1 byte object type: 00 = String (for now only strings are handled)
@ 000B..000C: 0006 - 2 bytes length of the String + 2 (includes the 2 bytes of objecte pointer, see 000D..000E)
@ 000D..000E: 00FE - addr of object pointer and object id (used for sweep in garbage collect, can be used for validation of obj addr on access with 1/65536 error probability)
@ 000F..0012: A B C D - the actual object value / string
@ 00FE: 000A: addr of object data at object pointer address / object id
Step 3. After storing (writing) a second string - efghijklmn - to the memory - S03:
Enter a string efghijlkmn in the Value field and press write button.
The store operation returns the object's id 00FC in the memory in ID, with which it can be retrieved, updated, and deleted.
@ 0004: 0022 - addr of the 1st new free byte for object storage
@ 0006: 00FC - addr of object pointer and object id as returned by the write operation
Attachements:
5 Attachments