Espruino 1v88 released

This one's a massive release - containing a whole raft of improvements that were originally developed for Puck.js - which will be going into production early next week!

You can check out a full list of improvements here but in summary - and with a bit more info:

ES6 additions

• ES6 Template Literals - the following kind of stuff now works, so could really tidy up service webpages:

  for (var i=0;i<5;i++) 
  console.log(`No.${i} Hello World, even ${i*0.25}`);
  

• ES6 Arrow Functions - this'll keep a lot of JS developers happy too. For instance:

  [5,6,7,8].map(x=>x/2)
  // or
  ["Foo", "Bar", "Baz"].filter(a=>a[1]=="a")
  // or
  [5,6,7,8].sort((a,b)=>b-a)
  

• Promises now work pretty well too, and are used in Puck.js's BLE Central Mode API. Chaining works great, as does catching exceptions thrown inside promises. They even work with arrow functions:

  new Promise((resolve,reject) => { resolve("Wohoo!"); }).then(
  a => { console.log(a); });
  

(Sadly none of the above made it to the micro:bit, as it's just too short on Flash/RAM at the moment. They're in the Original Espruino, Pico, Wifi, and Puck.js though)

Improvements

• Tab complete now offers a much better set of completions, and spaces them out nicely if they're too long
  
• Add 'opendrain_pullup' pinMode (including emulation on STM32F1)
  
• Make OneWire use opendrain_pullup (so no resistor is needed for short runs on OneWire now)
  
• Add Software I2C (with opendrain_pullup, so it doesn't even need resistors)
  
• Tweak VGA output back porch to 2ms (so leftmost pixels always on screen)
  
• Added E.lockConsole() for use with E.setPassword()
  
• Allow padding to be specified as 3rd argument of JSON.stringify
  
• JSON.stringify now dumps typed arrays as arrays - while not according to the spec, this can be really helpful
  
• Add Third option to pinMode to allow the pin mode to be set while keeping it 'unforced'
  
• save() and dump() now keep track of whether pin mode had been forced or not
  
• fs.readFile (and File.read) now use Flat Strings to allow more memory efficient reads
  
• LED + BTN definitions now autocomplete
  
• Loads of fixes/improvements to the BBC micro:bit's BLE
  
• Some internal variables are now freed if they're undefined (saving memory)
  
• Console now prints the type of Objects if their constructor is in the root scope - eg new Bob() => "Bob {}"
  
• Exceptions now ave a 'stack' attribute if they can have children. This means you can use process.on(uncaughtException, ...) to catch exceptions along with the exact place in code that they happened
  
• Ctrl-C on micro:bit now works great - and breaks out of execution
  
  

Fixes

• Fix emitting of events with long names
  
• Ensure 'af_opendrain' pin mode gets remembered when saving
  
• Fixed memory leak when automatically converting a simple object to a String
  
• Cope with new escape codes for home and end on Ubuntu 16.04 (27,91,70/72)
  
• Fix 2 concurrent waveforms on different pins
  
• Fix STM32 regression where pinMode was set when it shouldn't have been
  
• Fix Espruino WiFi's timing issues (also applies to F4 with added LSI crystal)
  
• When moving console before printing has started, move all buffer contents as well
  
• Fix regression where replacing a function starting with 'return' with another would cause errors
  
• Fix switch fall-through to default
  
• Added E.dumpLockedVars() in non-release builds to help debug memory leaks in libraries
  
  

So loads of stuff... Sadly I had to remove the VGA/TV output from the Original Espruino to make room for it. It's still in Pico/WiFi boards though - let me know if you were using it on the Original board and I'll see what I can do to get it back in (however I don't think it has ever been used!).

There'll also be a new Web IDE release coming soon too.

great!

Updated a Pico to 1v88, with the new editor.
I tested the first example in the released.

I had to put {} in the for loop, and it show faults in the right editor

1 Attachment

Yes - the editor itself isn't expecting any ES6 functionality. That was updated on GitHub today (so wouldn't be in the version that you have to test with). Espruino itself should be fine though.

Talking about promises, I just got this error message:
Uncaught Error: Unhandled promise rejection: Error: Function "b" not found!
Does it means that we absolutely need at anytime to give both resolve AND reject callbacks?
Is it possible that it worked with 1v87.XXX but not anymore with 1v88 ?

@Jean-Philippe_Rey what code did you paste in? The character b isn't even in the example code, so I guess you tried some different code?

new Promise((resolve,reject) => { resolve("Wohoo!"); }).then(
a => { console.log(a); });

@Gordon I tried the method getStatus() of the module RN2483 (LoRa)
https://github.com/espruino/EspruinoDocs/blob/master/devices/RN2483.js#L61

>lora.getStatus()
["sys get hweui\r\n"
=undefined
] "AAAAAAA" <--- "AAAAAAA"
] "AAAAAAAAAAAAAAAA\r\n" <--- "AAAAAAAAA\r\n"
["sys get vdd\r\n"
] "3" <--- "3"
] "3233\r\n" <--- "233\r\n"
["mac get appeui\r\n"
] "0" <--- "0"
] "00000000000000" <--- "0000000000000"
] "0000000000000000\r\n" <--- "00\r\n"
["mac get deveui\r\n"
] "0" <--- "0"
] "AAAAAAAAAAAAA" <--- "AAAAAAAAAAAA"
] "AAAAAAAAAAAAAAA\r\n" <--- "AA\r\n"
["mac get band\r\n"
] "8" <--- "8"
] "868\r\n" <--- "68\r\n"
["mac get dr\r\n"
] "5" <--- "5"
] "5\r\n" <--- "\r\n"
["mac get rxdelay1\r\n"
] "1" <--- "1"
] "1000\r\n" <--- "000\r\n"
["mac get rxdelay2\r\n"
] "2" <--- "2"
] "2000\r\n" <--- "000\r\n"
Uncaught Error: Unhandled promise rejection: Error: Function "b" not found!
> 

