• I had re-flashed to 2.00

    Are you uploading the exact same code you did with the exact same firmware when it worked?

    The compiler shouldn't be an issue - it was a config problem on the server but the compiler itself didn't change.

    If you were to 'save on send' to 'direct to flash' that would give you a bunch more available memory. If you'd had that on before, and had changed it back, that would have broken things.

    I should add that it's not just that saving to flash gives you more memory, but it also doesn't save the function declarations to the command history, which means there's far less fragmentation.

    Stack

    Espruino doesn't allocate variables on the stack - they're all in one chunk of statically allocated memory. stackEndAddress really isn't a useful number for you to look at.

    E.getSizeOf()

    This scans the whole variable and everything it links (like if you ran trace(var)) - it's showing you the size of the object, all variables, all functions, and even any variables/functions in scopes that those functions were defined in.

    When you go down a level to output data, you might have two functions that are defined in the same scope. Both of those functions will bring in the same scope so will be more or less the same (huge) size.

    Is running process.memory() even needed as the board is just powered up, and the first initial 'send' is performed before any other tasks?

    Yes - because the act of sending (which is creating loads of functions and even executing them) can fragment memory.

    process.memory().free

    It's most likely fragmentation - especially as you're using over 2/3 of your memory. The quick explanation is:

    Unfragmented:  
    "XXXXXXXX        "
    allocating "XXXX" in one long chunk is easy
    
    Fragmented:  
    "X X X X X X X X "
    allocating "XXXX" in one long chunk can't be done
    

    In both cases there's the same amount of free memory, and the same amount used.

    This is one of the reasons I suggest that you just leave Espruino to do its own thing. If you created arrays the normal way:

        this.ad = new Uint8ClampedArray(256);
        this.ar = new Uint8ClampedArray(nArySizeRGB);
        this.ab = new Uint8ClampedArray(nArySizeRGB);
        this.ac = new Uint8ClampedArray(nArySizeRGB));
        this.af = new Uint8ClampedArray(nArySizeRGB);
        this.ag = new Uint8ClampedArray(nArySizeRGB);
    

    Espruino would automatically allocate flat strings for all those arrays, except if it couldn't find a big enough block of memory - in which case it would just allocate a normal String and continue perfectly fine, just a little bit slower.

    Of course if you are trying to write C code to access the raw data as a char array then you'll hit problems - but if you're using compiled JS or just normal JS you'll be fine.

  • Topic: Flat Strings

    Big mis-understanding here.

    I read (four months ago) 'New Espruino IDE Posted on Wed 14th, February 2018':

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

    Which caused me to post back in Oct

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

    From #2

    'So in your case, your arraybuffer just isn't big enough that it makes sense to allocate it as a flat string. Make
    it size 32 or something and it'll work.'

    and #3

    'what I suggest (E.toString) is actually . . . so that would be a good starting point.'

    and #2

    'you'll find E.toString is much more reliable at creating flat strings.'
    'I'd suggest the little known hack of E.toString({data : 0, count : NUM_BYTES})'
    http://forum.espruino.com/conversations/­316409/#comment14077573

    The third example in #1 at:

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

    that and comments in other posts led me to believe that the technique shown was to use E.toString() when making the arrays because of the size required. [900 bytes] The goal was to have fast sequential and random array access to output within setInterval()

    What is happening is that when arrays are small <8 elements, code execution (Javascript only) is acceptable. When creating larger arrays, >32 elements, code execution gets progressively and perceptibly slower (when using setInterval()) as array size increases. In order to access the largest 5 meter Neopixel strips will require array sizes of 900 elements. [60 neo/m * 5m * 3rgb] I have a design/speed reason(s) to stay away from Uint24ClampedArray

About

Avatar for Robin @Robin started