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
Exactly what made me go for FRAM vs EEPROM... ;-) - recalling the challenges when building hardware where EPROMs needed those even for reading (...with then 'fast' micros: 4MHz Z80).
What are the thoughts regarding the module name and the setup. I could imagine something more on the lines of external memory or just memory - MEMORY, **XMEMORY **, which includes the memory management logic, and it is connected by passing a connected driver for the specific memory attachment.
The memory attachment could be something like OWMsomething, SPIMsomething, I2CMsomething, or even P(arallel)(4..8)Msomething. The something could then be generic or the whole driver name is device specific.
Regarding the API for the MEMORY or XMEMORY, @Gordon's suggestion works for me - or the memory manager API as suggested in response to @Gordon's post - because it is the bare necessity. For performing operations though - such as in graphics where I have the need - the memory manager may be a bit far away from the actual memory access code. What I experienced in writing the the suggested memory management code is the need for 1 byte, 2 bytes, and n byte reads and writes, where 1 byte and 2 bytes operation are more for the int type data and n bytes are string type data. With write() and read() begin the string type - with or without count for the read, I would like to have also write1(), write2(), read1(), and read2() (or alike). Those would then accept any data and take the LSByte(s) from *numeric*s (*int*s) and first Byte(s) from any other reasonably suitable data type, and would return int. Furthermore, with smart arranged data in the memory, a first read with giving address could be followed by subsequent read that does not need passing the address again: read() with no argument. Furthermore, the API with writing without passing size(limit) and reading with size for bare metal operations looks to me as inconsistent. A write without limit is quite dangerous... I agree that matter on fact/nature of being on a micro everything is dangerous, that was the reason that my memory manager goes with the write() without size/limit for a dynamically managed memory space with garbage collection. I adds more complexity, sure, but it is a more robust/safe place. The passed address is therefore not the actual data area address but the address of the pointer to the data area. Adding an optional size argument in the bare metal write would solve the 'issue'. Even with the bare metal operations hidden behind/in a memory manager, the shining through of some of the operations - such as the read/write of 1 or 2 bytes and related data typing is very useful for application code.
In the memory manager I used the notion of datatype. Currently I'm only supporting (assuming) string data, because that's what I needed (and took the extra app work to convert any other data types first into and afterwards from strings). The most other data type is key-value pair - with key a string, and value what ever will be supported. Beyond the string and int data type though, the bare metal should - and obviously does already - not care about.