It's because it got right to the end of lora.getStatus() and tried to call the callback function, which doesn't exist because you didn't specify it.

Try lora.getStatus(console.log) :)

Unfortunately the module gets minified, so what would have been a helpful variable name like callback just gets turned into b...

ooooh that's totally true. I ever forget to give it the callback :-/ sorry for wasting your time with such beginners issues...

No problem - you had me panicked for a while ;)

Flashed the 1v88 version onto several original Espruino 1.3 boards resulting in just the red LED on reset.
One worked on reset but reverted to the red LED when powered down and then back up again.

I tried it with both the web IDE and command line.

1v87 works on all the boards.
1v88 works fine on the Picos

Jamie

Ok, thanks for letting me know - I'd tested it quite recently, but obviously not with the release version! I'll see if I can get that sorted tonight.

edit: That's a really odd bug- as you said, just tried here and my board worked great at first, even after a reset - but failed after a power off and on. It possibly explains why it passed the quick test I did before releasing.

Ok, try again now. I've found the problem and updated the Original Espruino's image with the fix.

Turns out it was to do with the Low Speed oscillator. The F1 behaves very slightly differently to the F4, and the startup code got stuck waiting for the RTC to initialise - unfortunately if you previously had a good firmware on the device then when you put the new one on everything will keep working until you power it off (as the RTC is already set up).

That did it.
I initially assumed the board wasn't getting updated properly as one did work.
Just for reference; there is a 32.768kHz crystal on the original Espruino boards I tried.

Excellent work. Thanks Gordon.

Further to this; after leaving the boards powered down for some time they again did not reset properly.

As mentioned I have 32.768kHz crystals connected to these three boards but I do not have the 12pF caps mounted since they all worked fine without them.

However, if I hold my finger over the 32.768kHz crystal leads they do reset properly and also reset properly if left powered after the initial successful boot.

So it seems they may now require the capacitors. I will update this post when I dig up some appropriate caps.

after leaving the boards powered down for some time they again did not reset properly.

...even with the new firmware? and it was fine on the older firmware?

I've tried on the 1v4 boards and they seem fine (crystal + capacitors). It's possible that without capacitors the oscillator ran for a bit and then stopped, and it's causing that function to get stuck somewhere else waiting for the RTC to respond.

Do you have any advice for building these on windows using Vagrant for the NRF52832DK? I have tried out the current vagrant setup but believe the version of arm-none-eabi-gcc it installs in the provision.sh script may not be compatible with the current master branch?

https://github.com/espruino/Espruino/blob/master/scripts/provision.sh

From what I can tell based on this link:
https://travis-ci.org/espruino/Espruino/jobs/175343830

you are building with the current version:
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]

Right now on gcc-arm-none-eabi-4_9-2015q1 it mostly works but fails at the end with this:

