Release 1v71 now out

This one's been quite a long time coming with the KickStarter I'm afraid, but here it is!

New features:

• CC3000 and WIZnet modules can now be instantiated on any pins (as long as they have hardware SPI)
  
• Lots of fixes and tweaks
  
• Added fs.stat() and File.seek() methods
  
• Added XON/XOFF flow control for serial (on by default, can be turned off with Serial.setup)
  
• setTime should now work on the Espruino board, which should mean you can easily use 'Date' without needing the clock module.
  
  

New Board:

As part of the deal with ST on the Espruino Pico, I'm now putting binaries for the ST NUCLEO-F401 board on the Espruino site - thanks to Alain for getting it working! They're available for download right now.

It is quite a nice board (with an Arduino footprint). It does lack proper USB support though - the serial comms via the ST-Link part will run at 9600 baud by default so will be a bit slow for programming it.

As with the other non-Espruino boards, I'm not making anything on these boards - in fact I believe they may even be subsidised by ST. This means that I can't afford to spend time supporting you if you have problems... If you want support, buy an Espruino board - it's a little more expensive, but that money helps me keep working on Espruino :)

Web IDE

I also snuck in a new Web IDE version (which should be auto-updating in the next hour or so):

• LED/BTN variables now work with the autocomplete feature
  
• The editor now remembers what was last in it
  
• Load and save remember the directory they were in (only while the app is running)
  
• Slightly better inline Assembler
  
• better handling of weird formatting at root scope
  
• Added a 'minification cache' that should make it less likely that you hit the Closure Compiler's rate limit
  

Thanks... anything helps.... it goes from already very good to better all the times... and with new releases there come surprises... so far they were for me all on the plus side!

Firstly the good news: Great to see setTime & ArrayBufferView.sort now working. Thanks.

Now for the bad news: I have some code to test the performance of my buffered ILI9341 module (simply multiple drawStrings).

Using the existing ILI9341 module the test was taking 7.5 seconds, 1.8 seconds with the buffered version. Since upgrading to 1v71 the tests now take 10.5 and 2.1 seconds respectively.

I didn't believe the difference so went back to 1v70 and the timings reverted to 7.5 & 1.8 seconds. (I use getTime() before & after the tests to calculate timings)

All I can think of is that SPI is running slower for some reason - any ideas?

I did finally switch to a new compiler and modified the build options to optimise for size rather than performance, however I didn't actually think that would make such a big difference.

I don't think it'd be SPI timings, but it may be execution speed in general that has slowed. I'll try and run some tests and see if it was the change in compile flags that slowed it down.

Yes, that's what it was. I'm running the benchmarks on previous builds, and the one that makes it noticeably worse is the one where the optimisation flags change.

I could change it back but I'd actually quite like to try and find out why it's slower. -Os shouldn't have made that much of a difference.

Just to add that I've done a bit of work on this now, and it's down to a 10% performance degradation, rather than the 40% that we're seeing before. Hopefully with a little more work we'll be closer if not maybe even a bit faster.

I won't update 1v71, but these changes will be in 1v72 when it's released.

Good news!

So I keep having small problems with various points on the Nucleo. Working on getting rid of first chars after reset() and other details.

@asez73 the characters after reset may be control codes to set the terminal up so that it doesn't wrap (which messes up the console when there are long lines). Of course it's possible (if they are received?) it's actually a side-effect of initialising the pull-up on the serial line.

What other problems are you having?

Hi @Gordon,

Well, these characters are a problem when the web IDE sends a program from the right pane to the 'Espruino'.
For instance, see line 17 below.

So far I failed to identify where, in Espruino interpreter, these characters were generated.
I guess, to achieve such a result, I have to setup a full debugger with watched variables, breakpoints, gdb, openocd 0.8.0 and st-link.

Actually, I am not far from getting gdb at work: gdb connects to openocd which connects to st-link which, in turn, connects to the Nucleo.

At that point, the Nucleo must have an already properly loaded program such as 'blink a led' in order to not have the error 'init failed'.

I get the number of hardware breakpoints and so on display from openocd.
gdb allows me to load the .elf file which I compiled with NUCLEOF401RE=1 DEBUG=1 make.

It's just a matter of setting a breakpoint at some precise line in source code and get it running in the right order. The code is started with 'continue' under gdb but never stops where I want...

That's the moment I found your page about AdvancedDebug. So I yet have to apply/transpose those directives properly.

As a secondary question, how do I launch the various tests available on a Nucleoboard? Obviously, your instructions are linux specifics.

