Espruino 1v65 released!

Posted on
  • This is another really big release with a whole range of changes!

    Some of the changes are:

    Changing from int64 to int32

    This may seem like a step back, but it makes Espruino much more JS compatible. Quite a lot of code relies on numbers overflowing after 32 bits, and it will now work correctly. It also frees up some memory, speeds up execution, and paves the way for some better memory saving features in the future.

    Improved Serial port handling

    I've had to break backwards compatibility for this, but it's worth it! Serial.onData is now Serial.on('data', ...) which can return strings of data rather than just single characters. It means that Espruino can handle Serial data at much higher data rates than possible before, makes it more compatible with Node.js, and it also means...

    Piping data from Serial/HTTP

    Both Serial and HTTP now support the use of .available() and .read(nBytes) if there is no on('data', ...) handler present. This means that you can also use Serial.pipe(...) to pipe them directly to a file or even an HTTP socket!

    Multiple arguments to SPI/I2C and Serial

    This means you can be much more efficient with code - you can write I2C.write(addr, 1,2,myarray) and 1,2, and myarray will be output together. You can also write things like SPI.write(1,2,{data: [3,4], count:5}) which will output 1,2,3,4,3,4,3,4,3,4,3,4 - this is extremely handy for things such as LCD drivers.

    Built-in Date class

    There's now a Date module built into Espruino - which includes both parsing of dates, as well as creating string from dates. This means that you can easily read the current time and date right out of HTTP server responses, and can then use it to adjust Espruino's internal clock.

    Exceptions!

    While this needs a little more testing, there is now exception support, and most of the functions you'll call now return Exceptions. This means you can now 'catch' most errors that your code might generate, and can handle them yourself.

    Increased Event Buffer size

    The event buffer now stores 128 events instead of 64 - this means that you can now store up to 128 edge changes from setWatch, even if your code hasn't yet finished processing the first one.

    Array.reverse

    This one has been a long time coming, but it's here now. While not in ES5, ES6 has reverse support for ArrayBuffers, so it's been added to Espruino too. This will be really handy for all kinds of code that handle large blocks of data.

    New Tutorials/modules/examples

    There's:

    and hopefully there will be a few more coming as well!

    ... and many more fixes and improvements!

    Check out the ChangeLog. Espruino keeps getting more capable by the day!

    As always, there will be a small yellow triangle at the top right of the Web IDE when you connect to an Espruino board with an older version of the software on it. Click it, and you'll be walked through the process of updating your firmware...

  • Fantastic Gordon,

    Congratulation. You also patched my XBee module to the new serial handling.
    Will test it and post some other improvements soon.

    Any progress on auto detect "bigram" ?

    Sacha

  • No problem. I've tried to update all the modules and docs to go with the changes... Let me know if I missed something!

    No progress on that yet. Well, a little, but I still need to actually make the ram resize...

  • Is the 1v65 WIZnet bin posted anywhere?

    I'm using @DrAzzy build from the 32-bit Int Switch thread, but I'm unsure if that's the same as the official 1v65. http://forum.espruino.com/conversations/­1555/

    Also - will the WIZnet module always require a separate build, or can this be rolled in at some point?

  • Hi. It seems there's been a bit of a mixup as the latest builds in http://www.espruino.com/binaries/git should have wiznet, but they don't.

    I've also just added them to http://www.espruino.com/binaries (they should have been there already!), and I'll make sure that they continue to be put up there.

    At the moment, rolling support in looks unlikely. While I made sure that the code would support it, it turns out that there are a lot of conflicting function names, and the compiled binary won't work.

    While that could be fixed, it's starting to get difficult to get all the required program code into the available flash, so I'm not sure I'll be able to justify using up such a large amount of it with support for different modules.

    Probably the easiest fix for now would be to make it easier to choose different builds to flash from within the Web IDE.

  • Just tested new command spi.write for ILI9341 erasing the screen.
    old version took 3.5 secs
    new version takes 1.2 secs only
    In a mixed session with text, bars, etc. etc.
    old version took 13.5 secs
    new version takes 9.5 secs only

    Powerful new command, great job.

  • @Gordon Excellent, as always. Thank you.

  • The version I posted is not the same as official - it's based on github as of 6/21, so it's missing anything from after that. Also, it uses all 64k of ram (which the espruino boards seem to have despite the specs saying 48) for 2600 jsvars, and also makes use of the full 512k of flash (so you can save() )

    On the topic of fitting Wiznet+CC3000 modules - I was kinda bummed when i discovered that the function names fight with eachother (I tried the naive approach of just enabling both in the makefile). The Espruino boards all seem to have 512k of flash - so they should all be able to fit a binary with both wiznet and cc3000, right?

  • Great job Gordon! Thanks a lot.

  • @DrAzzy - I don't want to actually take advantage of the full 512kB because it's not guaranteed that the board will have it at all. This batch may all have it (I have no guarantee), but it's extremely likely that the next batch of boards won't :(

    But yes, I refactored all the code to work with both modules at the same time - so I was pretty fed up to find out that it wouldn't work! Someone could refactor all the duplicate names (cc3k_send / wiznet_send / etc) and it might spring into life though.

    @JumJum: the changes were done for that very reason! I'm considering also adding an option for a DC pin, which would be set with the 9th bit of the data that was sent. That should massively speed up those displays (as well as simplifying the code).

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

Espruino 1v65 released!

Posted by Avatar for Gordon @Gordon

Actions