• It is more a memory manager with garbage collect for storing/retrieving/updating strings... it could certainly be tuned to the needs of a page oriented thing. I was thinking of it when reading @tve's post. The issue though is that the way it is built, a flash would wear out quickly. It has a pointer system for free space and freed space management that is updated on most of the writes... too much of updates for a flash. I had started it for MRAM/FRAM where no page limitations are and no real wear out. For a flash, it gets a bit more complicated, because the free space would have to be managed with bit lists (ribs - 1 bit per n bytes block)... reference to mm.html in conversation about New EEPROM module names/AT EEPROMS with an emulation / cross-implementation for developing the logic... some more explanation and rational in the conversation about Running code off of an EEPROM - includes screen shots of usage example and explananation what's goin on in the memory (all in the cross-context / browser), where visualization is easy to show what is going on.

    To apply the memory manager for flash would require:

    • convert pointer/chained blocks system to bitlist for free space
    • take page constraints into account (only update 'in one direction' (go for a new page or rease it before rewrite...)

    Not that simple... may become slow, and is still not holding up for frequent use.

About

Avatar for allObjects @allObjects started