Connected
>
=undefined
>echo(0);
<<<<<{"VERSION":"1v72","BUILD_DATE":"Nov 12 2014","BUILD_TIME":"16:11:50","GIT_COMMIT":"3c4500490eb33bd2ac84a108c70a42d0bee4a83b","BOARD":"NUCLEOF401RE","CHIP":"STM32F401RET6","CHIP_FAMILY":"STM32F4","FLASH":524288,"RAM":98304,"SERIAL":"56005b00-0b513333-37343534","CONSOLE":"Serial2"}>>>>>
=undefined
>
=undefined
>reset((;
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v72 Copyright 2014 G.Williams
>ÿecho(0);
=undefined
Uncaught SyntaxError: Got ?[255] expected EOF
 at line 1 col 1
ÿecho(0);
 ^
>function buttonWatcher() {
:  console.log("Pressed at "+getTime());
:  digitalWrite(LED1, Math.random()>0.5);
:}
=function () { ... }
=undefined
>setWatch(buttonWatcher, BTN, {edge:"both", repeat:true, debounce: 0});
=1
>echo(1);
=undefined
> 

I actually just run those tests on linux - not on the ARM boards at all.

I'm almost 100% certain that the character won't be a software issue. Espruino compiles for a whole bunch of different processors and works on them, so I doubt it's something specific to yours.

Actually I just realised what it might be - you could try explicitly setting the serial pins in the .PY file with:

 'default_console_tx' : "A2",
 'default_console_rx' : "A3",

What this does is in jshReset it stops the pin function from being set back to a normal input - the change of registers may cause a glitch on the input line which makes the USART read in a dud character.

Hi,
Bravo, it did the trick: No more scary characters in the input line after reset() or load() as shown below.

>
=undefined
>reset();
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v72 Copyright 2014 G.Williams
>echo(0);
=undefined
>dump();
function buttonWatcher() {
  console.log("Pressed at "+getTime());
  digitalWrite(LED1, Math.random()>0.5);
}
setWatch(buttonWatcher, "C13", { repeat:true, edge:'both' });
=undefined
>save();
=undefined
Erasing Flash....
Programming 86016 Bytes.......................................................................................
Checking...
Done!
>dump();
function buttonWatcher() {
  console.log("Pressed at "+getTime());
  digitalWrite(LED1, Math.random()>0.5);
}
setWatch(buttonWatcher, "C13", { repeat:true, edge:'both' });
=undefined
>reset();
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v72 Copyright 2014 G.Williams
>dump();
=undefined
>load();
=undefined
Loading from flash...
> 

I had tried to call jshResetSerial() after load or reset, however it did not do it alone. Defining the RX and TX pins does change the init sequence. That's because there are some

 [#ifdef](https://forum.espruino.com/search/?q=%23ifdef) DEFAULT_CONSOLE_TX_PIN
    inf.pinTX = DEFAULT_CONSOLE_TX_PIN;
 [#endif](https://forum.espruino.com/search/?q=%23endif)
 [#ifdef](https://forum.espruino.com/search/?q=%23ifdef) DEFAULT_CONSOLE_RX_PIN
    inf.pinRX = DEFAULT_CONSOLE_RX_PIN;
 [#endif](https://forum.espruino.com/search/?q=%23endif)

that apparently change the actual final initialisation of the serial port.
Anyway, now it is solved!

Running test on ARM boards is normally not a requirement and actually, breakpoint/watchpoint based debugging won't help much with real time problems...

Now I'll try to test more points about batteries life duration, data logging and ESP8266...

Serial

I don't think it's those defines that are the problem - it's actually jshReset (I think?) that resets the pin state to an input if it was not defined.

Did the exact lines I gave you fix it? If so I'll commit them to GitHub.

Running test on ARM boards is normally not a requirement

I do occasionally run through the tests on a Raspberry Pi - while the architecture isn't quite the same, it's probably close enough that it would pick up most potential issues.

batteries life duration

Looking at the size of the voltage regulator, it's not going to be fantastic I'm afraid!

ESP8266

Support for this isn't finished yet. @JumJum's written a driver in JavaScript but hopefully I'll get proper support in the interpreter soon.

Did the exact lines I gave you fix it? If so I'll commit them to GitHub.

Yes, the lines you gave fixed it.
I pushed those changes and some minor cleanup around there.
Since that, I think, you merged these in 1.72.

it's actually jshReset (I think?) that resets the pin state to an input if it was not defined.

Yes but those defines just swallow some init code of the serial inf structure if there are no RX and TX macros predefined in the board. However, this is now a closed issue.

it's not going to be fantastic I'm afraid!

Well, I hope to get a reasonable result with voltage regulator simply because I intend to shutdown the ESP8266 as soon as possible and power it up only when required. All of that being done by a GPIO, potentially some current limiting resistance on the CH_PD, at that point specs say 0.5 nA which is admissible. This is a web connected sensor approach, not a web controlled system. The later would require a permanent connection which is just a terrible thing to do if you expect batteries to last for months or may a year...

ESP8266

It is still unreliable/unstable as this post explains. I faced some issues of this kind after 1 or 2 weeks with Xively+Wifly and even faster with CC3000. The CC3000 just never ever reconnected to my modem/router. The Wifly did required a full reset and software update, but keeped unstable on long term. Actually, those modules do have some problems with the unreliable aspects of Wifi and Internet: they all can fail without warning or error messages and apparently this mess up the wifi/IP stacks in their inner memory.

Aside of Wifi, Xively faced unreliablity due to the internet connection itself. Some data was never received at Xively even from a Debian PC connected through ethernet.