Just tried it here on an official board, and on a Linux build with restricted vars and it works great.
In the function - calling f=process.memory().free; seems to work. All I can think that is occuring here is it perhaps a garbage collection is occuring
Calling process.memory() will cause a garbage collection (in fact process.memory().gc tells you how much got freed).
It looks like the filesystem stuff needs a flat array and is unable to find a large enough flat memory space for it... It is possible it's because of a memory leak...
If it were something that wasn't unlocked you wouldn't expect the behaviour because GC wouldn't be able to free that, but if it were something that was referenced and not unreferenced then that could be it (but it's unlikely as it's very rare that anything outside of core touches references).
OR... it might be because when you use the FAT filesystem on ESP32 the allocation units are 4k? That means each file ends up being quite big.
I guess if there isn't much free RAM available then the data area might get too fragmented to allocate a 4k block of data after a while. I guess by the time GC actually runs, it's too late.
Running GC manually will automatically re-order the free-list, which makes it significantly less likely that things get fragmented in the first place.
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.
Just tried it here on an official board, and on a Linux build with restricted vars and it works great.
Calling
process.memory()
will cause a garbage collection (in factprocess.memory().gc
tells you how much got freed).It looks like the filesystem stuff needs a flat array and is unable to find a large enough flat memory space for it... It is possible it's because of a memory leak...
If it were something that wasn't unlocked you wouldn't expect the behaviour because GC wouldn't be able to free that, but if it were something that was referenced and not unreferenced then that could be it (but it's unlikely as it's very rare that anything outside of core touches references).
OR... it might be because when you use the FAT filesystem on ESP32 the allocation units are 4k? That means each file ends up being quite big.
I guess if there isn't much free RAM available then the data area might get too fragmented to allocate a 4k block of data after a while. I guess by the time GC actually runs, it's too late.
Running GC manually will automatically re-order the free-list, which makes it significantly less likely that things get fragmented in the first place.