Espruino Firmware release 1v70

This one's another big one...

There are a whole bunch of fixes but the main improvements are:

JsVar size has dropped from 20 to 16 bytes on most boards

This means that instead of 1800 vars, you now have 2250 available on the Espruino Board.

Array or Object elements that are smallish integers are stored in one variable

On the Espruino board, this means -32768 to 32767. So now, you've got more variables available and for some structures you also use half as many!

Added E.getSizeOf(...)

If you were (or are still) having troubles with memory, you can now use E.getSizeOf(...) to check out how many of your 2250 variables your structure is using up. It should give you a good idea where you should be focussing your efforts.

For instance the following will list all global variables along with how big they (and all variables referenced from them) are:

for (var i in this) print(i,E.getSizeOf(this[i]))

So overall, if you were having problems with a lack of memory, hopefully you won't any more.

It's a pretty big change, but I (and a few other forum members) have been testing this for a few weeks now. Let us know on the forum if you hit any problems though.

If you're interested in what this actually means in terms of implementation, check out the Performance and Interpreter Internals pages.

my STM32F4 Discovery board was not able to connect to the WEB IDE after reflashing with 1v70. When I went back to 1v69 it worked.
I have not been able to test on my Espruino boards yet, I forgot them at work and I am on vacation this week.

@tage did you try booting with BTN1 held down? Theres a note on the flashing page, but when firmware changes a lot then the saved code from an older version can cause the new version to crash while it is booting.

It doesn't happen on the Espruino board because the bootloader makes sure that saved code gets erased.

Thanks Gordon,
I was not able to press the buttons in the correct sequence obviously, so instead I used ST-Link to do a complete Chip Erase and Sector Erase.
As I was not sure how to proceed after that (the board was not detected by my Win 7 PC any more), I programmed the STM32F4 Discovery board for NETMF following the procedure in http://singularengineer.com/stm32f4-discovery-board-running-net-microframework/
and then re-flashed with Espruino 1v70 and after that the board works fine.

And I also found one of my Espruino boards and managed to update it to 1v70. This board had stopped communicating so I thought it was dead, but it works after I managed to update it. Don't ask me how it was able to connect to the IDE.
I am tinkering with an index table using a 56.4mm (NEMA 23) stepping motor PK268-03A with a digital stepper drive CWD860. The drive has a pulse input and direction input so the Espruino code is a bit different than the example. I am scratching my head over how to accelerate and decelerate in an optimal way, as the motor will have to move a large mass. The motor is connected to the table with a 3M belt with 8:1 reduction.

One strange problem I had was that the stepper drive had the wrong polarity indicated for the DC input, so when I connected a dc power supply to the drive it was current limiting and the voltage was only a couple of volts. the polarity on the drive electronics was wrong. I reversed the power supply leads and the drive worked. Apparently I was the first customer to notice the manufacturing error. The drive is supposed to work with both ac and dc, but the rectifier bridge had been removed and replaced with wires that had been wired backwards. Obviously nobody had tested the drive before shipping it to the distributor. Strange.

Yeah, I've never been able to do the BTN1+reset to boot without loading the stored program either.

Gordon, are you sure that trick still works, and in situations where the Espruino won't start due to stored code from a previous version? I've seen a few threads where you recommended it, but I don't think anyone reported success with it...

It does still work fine. I just made a video so you can see how you need to press the buttons:

https://www.youtube.com/watch?v=N4ueQTHDrcs

But that's for the Espruino Board. Discovery boards don't have a bootloader, so you can skip loading code with them in much the same way that you enter the bootloader in the Espruino Board: press BTN1 + RST, release RST, wait 2 seconds, release BTN1

@tage it'd be better to discuss your stepper issues in a new thread, but check out the highlighted lines in this link. They set the speed of setInterval based on the distance to the target position.

After re-flashing w/ 1v70, pressing reset button crashes Chrome instantly - also just after only connecting. - #chromecrash #crash #firmware #webidecrash #webide

First I thought it was code related, but even with code that ran perfectly before w/ 1v67 crashes happened even in idle mode, and as frequently as never before.

Trying figure out what it was, I I disconnected everything, restarted, made sure that I used the most recent Web IDE - 0.47.1 - it still happened. By 'accident' I pressed the reset, and that made Chrome crash right away. So I just connected, pressed reset: et voila - it crashed... and I can repeat it.

Other items I noticed: sometimes after uploading the code the command pane does not show the completion prompt and becomes unresponsive. Nothing what so ever brings it back to be responding.

More crash details available on request. I'll try to get back to 1v67 - may be I can get around the reset-button-crash... and will post my experience...

Process:         Google Chrome [31835]
Path:            /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
Identifier:      com.google.Chrome
Version:         37.0.2062.122 (2062.122)
Code Type:       X86 (Native)
Parent Process:  launchd [243]
Responsible:     Google Chrome [31835]
.....
OS Version:      Mac OS X 10.9.4 (13E28)
Report Version:  11
.....
Crashed Thread:  11  Chrome_IOThread

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000008
.....
Model: MacBookPro5,3, BootROM MBP53.00AC.B03, 2 processors, Intel Core 2 Duo, 2.8 GHz, 8 GB, SMC 1.48f2
Graphics: NVIDIA GeForce 9400M, NVIDIA GeForce 9400M, PCI, 256 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1067 MHz, 0x859B, 0x435435313236344243313036372E4D313646
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1067 MHz, 0x859B, 0x435435313236344243313036372E4D313646
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8D), Broadcom BCM43xx 1.0 (.....)
Bluetooth: Version 4.2.6f1 14216, 3 services, 15 devices, 1 incoming serial ports
Network Service: xyzLAN, AirPort, en1
Serial ATA Device: Hitachi HTS5....., 500.11 GB
Serial ATA Device: MATSHITADVD-R   UJ-868
USB Device: Built-in iSight
USB Device: Apple Internal Keyboard / Trackpad
USB Device: BRCM2046 Hub
USB Device: Bluetooth USB Host Controller
Thunderbolt Bus: 

----- eoc -----

That's a regression in Chrome introduced in version 37 of Chrome effecting serial in general. Until it is fixed, downgrade to Chrome 36. http://forum.espruino.com/conversations/254907/

...pulling the USB cable while Web-IDE-connected has the same effect: crash of chrome. - #chromecrash #crash #firmware #webidecrash #webide

The hanging of the the command window is though something else: faulty code sent to Espruino, but IDE is not is 'not' detect nor marking. - see #sentfaultycode #syntaxerror #faultycode

@allObjects, yes - I know. Your version of Chrome has auto-updated and broken itself.

Since you can't see the bug I filed (so can't comment on it), can you just file another at crbug.com, and reference https://code.google.com/p/chromium/issues/detail?id=409554.

Google need to get their act together and fix this. It's a nightmare. They can't just auto-update something that starts causing their API to be unusable. Note that I filed the bug BEFORE they released that version properly, so they were aware that they were breaking it for everyone..

Thanks @DrAzzy - I'll downgrade if it gets too annoying. I reported a Chrome bug, because pulling the USB when connected tears everything down as well... I'm stunned that this HW error/exception is not handled in the first place, and second, how safe/secure do I find myself with Apps that can tear down the whole App environment... May be they can silently talk to other Apps running and sniff... This reminds me of the .. Win 3.x times, where Ctrl-Alt-Delete was the universal solution for 'moving on' - I thought 'we' came further along with runtime containers...

@DrAzzy, looks like downgrading can be skipped. Soon 38 will show up as stable: http://forum.espruino.com/conversations/254907/#comment11843402