Problem with Graphical Designer

G) Enhance the program according to attachment 7 (1st in this post): How busy is Espruino with blinking

We use something new: Lists to record the busy times and list them at the end.

Printing the times gets graphically so cumbersome, that we use code to do it...

It can be done graphically, but like the insert/add at the end of the list of time taks a lot do vs. the comparable code times.push(getTime() - startTime);, printing the list with the times would need quite some space, and for the actual printing in the log, still code to do it... Therefore, going right away for the code gets it done...

And from the reported busy times we notice that Espruino spends about a (one) (1) millisecond in the blinking code: 1/1000 second. All the other 999 milliseconds it is still available to handle other events and tasks. Applying the busy times to the solution with the 2 waits of 1 second each, Espruino would show completely busy all the time until interruption...

For some icing on the cake, let's switch to the text editor, where we can see the code sent to Espruino for the last uploaded - graphic edited - program:

// Code from Graphical Editor
var times;
var state;
var count;
var startTime;

function blink() {
  state = false;
  count = 0;
  times = [];
  digitalWrite(LED2, false);
  setInterval(function() {
    startTime = getTime()
    ;
    state = !state;
    if (state) {
      count = count + 1;
    } else {
      if (count >= 10) {
        eval("clearInterval(); // Enter JavaScript Code Here");
        digitalWrite(LED2, true);
        setTimeout(function() {
          listBusyTimes(times);
         }, 0.5*1000.0);
      }
    }
    digitalWrite(LED1, state);
    times.splice(times.length - 1, 0, getTime()
     - startTime);
   }, 1*1000.0);
}

function onInit() {
  blink();
}

function listBusyTimes(times) {
  eval("times.forEach(function(t,i){ console.log(Math.floor((i+2)/2)+((i%2===­0)?\" on:  \":\" off: \")+t); });");
}

We notice that the code entered in the general purpose code block is evaluated from source as string. Dropping the eval function, the begin and end double quotes, and eventual double quote escapes make it almost look like an inline code. Further noticeable is that the scoping of variables has a bit shifted... to say the least. If variable scope is consciously applied it can lead to overwritings in outer scopes.

Last but not least we are are read to take a look at working implementation based the initial idea of two consecutive waits 10 times repeated. The 'proper' setup uses timeouts for the waits and defers the execution of the remaining code following the 'wait'. The 'loop' is constructed as a deferred self invocation of the blinkCycle (not the same as a recursion).

H) Modify the program according to attachment 8 (2nd in this post): Blink with proper waits implemented as timeouts and loop as deferred self-invocation

Notice that the undesired scope shift of variables makes the code actually work: variable count is defined in function onInit(), which - when accordingly transformed to code - would be local to this function an invisible - inaccessible - by the blink-cycle function.

Scoping is any already a critical item in JavaScript, but a code generation that shifts declarations around can lead to crash and data corruption. Keeping the variable names across the whole program - globally unique, independent of the scope - prevents such contentions.

2 Attachments