More RAM!

@Sacha - a simpler hack would be to store some information in flash memory. There are a few kb after the bootloader but before Espruino, and those could be used to store information on the expected memory size.

However ideally there would be a run-time check. If I could trap out of range accesses it'd be really easy to run through memory testing it - and if 64kb worked without issue, it'd be used.

Oh yes, your hack is much better...

Sacha

I've been able to build images. But I don't seem to be able to get it to work with the whole 2600 memory units that I should be able to (Right? 1800 + 16K/20 = 1800+800=2600)

I've changed ESPRUINOBOARD.py and Makefile to use the other compiler flag, and to say that the Espruino Board has 64k ram 512k flash and uses the D spec chip.

At 1800 it's fine (of course)
2000 works
2200 works
2300 does not work
2400 does not work
2600 does not work.
Ones that "do not work" flash successfully, and I can connect to them, but the interpreter is inert. Usually it prints the first =undefined, but then nothing else.

If anyone else is interested, they are here:
http://drazzy.com/espruino/

Based on a github pull from a saturday night iirc.

>process.memory();
={"free":2181,"usage":19,"total":2200,"history":11,"stackEndAddress":536917484,"flash_start":134217728,"flash_binary_end":134385324,"flash_code_start":134696960,"flash_length":524288}
> 

Just tried this here - same problem :( If you compile with the debug info in (normal compile without RELEASE=1) you get:

ASSERT() FAILED AT src/jsvar.c:1544
  #2379[r2051,l1] Flags 2

Which seems to imply that the memory is getting corrupted.

I'll try some more tests of that extra memory...

Just tried:

function test(mask) {
  var i;
  for (i=48*1024;i<64*1024;i+=4) {
    poke32(0x20000000+i, mask^i);
  }
  for (i=48*1024;i<64*1024;i+=4) {
    var v = peek32(0x20000000+i);
    var exp = mask^i;
    if (v != exp) console.log("Got "+v+" not "+exp);
  }
}

test(0xAAAAAAAA);
test(0x55555555);

And that seems to work too - so it really looks like the memory is there.

I checked the compile with the extra RAM: the jsVars structure is the correct size and everything appears to get set up correctly... The stack is put at the end of memory (in the 'new' 16kB) so the fact that Espruino can actually spring into life enough to print stuff down USB implies that it works.

In my build, jsVars starts at byte 816, so the first variable that has a problem (2379) is near byte 48396 - well into the 'new' memory - and it's the same on different boards, so it's probably not that the memory is dodgy.

It's a bit of a mystery why it's not working really!

Uh, I have some more bad news. This with 2200 variable Espruino image:

>reset();
=undefined
 _____                 _ 
|   __|___ ___ ___ _ _|_|___ ___ 
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v63 Copyright 2014 G.Williams
>echo(0);
ERROR: Too much recursion - the stack is about to overflow at line 1 col 11
{this.i2c.writeTo(119,b);return this.i2c.readFrom(119,1)[0]}
           ^
at line 1 col 11
{this.i2c.writeTo(119,b);return this.i2c.readFrom(11e,1)[0]}
           ^
in function "read8" called from  

(after which the espruino froze).

This was with the latest desk lamp driver code - but the point is that the code works with the stock 1800 variable firmware, but gets this bizzaro error with 2200 variables. As far as I can tell, it got through loading a bunch of modules, but then when the time came for it to run the connect() method and actually use that code it had cached, it blows up....

I'm becoming pessimistic...

In that case, it looks like you've got the RAM value set back at 48, with the variables set at 2200?

What happens is you've got 48k, with 2200*20=44k of RAM used for variables. There's about 1k of overhead, which only leaves 3k for stack - which gets used up pretty quick.

edit: Just to say that if this isn't the case, it's probably why we have a problem ;)

Right - I'm pretty sure I know what the problem is... Espruino starts in the bootloader - which is the original which still thinks the device is only 48kb - so that's what the stack pointer gets set up to.

Hopefully I should be able to make some tweaks and fix that though!

Ok - all fixed now - pull the latest from GitHub and build again - but not before increasing the number of variables to 2600 ;)

Building...

And happily running my desk lamp code!

=undefined
>process.memory();
={"free":1349,"usage":1251,"total":2600,"history":735,"stackEndAddress":536925508,"flash_start":134217728,"flash_binary_end":134454452,"flash_code_start":134688768,"flash_length":524288}
> 

If anyone else who doesn't have a build environment wants to take it for a spin:
http://drazzy.com/espruino/espruino_1v63dev_espruino_1r3_BIGRAM.bin

Great! Phew, that's a relief.

It's quite nice that it seems everyone's actually got a slightly more capable chip than they thought ;)

DrAzzy! Many many thanks. Will try it out as soon as possible.

Sacha

Wow:

process.memory();
={"free":2581,"usage":19,"total":2600,"history":11,"stackEndAddress":536925508,"flash_start":134217728,"flash_binary_end":134454452,"flash_code_start":134688768,"flash_length":524288}

;) And I also managed - with the help of some people on ST's forum - to figure out a way of checking the RAM without HardFaulting... So this could soon be something that all happens automatically.

Congratulations Gordon!