Something most not-understood about Javascript Espruino is the fact that - with default settings - source code from within the IDE code editor is already processed - executed - by Espruino interpreter on the board on upload and *stored in the (volatile) RAM only. An upload independentsave() command in the console is required to save the cod in non-volatile Flash EEPROM to be available again after a power cycle. With most other environments (and languages), the source code is 'completely' transformed - compiled - into executable machine code before upload, and uploading is a plain copying of that code into the FLASH (EEPROM) (of the chip). Default settings has 'save on upload un-checked'.
Upload on Espruino uses the REPL nature and state of Espruino in connected mode and the interpretative nature of JavaScript with the small modification: no-print: echo is while uploading. About REEPL, see for example Wiki Read-eval-print_loop.
Let's play out the story on 'the subject' while moving on in this post. For that, we start with a clean slate: connect to the board with the Web IDE and enterreset()in the console (left pane).
That any code is processed by Espruino on upload becomes most noticeable when sending following code source string digitalWrite(LED1,1); to the board. Send the code by either typing it in the console and pressing Enter or by typing it in the editor - right pane - and clicking the upload 'button'.
At the very moment the code arrives - streams in - to Espruino board, Espruino's Javascript interpreter interprets it, and therefore turns LED1 on.
Let's look at some more things we upload - one after the other:
The code source string var v = 5; tells the interpreter to establish a variable by the name of v in a piece of RAM and set it to the value of 5. Note: If you use the editor pane to upload, add this code to the code that turns on LED1.
The code source string function turnOnLED1() { digitalWrite (LED1,1); } tells the interpreter to establish a function by the name of turnOnLED1 in a piece of RAM and set it to the function body's source code, the code between the curly braces, and - as expected - nothing else happens.Note: If you use the editor pane to upload, add this code to the code already in the editor pane.
For the sake of understanding what save() really does, execute it now byentering it in the console.
Espruino treats save() just the same way as it did previous digitalWrite(..., var... and function(...: Espruino interprets save() and while doing justice to the 'command' it saves - or - simply copies the RAM content to the FLASH, which means that now the value 5 as variable named v and the source of the function body as function named turnOnLED1 are stored in Espruino's FLASH... firmly and safe from power loss... and for 're'-use... later on.
Disconnect Espruino from Web IDE and de-power/unplug it, then plug it back in and re-connect.
The LED1 is not/does not come on, and nothing else really visible happens... but Espruino copies the FLASH content back to RAM - restores the Espruino machine state, such as the RAM (and some other things) so they becomes accessible / usable again:
Just type v into the console and press Enter and you get a (high) 5 back. Entering turnOnLED1() will invoke the (re)stored function code and latter turns LED1 on. Espruino interprets v, finds it as variable with value 5 and prints the value in the console. Espruino interprets turnOnLed1, finds it as a function and the following open-close parentheses () makes Espruino to execute it.
Looking at any of your code you upload, you will see just 'code pieces' that have either immediate effect or are 'stored' under a name for 'later' use.
For example, if you want to turn on LED1 on power on, add (upload), for example,function onInit(){ turnOnLED1 (); } *before you save*. This will bottom line - as you just learned by experience - store the invocation of turnOnLED1 function as function with the name onInit in the RAM, and on save() in the FLASH.
Note: If you use the Web IDE editor for entering the code, the final code you upload and save looks like the code below. The save() is NOT part of the uploaded code. You enter save() command after uploading the 'final cod version'; save() is only used when the code ready to be run in disconnected, re-powered state. To save intermediate states, use the save code to disk and load code from disk functions (buttons located just above upload to board button).
digitalWrite(LED1, 1);
var v = 5;
function turnOnLED1() { digitalWrite (LED1, 1); }
onInit() { turnOnLED1(); }
On power on, Espruino looks foronInit() function in RAM and executes it as first thing, after it has restored RAM content from FLASH.
In (most) other environments, on power on, (application) code execution starts at a particular, predefined location in the FLASH.
There is more to upload and save, such as uploading referenced modules and minification of uploaded code - latter to use less memory and execute/interpret faster... - ...'saved' for another post.
Very clear and detailed. Thanks. One small question. For the Arduino(Uno) they are distinguishing between Flash memory and EEPROM. Are they the same for the Espruino ?
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
A few things... like 2 cents :)
Something most not-understood about Javascript Espruino is the fact that - with default settings - source code from within the IDE code editor is already processed - executed - by Espruino interpreter on the board on upload and *stored in the (volatile) RAM only. An upload independent
save()
command in the console is required to save the cod in non-volatile Flash EEPROM to be available again after a power cycle. With most other environments (and languages), the source code is 'completely' transformed - compiled - into executable machine code before upload, and uploading is a plain copying of that code into the FLASH (EEPROM) (of the chip). Default settings has 'save on upload un-checked'.Upload on Espruino uses the REPL nature and state of Espruino in connected mode and the interpretative nature of JavaScript with the small modification: no-print: echo is while uploading. About REEPL, see for example Wiki Read-eval-print_loop.
Let's play out the story on 'the subject' while moving on in this post. For that, we start with a clean slate: connect to the board with the Web IDE and enter
reset()
in the console (left pane).That any code is processed by Espruino on upload becomes most noticeable when sending following code source string
digitalWrite(LED1,1);
to the board. Send the code by either typing it in the console and pressing Enter or by typing it in the editor - right pane - and clicking the upload 'button'.At the very moment the code arrives - streams in - to Espruino board, Espruino's Javascript interpreter interprets it, and therefore turns LED1 on.
Let's look at some more things we upload - one after the other:
The code source string
var v = 5;
tells the interpreter to establish a variable by the name of v in a piece of RAM and set it to the value of 5. Note: If you use the editor pane to upload, add this code to the code that turns on LED1.The code source string
function turnOnLED1() { digitalWrite (LED1,1); }
tells the interpreter to establish a function by the name of turnOnLED1 in a piece of RAM and set it to the function body's source code, the code between the curly braces, and - as expected - nothing else happens.Note: If you use the editor pane to upload, add this code to the code already in the editor pane.For the sake of understanding what
save()
really does, execute it now by entering it in the console.Espruino treats save() just the same way as it did previous digitalWrite(..., var... and function(...: Espruino interprets save() and while doing justice to the 'command' it saves - or - simply copies the RAM content to the FLASH, which means that now the value 5 as variable named v and the source of the function body as function named turnOnLED1 are stored in Espruino's FLASH... firmly and safe from power loss... and for 're'-use... later on.
Disconnect Espruino from Web IDE and de-power/unplug it, then plug it back in and re-connect.
The LED1 is not/does not come on, and nothing else really visible happens... but Espruino copies the FLASH content back to RAM - restores the Espruino machine state, such as the RAM (and some other things) so they becomes accessible / usable again:
Just type
v
into the console and press Enter and you get a (high) 5 back. EnteringturnOnLED1()
will invoke the (re)stored function code and latter turns LED1 on. Espruino interprets v, finds it as variable with value 5 and prints the value in the console. Espruino interprets turnOnLed1, finds it as a function and the following open-close parentheses () makes Espruino to execute it.Looking at any of your code you upload, you will see just 'code pieces' that have either immediate effect or are 'stored' under a name for 'later' use.
For example, if you want to turn on LED1 on power on, add (upload), for example,
function onInit(){ turnOnLED1 (); }
*before you save*. This will bottom line - as you just learned by experience - store the invocation of turnOnLED1 function as function with the name onInit in the RAM, and on save() in the FLASH.Note: If you use the Web IDE editor for entering the code, the final code you upload and save looks like the code below. The save() is NOT part of the uploaded code. You enter save() command after uploading the 'final cod version'; save() is only used when the code ready to be run in disconnected, re-powered state. To save intermediate states, use the save code to disk and load code from disk functions (buttons located just above upload to board button).
On power on, Espruino looks for onInit() function in RAM and executes it as first thing, after it has restored RAM content from FLASH.
In (most) other environments, on power on, (application) code execution starts at a particular, predefined location in the FLASH.
There is more to upload and save, such as uploading referenced modules and minification of uploaded code - latter to use less memory and execute/interpret faster... - ...'saved' for another post.