Release 1v71 now out #69
Replies: 12 comments
-
Posted at 2014-11-10 by @allObjects 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! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-11-11 by DaveNI 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? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-11-11 by @gfwilliams 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. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-11-11 by @gfwilliams 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. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-11-11 by @gfwilliams 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. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-11-11 by asez73 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. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-11-11 by @gfwilliams @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? |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-11-12 by asez73 Hi @gordon, Well, these characters are a problem when the web IDE sends a program from the right pane to the 'Espruino'. So far I failed to identify where, in Espruino interpreter, these characters were generated. 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. 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.
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-11-12 by @gfwilliams 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:
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. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-11-13 by asez73 Hi,
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
that apparently change the actual final initialisation of the serial port. 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... |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-11-13 by @gfwilliams
I don't think it's those defines that are the problem - it's actually Did the exact lines I gave you fix it? If so I'll commit them to GitHub.
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.
Looking at the size of the voltage regulator, it's not going to be fantastic I'm afraid!
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. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-11-13 by asez73
Yes, the lines you gave fixed it.
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.
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...
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. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-11-10 by @gfwilliams
This one's been quite a long time coming with the KickStarter I'm afraid, but here it is!
New features:
fs.stat()
andFile.seek()
methodsSerial.setup
)setTime
should now work on the Espruino board, which should mean you can easily use 'Date' without needing theclock
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):
Beta Was this translation helpful? Give feedback.
All reactions