GEN espruino_1v88.180_nrf52832.lst
GEN espruino_1v88.180_nrf52832.hex
Merging SoftDevice
scripts/hexmerge.py /vagrant/targetlibs/nrf5x/components/softdevice/s132/hex/s132_nrf52_3.0.0_softdevice.hex espruino_1v88.180_nrf52832.hex -o tmp.hex
make: scripts/hexmerge.py: Command not found
make: *** [espruino_1v88.180_nrf52832.hex] Error 127

@Gordon
Yes, even with the new firmware.
I've tried it with 7pF caps on (the closest I have at the moment) with the same result.

Espruino 1v87 (using the binary from the website) has started up fine so far after numerous unpluggings etc. It reverts to start up problems when 1v88 is flashed on again.

Also, with 1v88 loaded the web ide has trouble connecting:
something like "Can't find STM bootloader"

Edit: An Espruino 1.3 without a crystal works fine with 1v88.

With 1v87 it appears that holding my finger on the crystal leads actually STOPS the LSE from starting up, possibly because it does not detect the crystal.

With 1v88 it seems to detect the crystal and attempts to use the LSE even though it hasn't started up.

Checked with peek32(0x40021020), RCC_BDCR register, after reset.

Okay I figured out my own problem :)
on line 2080 of makefile

	@echo FIXME - had to set --overlap=replace
	python scripts/hexmerge.py --overlap=replace $(SOFTDEVICE) $(NRF_BOOTLOADER) $(PROJ_NAME).hex -o tmp.hex

and line 2086 of makefile

	python scripts/hexmerge.py $(SOFTDEVICE) $(PROJ_NAME).hex -o tmp.hex

I had to add the "python" preface which was missing before the call to hexmerge.py - this fixed the merging problem.

Also to fix the vagrant setup problems I changed the provision.sh by adding the top three lines and commenting out the lower ones.

sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
sudo apt-get update
sudo apt-get install gcc-arm-embedded
 
# download known working version of arm-none-eabi-gcc
[#sudo](https://forum.espruino.com/search/?q=%23sudo) mkdir ~/gcc-temp
[#cd](https://forum.espruino.com/search/?q=%23cd) ~/gcc-temp
[#sudo](https://forum.espruino.com/search/?q=%23sudo) wget https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q3-update/+download/gcc-arm-none-eabi-4_8-2014q3-20140805-linux.tar.bz2
[#cd](https://forum.espruino.com/search/?q=%23cd) /usr/local
[#sudo](https://forum.espruino.com/search/?q=%23sudo) tar xjf ~/gcc-temp/gcc-arm-none-eabi-4_8-2014q3-20140805-linux.tar.bz2
 
# apply setup config to add compiler to PATH
# from stackoverflow i.e http://stackoverflow.com/a/28279205

I also edited the vagrant_setup.sh to include the correct path to new version of gcc-arm-embedded

export PATH="$PATH:/usr/local/gcc-arm-embedded/bin/"

I am not sure this is all correct but when I upload hex files for the NRF52832DK they now show up as bluetooth devices and some basic commands work :)

You can see the changes on my fork of Espruino here https://github.com/espruino/Espruino/compare/master...clowrey:master

@hilo90mhz Thanks for that - looks like vagrant probably hasn't been used in a while (I think most people just build directly on Linux)

@jlawson strange - there was another change in there that I can remove as well. I'll give it a try on some 1v3 boards here.

Ok, I've just produced a new build (It'll be at http://www.espruino.com/binaries/git/commits/b4edf13c51c825ca8ed032d7e31dec7a2759a20f within the hour). Could you try that? I've just removed all the RTC code changes that were there for the F1, so all being well it should behave exactly the same as 1v87.

@Gordon - the link is broken but I have rebuilt the latest pulled version here.

Works on three Espruino 1v3 with the LSE running and also with the finger stopped LSE.
These boards all have a 32K crystal but I will try it on a bare 1v3 later.
Thanks again.

Ahh - thanks for letting me know - looks like after the server move my build machine stopped uploading the builds. Hopefully it'll be fixed soon.

There's a regression in 1v88 I found today that I'd like to get fixed, so I'll push out a proper 1v89 build soon anyway I think.

@Gordon, for an original Espruino board (v1.4b) running 1v89, code entered right after a reset of an example right out of Mozilla Developer Network Arrow Function page ...

var max=(a,b)=>(a>b)?a:b;
max; // returns function (b) { native code }
max(4,6);  // hangs indefinitely???

Hangs, and usually eventually generates an out of memory error message.

function max(a,b) { return (a>b)?a:b; };  // works fine