• try this on the left side:
    reset();

    then upload via ide, see if starting from a clean interpreter state makes a difference (This is usually the default in the IDE settings to reset first.

    Q: How much in bytes is the actual space indicated by 'free'

    it's not bytes but jsvars....

    Q: How large are these blocks re: total 1700

    So you have 1700 jsvars free

    Q: What is the relationship between the total blocks 1700 and used bytes 12284

    12284 Bytes is the number of chars in you javascript source.

    Q: Are comments stripped from the source before 'Send to Espruino'? e.g. are they counted in used byte count?

    It depends ;-) The position of the comments is a factor if they 'take up space' - I can't recall the details
    This is why modules get minified before upload to strip comments and shorten any externally referenced variables.

    Q: Why couldn't I save this code block despite having ample free space?

    The ESP8266 is pretty strapped for space. It really is quite limiting.

  • Thr 2017.02.23

    Thank you for your responses to each of my questions:

    What is the relationship between the total blocks 1700 and used bytes 12284 - 12284 Bytes is the number of chars in your javascript source

    What I was after was total used space of 1700 blocks. @Wilberforce your comment 'So you have 1700 jsvars free' allowed me to do a Google search on the needed concept of 'jsvar' which turned up additional detail.

    http://www.espruino.com/Internals

    Variables are usually stored in fixed-size 16 byte blocks. In small devices this can get down to 12 bytes (10 bit addresses) and on PCs it's 32 bytes (32 bit addresses)

    Which then led to:

    http://forum.espruino.com/conversations/­276825/

    As a rule of thumb, expect to be able to store 12 characters for each 'JsVar' reported by process.memory, so if you have 5000 variables then that's 60,000 characters.

    ----snip from above #1

    The offsets from an ESP-12 allow for 0x3FFF or 3 * 16 * 256 = 12288 bytes which I can see is used for the 12284 value
    0x3FC000
    0x3FE000
    0x400000

    and performing the calculation: 1700 * 12 = 20400 which exceeds the physical capacity of 12284 actual bytes alloted. On to 12288 / 12 = 1024 a rough approximation on the number of 'jsvars' that will fit in the available memory.

    Author note: Still would like to know why 1700 is the magic limit

    Writing............
    Compressed 27200 bytes to 9390
    Checking...
    >process.memory()
    ={ "free": 761, "usage": 939, "total": 1700, "history": 1 }
    >
    

    So, my take on this is, before minification, the environment can temporarily work with more code as it is unknown what the minification process can compress down towards. Looking at the process.memory() 'usage' argument can only approximate whether the current source code will fit. Since our base 10 is close to the 12 multiplier, one could approximate the save success probability by multiplying the 'usage' value by 10 and if that is below 12284, be reasonably certain of a successful save(). As a precaution, this implies one needs to be really observant as the 'usage' argument approaches 1000.

    Note that individual mileage may vary. ;-)

About

Avatar for Robin @Robin started