Espruino 1v80 released

Finally, I've released Espruino 1v80 - it should be available for firmware updates from the Web IDE.

There are a few big changes:

• USB HID support on the Pico (so it can pretend to be a keyboard, mouse, etc).
  
• Fast startup - code now starts running a fraction of a second after power-up, rather than after the previous ~1 sec delay.
  
• The 'one character behind' problems that occasionally happened with the Pico's console on Windows/ChromeOS seem to be fixed now, as well as the bug where it wouldn't run code if it was plugged into USB without a terminal running.
  
• Pico owners now get access to 5000 variables instead of 3000 (so available memory has almost doubled!). Code is compressed before writing it into flash memory, so it can fit in the same amount of Flash.
  
• There's also now an API for accessing the Flash memory on the Espruino boards - both for the Pico and the Original, and a nice surprise for Pico owners - there's a whole page of 128kB flash memory available at 0x20060000 which shouldn't exist, but does!
  
  

As always, I've tried to test and make sure everything is working fine, but this is a pretty big change - especially on the Pico - so let me know if you have any problems!

Full list

New features:

• USB HID support for the Espruino Pico
  
• Fast startup
  
• Added support for USB CK pin (USARTs), and hence PS2 keyboards/mice (fix #544)
  
• SPI.send now returns Uint8Array when passed an array. Also takes {data:X, count:Y} as argument (fix #485)
  
• VGA output can now do line doubling (so 320x240 mode)
  
• Add built-in 'Flash' module to allow Flash memory to be accessed from user code
  
• Add RLE compression when saving to flash, increase Pico RAM from 3000 to 5000 vars (fix #543)
  
  

Improvements:

• Shorten some internal property names to save memory and increase speed
  
• Speed up iteration for arraybuffers
  
• SPI speed improvements, esp for SPI.write (fix #547)
  
• Tweak Olimexino board - 700->1000 vars, but lowered code flash to 6k
  
• Disable flash prefetch on Pico (~1% slower, but less power and way more accurate ADC readings) (fix #545)
  
• Updated (inaccurate) docs for Serial.write/print and removed duplicated code
  
• Improve digitalWrite/etc documentation
  
• Add pin.mode and pin.getMode functions (mirroring pinMode)
  
• Serial.setup now remembers options if none specified (fix #557)
  
  

Bugfixes:

• Fix SD card corruption on file append regression (fix #536)
  
• Fix some potential pointer issues in hashlib
  
• Make debounced setWatch output state+time information (regression fix #537)
  
• Change 'internal property' prefix from '>' (fix #540)
  
• Duplicate properties in an object defn. now cause second definition to be used (fix #495)
  
• Make sure E.unmountSD doesn't forget custom SD card configs from E.connectSDCard
  
• ES5 parseInt behaviour - don't treat numbers beginning with 0 as octals (fix #538)
  
• Fix parseFloat(Infinity) (fix #314)
  
• Fix JSON.parse when not given strings (fix #546)
  
• Now throw errors when 'in' is used on an invalid datatype (fix #550)
  

Great set of updates, thanks Gordon.

Sadly still no joy for me with HID on Windows (I tried Windows 7 and Windows 10, two AMD-based and one Intel-based). OSX fine.

Ok, thanks for checking - it looks like we'll have to wait until the descriptors can be properly specified in Espruino then :(

Hi Gordon
Thanks. Very very impressing update!

Sacha

Not sure if this is to do with the update as I had not used the NRF24L01+ before. But when I call it from the PICO as in the example it errors back with "masterHbndler" not found.

SPI1.setup({sck:A5, miso:A6, mosi:A7});
var nrf = require("NRF24L01P").connect( SPI1, B10, B1 );
function onInit() {
  nrf.init([0,0,0,0,2], [0,0,0,0,1]);
}
onInit();
setInterval(function() {
  nrf.masterHandler();
}, 50);

returns

in function called from system
Uncaught Error: Function "masterHbndler" not found!
 at line 1 col 6
{nrf.masterHbndler();}
      ^

BUT when I run the code like this....

SPI1.setup({sck:A5, miso:A6, mosi:A7});
var nrf = require("NRF24L01P").connect( SPI1, B10, B1 );
function onInit() {
  nrf.init([0,0,0,0,2], [0,0,0,0,1]);
}
onInit();
function interval(){
  nrf.masterHandler();
}
setInterval(interval, 50);

it works........

Hi @Gordon,
I just added an issue about Serial4.setup in 1V80...

Thank's again for all that work, the Espruino is really an interesting, very power saving little board: I runned an internal temperature to SD card logger every 5 minutes for 6 months from a pair of AA batteries without having any problem.

Now I want to do it with a GPS switching it ON / OFF from the STM43F1.
I'll try by software first with ublox specific commands and, if not, I'll do it with a separate power supply regulator swithcing it ON / OFF from the STM32F1 in the prototyping area.

However I hate to solder very tiny things...

Nice update @Gordon!

Also @Cale, masterHbndler is not the same as masterHandler ;)

masterHbndler is not the same as masterHandler

However @Cale's code used the correct version. Usually when characters get changed it's because of some internal error in the interpreter :(

@Cale I can't reproduce this at all with your code though. What happens if you step back in the command history with the up-arrow? Does it show masterHbndler or masterHandler?

I did however find that the NRF24 module was broken in another way (it was depending on an Array, not a Uint8Array being returned by spi.send). I've just fixed that now though.

Maybe its my chip? Check this out.....

>nrf.sendCommand("1+2", function(r) { print("=="+r); });
=true
>nrf.sendCommbnd("1+2", function(r) { print("=="+r); }); //here I used the up arrow 
=undefined
Uncaught Error: Function "sendCommbnd" not found!
 at line 1 col 5
nrf.sendCommbnd("1+2", function(r) { print("=="+r); });
     ^
>nrf.sendCommand("1+2", function(r) { print("=="+r); }); //here I copy and pasted the code manually
=true

Notice when I use the up arrow to reuse the previous code that it changes letter a to b.....
That is weird as I have been able to duplicate it on a few units. The nrf wouldn't have anything to do with this?? Mine has a different pinout-- Waveshare style

and sometimes that 'print("=="+r)' will be replaced with 'print("=="+s)' then 'print("=="+t)' when I use the up arrows to reuse the code....... I'll do some more testing

Wow, strange. Does it do it with more simple bits of code, or just the NRF stuff? And you're definitely using 1v80?

It could be the chip, but this does look exactly like a very specific problem with the interpreter. I just wish I could reproduce it!

Sorry for not getting back, I've been onto other projects recently. I have received my new NRF modules though :) I should have a board put together in the next day or so and ill update you.