Espruino 1v86 release

Posted on
  • This one's been a while coming, but it's got a few nice additions/fixes:

    E.setBootCode and flash execution

    You might have noticed the Save on send option in the Web IDE - this uses E.setBootCode to save your code as-is to Espruino's flash memory. It's then executed straight from read-only memory and any functions you define are kept in flash.

    While this actually uses up more flash memory than the normal (compressed) arrangement, it can save you a lot of RAM.

    Promises

    Espruino now has a 'Promise' library built-in on all but the most constrained platforms - so stuff like this now works:

    new Promise(function(resolve, reject) {
      var ok = false;
      // do stuff
      if (ok) {
        resolve("Stuff worked!");
      } else {
        reject("It broke");
      }
    }).then(function(result) {
      console.log(result); // "Stuff worked!"
    }).catch(function(err) {
      console.log(err); // Error: "It broke"
    });
    

    I know some people like programming like this (to avoid all that nesting) so this may help...

    process.on('uncaughtException', ...)

    This allows you to catch any exceptions that your code produced but that weren't caught. For instance you might want to log the exceptions to read-only memory for later debugging, or just light up a warning light.

    force argument on Serial.setConsole()

    For example with USB.setConsole(true), you can make sure that Espruino's console always stays on USB and doesn't get in the way of Serial, regardless of whether USB is subsequently plugged or unplugged.

    Fix software PWM glitches

    It used to be that whenever you modified software PWM, PWM was stopped and then started again, and this made it 'glitch'. This is now fixed so you can animate software PWM values without any glitches.

    E.kickWatchdog()

    Espruino's had E.enableWatchdog for a while - which checks that the interpreter is always going around the idle loop, but you can now do E.enableWatchdog(time, false) which means that if your code doesn't call E.kickWatchdog() within the time period the chip will auto-reset.

    It's a great way of making sure that your code really is running as expected.

    micro:bit improvements

    • micro:bit's show() function now works well with Graphics
    • Many nRF51/2 fixes and improvements
    • Fixing micro:bit compass issues

    Other Fixes and Improvements...

    • Telnet now built into linux builds (use --telnet to enable) - also some Telnet fixes
    • Finally added .removeListener so you can remove just one listener (for example when using multiple listeners on Serial)
    • Added require("Flash").getFree() as multiplatform way to find free flash pages
    • Add the ability to set clock frequencies on STM32F4 chips (like Pico) with E.setClock
    • Add E.setBootCode to allow JS scripts to be saved without being in RAM ()
    • Expecting a number or something iterable, got X changed to exception rather than warning (so you now get a stack trace of the error)
    • Ensure that pinMode/digitalWrite is re-constituted properly by dump() and save() (fix #833)
    • ESP8266: Some read-only variables moved to flash to save a whole bunch of RAM
    • GCC 5.3.1 now used for ARM release builds
    • Fix potential variable corruption issue when copying objects/arrays containing packed ints
    • ESP8266 printLog memory leak fixed
    • Added Object.get/setPrototypeOf that are nicer than accessing prot_ directly
    • Fix memory leak when executing bound function with 'this'
    • Fix issue when turning a negative Date to a string
    • Stop eval in a switch statement from confusing parsing
    • Fix regression in 'mode' argument of SPI.setup (allows custom CC3000 pins to work)
    • Fix '.on' with long event names
    • Enable F4Discovery button pull-down. Newer boards don't seem to have one fitted
    • Unterminated expressions now produce errors
    • New slow but memory efficient sin and atan for devices with really low memory

    For more info including bug numbers of fixed bugs, check out http://www.espruino.com/ChangeLog

    New product!

    Espruino WiFi has got a bit delayed due to some component sourcing issues, but I hope to have the first 100 available within the month now.

    However I'm about to launch a KickStarter for a new Bluetooth LE Espruino (with a case and battery), which we're calling Puck.js. It should be starting within the week if all goes well, and I'll post up some more details then...

  • Question about 1v86's Object.setPrototype(...) implementation and reference/documentation:

    Espruino reference of Object.setPrototype(...) explicitly says in Description 'Creates a new object...'. Does it really? ...or does it only change the object's reference to its prototype and with that 'replace' the behavioral parts that are not defined on the object itself?

    ...almost forgot: @Gordon, thanks for the great enhancements... regarding coding (Promise) and robust operation (watchdog) ...next to the many other very useful things.

  • explicitly says in Description 'Creates a new object...'

    Ahh, thanks - yes, that's a copy/paste error. I'll update the docs in a second.

  • big thanks for the ongoing cool work on espruino and count me in for the kickstarter (cool name puck.js)

  • Nice new features, Gordon! Thank you!
    BTW, how did you produce the release builds, travis shows all recent builds in red... https://travis-ci.org/espruino/Espruino/­builds

  • @tve ahh - the builds do work fine - it's just that travis couldn't download arm-gcc.

    I was waiting to pull your branch in (which modified the download location of arm-gcc for travis) until we were sure about the new ESP8266 SDK. I figured if I just copied those lines it'd cause a merge error for you, and cherry-pick wouldn't do it so I figured I'd just wait and then forgot about it. I've just done it anyway - I'm sure you can deal with a 2 line merge conflict :)

  • Just a quick update - it turns out that the new compiler (GCC 5.3) broke USB on the original Espruino board. I've just rebuilt using the brand new GCC 5.4 release and updated the 1v86 release and everything now seems fine though.

    Sorry if you tried 1v86 without success before, but if you re-flash now then it should work.

  • FYI, the official v1.86 download is missing the user1.bin/user2.bin files for the esp8266. It has an empty dir.

  • Argh. I'll try and look at that it next week

  • Maybe the names of the built files changed - I'll look into it. IMO a single 1M bin file would be really good for new users - what exactly needs to go in there? Is it just the same layout as the 512k, but with the different binary?

  • The file would need:
    Boot loader,user1.bin,padding, user2.bin. It would not be able to be loaded onto the esp01 with 512k rom.

  • No, but we'd have a _512k combined file and a _1M combined file.

    Are you sure user2.bin is needed? Last time I checked with @tve, user2 was only for OTA firmware updates?

  • Each time you do an ota update, it alternates between user1 and user2.

    I'm not sure if you can just add the user1 part, and then do an ota into user2 and boot into it? @tve ?

  • No micro:bit build for 1.86 in the release Downloads folder...
    Compass works steadily, though :)

    -Stev

  • save() is broken for the micro:bit in the 1.86.xx travis builds...

    (and I get a debounce value stored for setWatch that is one less then entered...)

  • Thanks - that's strange as it's in the zip! Just fixed it.

    I'm away from the office for a few days so I won't be able to test/fix the save issue, but it's possible this is related to building with GCC 5.3 - I found an issue on nRF52 where they changed how double floating point values were passes into function calls, and that broke some of the calls in Espruino.

  • Hey Gordon,

    Take your time. I'll collect some more meanwhile:

    While the compass() function now returns sensible values, it happens to fail with a i2c write error after a while (though no clear criteria on when/why).

    Also, when I use a non-rounded int resulting from Math.pow as a parameter for show(), I sometimes end up with the result for one less (that "one less" thing. again.):

    show(Math.pow(2,15))
    

    should only light up a single LED,

    show(Math.round(Math.pow(2,15)))
    

    does.

    -Stev

  • Odd about the I2C - have you tried different micro:bits? I guess it's possible yours has a dodgy connection?

    For show, it's tricky - Math.pow will be using floating point, and I believe the truncation (rather than rounding) is the correct thing to do. The micro:bit has so little memory I believe I'm using a simpler Math.pow that's not quite as accurate, which might account for the problem. I'm not sure there's an easy fix (short of just hacking show to round when it gets an FP number).

  • Not familiar with Promise... it looks basically like the same functionality of Android's AsyncTask class, is this a fair comparison?

  • Without looking into AsyncTask in any detail I can't say for sure - there's loads of info on promises online though

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Espruino 1v86 release

Posted by Avatar for Gordon @Gordon

Actions