Nightly 'bigram' (3250 jsvar) builds for Espruino Board 1.3/1.4

I am now building bigram espruino builds automatically every night (the bigram build is the one to use the full 64k ram 512k flash that the espruino boards seem to have, giving you a total of 3250 jsvars instead of 2600).

These are automatically built in the wee hours of the morning EST and made available at:

http://drazzy.com/e/espruino/bigram

No tests or checks are performed on builds prior to posting them - it is automated. These may not work on all Espruino boards - the manufacturer spec for the chips says they shouldn't work at all - but they seem to work on most boards. So far we have one report of a user who had a board that didn't work with bigram.

Also please read the linked page completely before using these builds.

If you have any problems, first verify that the problem does not occur on non-bigram build, then start a new topic with the word bigram in the subject.

IF YOU ARE USING ANY BIGRAM BUILD FROM BETWEEN 11/12 and 12/28 PLEASE UPDATE - THOSE BUILDS WERE BAD AND DISPLAYED SUBTLY BROKEN BEHAVIOR

Thanks!

Just to add that if you flash these, Espruino will start remembering the code that you saved between firmware updates. If I've changed the way data is stored internally then it can cause Espruino to hang at boot time.

To fix it, just press reset, and hold down BTN1 for a few seconds immediately after releasing reset (but not before or you'll enter bootloader mode with the pulsing blue LED).

Just installed bigram and it works fine.
For a large application I was close to "out of memory" and now I have 1000 blocks free.
Thanks a lot !!!

Updated the index page with some background, as well as link to javascript to clear out saved programs that might cause future versions to not start correctly (after changes to the format of variables stored in flash)

Per https://github.com/espruino/Espruino/blo­b/master/ChangeLog the memory efficiency changes improvement is now in the main branch. Accordingly, bigram builds will have 3250 jsvars instead of 2600.

Y'all may need to use flashclear when updating from earlier bigram builds.

Yes... I'm expecting it may be a while before the next version as I'll need to be sure that nothing is broken by the changes. It'd be great if people can start playing with the latest build and let me know if they find any problems...

@DrAzzy Good news/bad news
I have loaded bigram( Espruino v70) and it seems to work with simple programs but loading my application program "hangs" when uploading to the Espruino.
The only way I can get the command prompt ">" is disconnect/hard reset and then
reconnect.
Note: This application program always worked with the standard Espruino release firmware v69. BTW ... I loaded the new firmware 3 times and used flashclear to no avail.

Hm... the builds work for me (in fact, that's the build I'm using on my desk lamp, which has been working great), and that's not an failure mode I've seen

The v70 on there should be the same as this one - as a reality check, make sure you code uploads on this: http://www.espruino.com/binaries/git/com­mit_date/2014-07-30%2017:00:29%20+0100/

Also, it's worth trying uploading with throttling (though I haven't needed to do that in quite a while). Sometimes I've had to do this though

Also, it could be that you're unlucky and got an Espruino board where the chip has problems in the high 16k of memory? Nobody else has reported this, but it's certainly possible.

Try uploading with throttling

What?

Also, it could be that you're unlucky and got an Espruino board where
the chip has problems in the high 16k of memory?

Is there a diagnostic test that can be performed to detect the chip problems
in the high 16k of memory?

(also edited in more above)
Communication options has a check box for throttling uploads. It makes uploads agonizingly slow, but sometimes fixes problems while uploading code.

Also, I assume you've tried ctrl+c?

espruino.com/binaries/git/commit_date/20­14-07-30%2017:00:29%20+0100/

This firmware link shows 1800 jsvars with v70?

Yes, i used the "control c" to no avail.

I tried firmware/and program throttling still with no change.

Guess I have one of the "bad" chips. Too bad there is not a pre-test that can
be run to see if your bigram can run?

BTW ...Throttling adds the true meaning to slow. (7 mins)

Yeah, that's the normal (non-bigram) build that should be about the same as the build you'd have used.

That's unfortunate, I don't know what to suggest.

Do note that the official github builds now have 2250 jsvars.

There is a test... Use the non-bigram version of the code and do what is described here: http://forum.espruino.com/comments/19893­/

So the firmware you got fromthe espruino.com link above works but DrAzzy's doesn't?

