Something is wrong - PICO

Espruino Original/Pico/Puck lesson learned:

LESSON 1

DO NOT have directly or indirectly immediate_executed / upload_executed dynamic code in your application - especially timers - such as:

// directly immediate_executed:
// ... some code
setTimeout(function(){ ...
  }, 100);
// ... some more code

or

// directly immediate_executed:
// ... some code
function myFunction() {
  ...
}
setTimeout(myFunction, 100);
// ... some more code

or

// indirectly immediate_executed:
// ... some code
function myFunction() {
  ...
}
function myOtherFunction() {
  setTimeout(function(){ ...
    }, 100);
  setTimeout(myFunction, 100);
// ... some more code
myOtherFunction();
// ... and some more code...

All of the above examples will get timers going already while uploading which most likely get you into troubles, especially when you

• have save on upload enabled in IDE settings
  
• have save() as last statement in your code - which y0u should not have anyway
  
• type save() in the console after upload
  
  

Best case is that the code works in development mode, but if you then save(), disconnect from IDE and just power it for running stand-alone, it most likely will not work as expected.

Reason why you should NOT have immediate_executed / upload_executed dynamic code in your application is that execution of this code may interfere already with the upload (has been experienced), interfere with the save() as explained in this conversation, ...and in general because you cannot reliably control the sequence in which things happen.

Remedy is - first - to put everything(XX) into functions, and - second - to call the functions as needed and in correct sequence in the onInit() { ... } function (or register them in correct sequence with E.on("init", myFunction);. This way it is guaranteed that invocation will happen on power cycle / power up initialization.

DO THIS:

// ... some code
function myFunction() {
  ...
}
function myOtherFunction() {
  setTimeout(function(){ ...
    }, 100);
  setTimeout(myFunction, 100);
// ... some more code
function onInit() {
  myOtherFunction();
}
// ... and NO MORE code...

(XX)everything is best practice and means also initializations, because some initializations are dynamic as well (as experienced with things such as require("module").connect(...); - because you cannot control what the particular .connect() actually does). Setting pin modes and settings of certain communication instances, such as Serial1, SPI1, I2C1, etc, you can have in directly or indirectly immediate_executed / upload_executed code - because @Gordon took care of saving state on save() and re-instating that state before (user) initializations (onInit() and E.on("init", ...)...@Gordon is such a nice and helpful guy to make live for us easy,... or lazy, but when you want to be lazy, you have to know how and what you do - lazy).

Note that with above example nothing application-wise happens on or after upload when Web IDE save on upload is disabled. There is no need to enable it (and unnecessarily wear down you FLASH). Just enter onInit() in the Web IDE's console to get your code started 'exactly' as it happens on power cycle / power up. If you are - smart - lazy and do not forget to delete an extra line before save(), add - for development convenience - onInit(); as extra and last line to your code. But as said: remove it before you save your code (Personally, I prefer using onInit() over multiple E.on("init",...) because it enables the lazy development mode...).

But for the sake of defensive, deterministic, and robust coding, it is best (practice) to put these things into functions too and invoke them the same - sequence controlled way - as the other functions with dynamic code.

For background details, take a look at the two times 2 cents posts #8 and #18 of conversation about simple explanation how to save code that espruino run on start?.