Search results for:

@Gordon, it worked. The official and "shifted to 0x80 8th byte" did flash immediatly by copy/paste to my D: drive.
I edited the official file using directly ST-link utility which allow to change a byte and save as a new file the .bin opened.

About the compiler there is an error message in the webide, I will look at it later, so far no problem.

One more detail, the compiler doesn't work apparently with the Nucleo.

Well, that one flashed correctly and run only through st-link, never by drag and drop.
So I didn't checked further...
The official one did not flash through the standard copy/paste under windows 8.1 64 bits.
That said, it flashed using st-link utility and runs from the web ide.

Screen capture with both @DrAzzy and official Espruino for NucleoF401RE board.

Connected
>
=undefined
>echo(0);
<<<<<{"VERSION":"1v81.79","BUILD_DATE":"Oct 18 2015","BUILD_TIME":"00:27:36","GIT_COMMIT":"d19c544b8a0e247524f41bf490fee7eb03fb387c","BOARD":"NUCLEOF401RE","CHIP":"STM32F401RET6","CHIP_FAMILY":"STM32F4","FLASH":524288,"RAM":98304,"SERIAL":"56005b00-0b513333-37343534","CONSOLE":"Serial2","EXPORTS":{"jsvLock":6661,"jsvLockAgainSafe":6625,"jsvUnLock":6573,"jsvSkipName":193093,"jsvMathsOp":17313,"jsvMathsOpSkipNames":115589,"jsvNewFromFloat":202021,"jsvNewFromInteger":202089,"jsvNewFromString":33209,"jsvNewFromBool":202045,"jsvGetFloat":79457,"jsvGetInteger":193809,"jsvGetBool":139461,"jspeiFindInScopes":93809,"jspReplaceWith":178577,"jspeFunctionCall":171857,"jspGetNamedVariable":89277,"jspGetNamedFie
Connected
>ld":58009,"jspGetVarNamedField":57625,"jsvNewWithFlags":197489}}>>>>>
=undefined
=undefined
>echo(0);
<<<<<{"VERSION":"1v81.79","BUILD_DATE":"Oct 18 2015","BUILD_TIME":"00:27:36","GIT_COMMIT":"d19c544b8a0e247524f41bf490fee7eb03fb387c","BOARD":"NUCLEOF401RE","CHIP":"STM32F401RET6","CHIP_FAMILY":"STM32F4","FLASH":524288,"RAM":98304,"SERIAL":"56005b00-0b513333-37343534","CONSOLE":"Serial2","EXPORTS":{"jsvLock":6661,"jsvLockAgainSafe":6625,"jsvUnLock":6573,"jsvSkipName":193093,"jsvMathsOp":17313,"jsvMathsOpSkipNames":115589,"jsvNewFromFloat":202021,"jsvNewFromInteger":202089,"jsvNewFromString":33209,"jsvNewFromBool":202045,"jsvGetFloat":79457,"jsvGetInteger":193809,"jsvGetBool":139461,"jspeiFindInScopes":93809,"jspReplaceWith":178577,"jspeFunctionCall":171857,"jspGetNamedVariable":89277,"jspGetNamedField":58009,"jspGetVarNamedField":57625,"jsvNewWithFlags":197489}}>>>>>
=undefined
>reset();
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v81.79 Copyright 2015 G.Williams
>Loading -134610944 bytes from flash...
>
Disconnected
>
Connected
>
=undefined
>echo(0);
<<<<<{"VERSION":"1v81","BUILD_DATE":"Oct  8 2015","BUILD_TIME":"16:05:33","GIT_COMMIT":"8e1efcf898350a290242d732631be15c36f53381","BOARD":"NUCLEOF401RE","CHIP":"STM32F401RET6","CHIP_FAMILY":"STM32F4","FLASH":524288,"RAM":98304,"SERIAL":"56005b00-0b513333-37343534","CONSOLE":"Serial2","EXPORTS":{"jsvLock":13789,"jsvLockAgainSafe":13777,"jsvUnLock":13753,"jsvSkipName":82997,"jsvMathsOp":50761,"jsvMathsOpSkipNames":128593,"jsvNewFromFloat":156705,"jsvNewFromInteger":157117,"jsvNewFromString":158673,"jsvNewFromBool":157045,"jsvGetFloat":59457,"jsvGetInteger":84653,"jsvGetBool":86897,"jspeiFindInScopes":159837,"jspReplaceWith":86581,"jspeFunctionCall":175133,"jspGetNamedVariable":124777,"jspGetNamedFi
Connected
>eld":42141,"jspGetVarNamedField":87629,"jsvNewWithFlags":156473}}>>>>>
=undefined
>echo(0);
<<<<<{"VERSION":"1v81","BUILD_DATE":"Oct  8 2015","BUILD_TIME":"16:05:33","GIT_COMMIT":"8e1efcf898350a290242d732631be15c36f53381","BOARD":"NUCLEOF401RE","CHIP":"STM32F401RET6","CHIP_FAMILY":"STM32F4","FLASH":524288,"RAM":98304,"SERIAL":"56005b00-0b513333-37343534","CONSOLE":"Serial2","EXPORTS":{"jsvLock":13789,"jsvLockAgainSafe":13777,"jsvUnLock":13753,"jsvSkipName":82997,"jsvMathsOp":50761,"jsvMathsOpSkipNames":128593,"jsvNewFromFloat":156705,"jsvNewFromInteger":157117,"jsvNewFromString":158673,"jsvNewFromBool":157045,"jsvGetFloat":59457,"jsvGetInteger":84653,"jsvGetBool":86897,"jspeiFindInScopes":159837,"jspReplaceWith":86581,"jspeFunctionCall":175133,"jspGetNamedVariable":124777,"jspGetNamedField":42141,"jspGetVarNamedField":87629,"jsvNewWithFlags":156473}}>>>>>
=undefined
>reset();
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v81 Copyright 2015 G.Williams
> 

So it seams to be a problem just with those restrictions mentionned above by ST.

@Kolban JSON (JavaScript Object Notation) is definitly javascript idiomatic thus Espruino too.
However, I believe that what @Gordon wants is just impossible.
Each and every module maker including an esp8266 chip wants to add its own 'firmware'. And obviously, the officiel sdk is still moving once a month, deprecating functionnalities while enforcing others...

So here are some hexdump of various files: Apparently, the code coming from mbed online compiler is different from the one obtained by @DrAzzy on the espruino build as it places the second vector at $08xxxxxx while espruino places it at 0x20xxxxxx.

Compiled on Filename Hexdump
13 October 2014 ds18b20_test_NUCLEO_F401RE.bin 00 80 01 20 b1 01 20 08 b9 01 20 08 bb 01 20 08 bd 01 20 08 bf 01 20 08 c1 01 20 08 20 20 20 20
18 October 2015 espruino_1v81.79_nucleof401re.bin 00 80 01 20 d9 2a 03 20 55 24 03 20 51 24 03 20 4d 24 03 20 41 24 03 20 3d 24 03 20 20 20 20 20
18 October 2015 get_serial_number_NUCLEO_F401RE.bin 00 80 01 20 b1 01 20 08 b9 01 20 08 bb 01 20 08 bd 01 20 08 bf 01 20 08 c1 01 20 08 20 20 20 20

@Gordon,
I think they have to be able to add new features and processors which implies some compatibility issues.
Will check those bytes soon

On the other hand, nucle0 boards are incredibly cheap and provide lots of connectivity...

And furthermore, mbed recompiled bin do flash correctly by drag and drop, while olders don't.
The bin's found on Dr Azzy web site flash only through st-link utility. On the other hand, they work!

@tve and others,
ST has changed quite a number of things and I now have some problems too.
They are also mentionned here.
What I did, on a NucleoF401RE, was to update:

1. the usb drivers
   
2. the firmware
   
   

Before doing this, I could flash my nucleo with no problem. Espruino run just as usual with just a recurrent problem with Serial4 beeing undefined. That on Espruino's side!

After doing so, I just can't flash any file by drag and drop: it is just copied, apparently, on the usb flash drive but in fact nothing happens... And the reset() just confirmed that in a terminal (putty).
To flash any bin, I had to use ST-link to the latest version.

Now, if I read the know limitations and issues of the st-link firmware in DM00107009.pdf, I see:

Applications programmed through the Mass Storage interface (drag & drop to disk)
must fulfill both following constraints. Applications not respecting one of these constraints, will not be programmed in this way (but could be programmed through any
other tool, such as ST-LinkUtility):
– a Stack Pointer value (first entry of the vector table) in the range of the
microcontroller RAM range
– a Reset vector value (second entry of vector table) in the range of the
microcontroller flash range

So for now, I will use ST-link v3.7. It's quite annoying but it works.

In fact, it was meant to help understanding some problems with the nucleo's rtc: some boards don't have all of the circuitry to run at full speed. Clearly a fault of st...
About the nucleo, it doesn't need the bootloader as the original espruino boards do.
That's a consequence of the mbed side which implies really bear metal bins, so it could be it.
The nucleo has an integrated st-link with its own separate stm32 and that's what is being updated in the St designed firmware. This one also provides all the USB enumerated devices: serial link, flash drive and ocd functionality.

Hi @tve, the bin you flashed has nothing to do with espruino. It is a c code compiled from the mbed online environment!
I just have an f401 so I 'll test this today.
Unfortunately I can't rebuild espruino now...

@Kolban, you should have a look here .

It says

For internal use, we at Espressif desired a GDB stub that works with FreeRTOS and is a bit more capable, so we designed our own implementation of it. This stub works both under FreeRTOS as well as the OS-less SDK and is able to catch exceptions and do backtraces on them, read and write memory, forward [os_]printf statements to gdb, single-step instructions and set hardware break- and watchpoints. It connects to the host machine (which runs gdb) using the standard serial connection that's also used for programming.

Really interesting, isn't it?

Hi @Gordon, @DrAzzy,

Yes I did the dev that way. I mean load only a part of the code and check it's functionnalities.

However some bugs appeared since I tried to shrink down my code and changed it again.
The problem arrises due to the fact that not all the source code can be loaded at once, even without launching anything. It has to be partly executed before the remaining part of the code is evaluated.

A complementary need would be to use more than one source file from the webide, having a 3rd window so that I could choose what to upload easily. That's not a priority, I agree.

The real solution is elsewhere: Use some code from flash directly, which, i guess, is on the trend of the ESP8266 and partly answered in some other discussion.

@Gordon, thanks, I had not thought to the timeout approach.
Yet, it won't solve my problem as I am really running out of ram. I need to execute the function in question before any other thing which I placed in the following lines of the code, I then delete my function factory so as to end up the object's events handlers.
Could it be possible to have a functionality to load files from the web ide on demand from the espruino board through USB connection?
Obviously the web ide and the interpreter would have to be tightly integrated.

Hi @Gordon,
I attempted to use debugger() within a function invoqued at load time and found that the remaining of the uploaded file was "used" or, may be "consumed " out of the file being uploaded. This is not what I intended...
Is this behaviour "normal " ?
How can I debug in such a case?

I subscribe to an automatically generated document, knowing that this forum, and now gitter discussions, do contain useful informations, about all the oddities any user might face.

That's it, and now you know why I did not carried on this way...
Anyway, as I wrote, you have little or none real solution but what you are already doing for the ESP8266.
On the STM32, there are much more interesting solutions with openocd and Nucleo's boards.

Now, for the ESP8266, until this summer you could not do any debugging within it, but by inserting prints. Now, with Arduino IDE compatibility and Visualmicro plugin, you could some step by step debugging. The trouble is the requirement to be able to actually build Espruino under Windows.

And finally, read this ...
Just noted that this ends up on smartJS project, yet worth reading!

The time you'll spend installing will be well paid, I think😉http://www.esp8266.com/viewtopic.php?f=9&t=3751
Now, considering the linux based process to build Espruino, I would suggest using the gdbstub above and use a gdb/eclipse.
This way you would keep all of the conveniencies of eclipse environment, python and so on for Espruino building itself and little more space used inside the Esp.

An other approach is Qemu described here .
You'll be able to use gdb but the hardware wont't be real, just emulated...

Hi @Kolban,
Actually, it depends on what possibilities the hardware has.
If you are left with pure software, you'r doing it the sole way possible.
On Arduino platforms there is a plugin in Visual Studio to inject those 'breakpoint' and 'watches' done from the IDE at compile time. This video
will show you how pratical it is. It's not free but there is an evaluation version and the prices seem 'fairly reasonnable'.
There is also a possibility to use it on ESP8266 but through the Arduino sketches. I don't think Espruino would be debuggable this way.
All other approaches are hardware specific: up to the number of hardware breakpoints versus software breakpoints.
For the ESP8266 there is this threat or this one which basically explains how to install openocd. This links, no warranty, to the specific xtensa openocd.
With other environments you could get lot's more (Keil and others professionnals), but that's expensive.
For CC3200, TI has it's own CCSv6 (eclipse+gdb+openocd+specific hardware on dev board) approach which allows to import energia sketches or use ti-rtos or even bare metal c and do step by step debugging.
For the STM32, you could see Emblocks which would handle Nucleo's out of the box: However that's windows only.
For Linux, that's the luxious situation, you have everything GDB and lot's of others.

Well, you spotted it : To my opinion and so far identified needs, I would say that the "low level" realtime layer separates the gps data stream from the use of these data.
You could just use these data to display them or produce much more dynamic computations and finally store only the results of these...
Yet, all considered, those computations have to be real time too. As far as no other delaying hardware impose its own pace.
By dynamic computations I mean data values based complexity.
As it happens with the big data world it can just be impossible to do some post treatments either due to the data size (mb) or to the volume of data to get of the storage support per time unit (mb/s) .
Do we pretend that the espruino has to solve any real time need? I would n't

Real time, normally, means with a known delay between this instant of the event and the start of the routine in charge of handling the event.
In the particular case of the Espruino interpreter, things are handled by pushing a time stamp and the handler gets it with the pertinent data somehow later.
So, in such a very different context, I would call "realtime" anything that would end up by consumming events fast enough so as not to overflow the event fifo....
I guess this is how Espruino was designed.
Of course, in my particular gps goals, I need to end up all of the computations within a second since the gps gives its data every second, or 1/10 of a second if properly setup.
At this point, your own requirments are the rule.
Do forget that writing to aflash memory takes literally ages per comparison since they are blocking apis.
Even worst, the so called non blocking apis are never so:
Either you use a multi core / processor, which is not Espruino's case and you could delegate blocking tasks to one of them.
Or you have to buffer and delay blocking actions to the risk of not handling whatever happens at that instant.... So i would say that buffering is, per itself, a problem! That's why, I would that consider only buffering summaries, that can wait in a buffer for a very long time (seconds to hours). While i'd prefer to handle the full data stream in "realtime".
There is no universal answer to this!
It will, forever, be a matter of priorities: should I kill my batteries by over discharging them, or let my drone fall on someone's else head? A boat or a car could just safely stop in place and not destroy anything or anyone.

Definitly yes,
While the case about "this" is a classic problem to javascript, it becomes crucial on very small platforms such as Espruino. This would have gone unnoticed in a web browser for instance.
Drilling down in objects is a need to diagnostic and i ended with a difficulty to read the trace output.

@Gordon and all others interested:
My problem was indeed an out of memory error, happening due to the exessive size of the gps object created.
The object was very oversize in memory due to using an eval() to transform my dynamically computed strings into functions.
Eval uses the local context which was the local context of the initialising function. Thus eval linked all of its local vars and values, local functions and so on.
This discussion gave me the answer.

How to call eval in a given context? 3 words. Use a closure.

var result = function(str){
  return eval(str);
}.call(context,somestring);

The context object above is a global object created outside of the parseHandlers function.
It could be seen as a pre initialised gps object. Something like
{ serial: Serial4 } is sufficient if provided as a parameter of the function that computes the handling functions.

The joined file is actually the parsing function that creates the gps object with its nmea sentences as methods. You then can call gps.GPGGA(d) were d is the array, comma splitted, resulting of the nmea string received after checksum and dollar having been removed.

Once intialised, you just could delete parseHandlers function which will free the memory space it used: around 650 jsVars... While gps object is less than a 100 jsVars....

So, so...

Well, gps is all about real time and position...