The v70 on there should be the same as this one - as a reality check,
make sure you code uploads on this:
espruino.com/binaries/git/commit_date/20­14-07-30%2017:00:29%20+0100/

quote from @DrAzzy Do note that the official github builds now have 2250 jsvars.

Ok, this "github" v70 firmware code works with my application user code Ok?
Note: The memory still shows 1800 jsvars? <---
Note: The upper ram test came back with the > after a few seconds.

Next test "again" bigram ...

Update ...
Again, I did another 12 minute throttling of bigram firmware link: (http://drazzy.com/espruino/bigram/esprui­no_1v70_08-05_espruino_1r3_bigram.bin)

My application "hangs" after uploading to the Espruino. The only way to revive communications is to disconnect/hard reset/reconnect.
Note: It runs fine on the github v70.

@DrAzzy I can send you a portion of my "top secret" application, for your inspection, but you probably don't have the hardware to run it on.

Sorry - I just checked and that is an old one without the variable size changes. Try this one:

http://www.espruino.com/binaries/git/com­mits/5e9662d82b23dcc7068fd61675860cadd6b­7aebb/

There was a period when the variable sizes were smaller but the variable count was still 1800 - @DrAzzy's link wasn't one of those though!

If the RAM size check didn't give any errors, looks like it's ok. It may well be the variable size changes then.

What errors do you get, or does the code just inexplicably not work?

If you could give us some example code that exhibited the problem then we might be able to fix it.

Sorry - I just checked and that is an old one without the variable
size changes. Try this one:

Again, 2250 jsvars and the "new" link v70 (above) works with my application code.

As for bigram ...My application "hangs" after uploading to the Espruino. The only way to revive communications is to disconnect/hard reset/reconnect.

I will send my "top secret" private application code to an email destination for your
inspection. Just send me a message.

Thanks... Well, if the new 1v70 above works then I'm not sure there's much I can do to figure out why @DrAzzy's bigram builds aren't working with your code... I guess it is possible that the extra RAM on-chip is a bit flaky - or its extra flash (the code I'd linked to before didn't test flash memory).

At least the 2250 var build should help out with your memory problems though.

Happiness is having 2250 jsvars. True happiness is having 3250 jsvars.

Well, the bigram build he tried and couldn't make work didn't have the change in jsvar size either (it wasn't in until the 8/5 bigram build).

Tried 8/5 bigram build "again" today and the program still "hangs"

On/off, for the next few weeks, I will be trying again to see if, by some chance,
"updated Bigram firmware" might work on my chip.

Too bad, if there isn't a reference from my purchased Espruino serial number or markings on the STM chip to ascertain if the chips can take the bigram firmware or not. Better yet, a yes/no diagnostic with flash/ram testing in the upper 16K
For now, I can live with 2250 jsvars.

Let's say if a user needs 3250 jsvars and he wants to buy
an Espruino that has 3250 jsvars. It would be senseless to
purchase an Espruino and find out it can only have 2250 jsvars.
Are there any certified/guaranteed 3250 jsvars "Bigram" Espruinos that can be purchased?

Nope. There are the unsupported boards, some of which have more memory, of course.

The new espruino that Gordon was talking about is going to have 64k ram I think, which would give 3250 jsvars

Yes, I'm in the process of doing a smaller board with a slightly bigger chip on it.

When that's done I'll be seeing if I can do a batch of 'super' Espruino boards with the biggest chip available on them though (96kB).

Did you actually try any of our memory reduction suggestions apart from turning on minification? You can fit a huge amount into even 1800 vars, so if your project isn't fitting then you might be defining something in a way that's taking up a lot more memory than you expect.

I removed all text/comments for code reduction.
There are no arrays (if any, very few) used in the program code.
Simple minification is turned on.

The problem is all the algorithms needed to support my user application are huge. Devices like GPS, two precision RTC (real time clocks), a 4x20 LCD display, a WS2811 dot matrix, an accelerometer and other sensors. I am taking the Espruino to the max of 2250 jsvars.

BTW ... Minification -Advanced Optimisation (not recommended) could get me another 16-17% if it was working?

Yes, Advanced Optimisations are what's produced by the closure
compiler in its 'advanced' mode. Problem is they tend to think that
they can rename absolutely everything, which breaks a lot. I think
someone could potentially write a configuration for it which explained
which things it's not allowed to rename, but I haven't had time to
look into it properly.