Search results for:

( See updated version of module)

Was looking for some serially connected RAM that has to briefly hold on to some processing data (not like EEPROM / SDCard) and has to be very fast. Came across this thing and it has great specs (datasheet attached). Ordered - 2 pieces - and got package yesterday. 'Tin-glued' it to Espruino board, added some more machined socket pins for connecting. With hardware 'complete', I started coding...

Reading the device ID got pretty quickly going... even though not standard. Everything after that became just rubbish... and still is. Nevertheless, I publish it here...

// FRAMSPI_inline.js (c) muet.com

// F RAM SPI Module

var framspiModule = { connect: function(spi,cs,hd,wp) {
  pinMode(cs,"output"); cs.set();
  if (hd) { pinMode(hd,"output"); hd.set(); }
  if (wp) { pinMode(wp,"output"); wp.set(); }

  var fram = 
{ id: function() {
    var d = spi.send(
      [0x9F,0x01,0x01,0x01,0x01,0x01,0x01,0x01­,0x01,0x01]
     ,cs); // chip select, write 0x9F, send 10*0x00 not working
    return d;
  }
, stat: function() { 
    var d = spi.send(
      [0x05,0x00]
     ,cs);
    return d;
  }
, wen: function() {
    spi.write(
      [0x06,0x00]
     ,cs);
  }
, wdi: function() {
    spi.write(
      [0x04,0x00]
     ,cs);  
  }
, read: function(a,n){
    cs.reset();
    spi.write([0x03,0x00,0x00]);
    var d = new Uint8Array(n);
    while (n>0) { n--; d[n] = spi.send(0x00); } 
    cs.set();
    return d;
  }
, write: function(a,d){
    cs.reset();
    spi.write([0x02,a>>8,a]);
    spi.write(d);
    spi.write([0xFF]);
    cs.set();
  }
};
  return fram;
}
};

SPI2.setup({sck:B13, miso:B14, mosi:B15, baud: 1000000});

var fram = framspiModule.connect(SPI2,B12);

console.log(fram.id());

/*
fram.write(  0,"FRAM@000");
fram.write(  8,"FRAM@008");
fram.write( 16,"FRAM@016");
fram.write(128,"FRAM@128");
fram.write(256,"FRAM@256");
fram.write(512,"FRAM@512");

console.log("@000:",fram.read(  0,  8));
console.log("@008:",fram.read(  8,  8));
console.log("@016:",fram.read( 16,  8));
console.log("@128:",fram.read(128,  8));
console.log("@256:",fram.read(256,  8));
console.log("@512:",fram.read(512,  8));
*/

The challenge is in SPI. Having done some work with the ILI9341 SPI LCD controller, I though: piece of cake... wrong. The FRAM's SPI is behaving weird: bytes get stuck in the output buffer and are read the next time. Also randomly dummy bytes are inserted for no obvious reason. Elaborating and trying to track some of the signals lead to the death of one chip... an so I had hope that the second would fair better. So far I can say: work different... actually more annoying: the broken chip could handle ID-read followed by a status-read. The new chip inserts dummy bytes so that the first status read has just those, as you can see in the output below (chip ID shows on upload, fram.stat() is called with a command n console):

 1v70 Copyright 2014 G.Williams
>echo(0);
[ 255, 127, 127, 127, 127, 127, 127, 194, 34, 0 ]
=undefined
>fram.stat();
=[ 255, 255 ]
>fram.stat()
=[ 255, 0 ]
> 

Tried to add other dummy byte, but this makes it even worse. Somehow, the chip does not follow its own spec which says that when chip select (CS) goes high, the SPI transaction is considered complete, even though send may not have completed yet.

It seems, that only continuously sending / receiving works to some degree: everything packed in a Uint8Array - including the command and parameters - and SPI.send() it a once. Using a mix and mach of SPI.write() and SPI.send() fails.

Looking for answers I came across hints that the SPI behavior is a bit unique... something about having to keep the clock going...

I have not given up yet, but if things do not smoothen out soon, I will look for a different solution.... :(

...may be you could... and if poking does not get you there, poked assembler/machine code get's you there... but you should not... otherwise why Espruino/JavaScript in the first place (with which you then would mess). I like Espruino's implementation very much: it translates / maps the internal/low level things into the JavaScript application language layer. It even has the support for managing bursts of interrupts: they are queued in order to not get lost... and it convey as much 'realtime' feeling as possible: with the interrupt, additional context information - most importantly the time of the interrupt *including the time of the previous one - is provided and makes it available to the application. When the JavaScript engine finally catches up - the (next) interrupt is picked up from the queue and handled on the JavaScript level. So you could say: hardware events are mapped to software event, like you are used to Web-program on a button onclick="someJavaScript...;". Clicking with the mouse is a very hardware event, but it is finally handled in the application layer through a software event.

@favo - I updated previous post... because I'd left some stuff out... I hope that after having made it too simple the first time, the second edition is not adding (too much) confusion.

STM32F103's GPIOs are extremely versatile, hence GPIO configuration and understanding of GPIO behavior IS a challenging... there are quite many publications and forum posts and... out there, in addition to ST's chip manual. Google it with https://www.google.com/search?q=GPIO+STM­32F103

JavaScript in the browser is single threaded... and therefore, concurrency issues are rarely a problem.

It becomes a challenge when the native UI elements, for example, an input field is multi-threaded handled, and JavaScript can not made aware of that (The DOM and JavaScript events are not transaction like handled: While javascript does something on a key event, such as reading parameters from from the natively updated DOM, the values read are in flux because of the multi-threadedness of the operating system and native IO field updating on the next key stroke before JavaScript has completed is first event / service routine. The picture of the input field JavaScript gets can get inconsistent to - looking like - corrupted, and the JavaScript code is then flagged faulty...).

I wonder how Espruino handles the the update of interrupt handles that are held and controlled natively as well as in the JavaScript domain, such as the handles for setWatch(), setTimeout(), *setInterval(),... I use the following construct in the TOUCHR - module (for more details see http://forum.espruino.com/comments/11918­647/):

tr.listen = function(b) {
    tr.l = b; if (b) { if (!tr.w) { 
    pinMode(xn,"input_pulldown");
    digitalRead(xp);
    digitalWrite([yn,yp],3);
    tr.w = setWatch(tr.track,xp,{edge:rising, repeat:false});
  } } else {
    if (tr.w) { clearWatch(tr.w); tr.w = null; }
  } return tr;
};

I wonder whether something relevant to my JavaScript application logic can happen in the time between the checking of the watch (handle tr.w) and the clearing of it, and if so, what would it be, and how would I be able to detect.

May be this question is trivial with (absolute) insight in the firmware, but I'm just not there yet and would like to know know for my design thoughts.

I'm sure you might miss some of APL's terseness in todays again verbose, COBOL like languages, such as Java. I miss some of Smalltalk's concise and consistent application of oo thinking combined with minimal syntax noise. From the constructs I like JavaScript a lot - just miss classes being 1st class objects... (which practically no other commonly used languages support either).

@Manxome, it does... and very cool, jus as @thomc explains. Did JS a while a go for a lot... in 97, but got laughed at a lot by the .jsp 'fans' - even by my own kin - ... guess what: it's back bit time, for a while now and is THE client platform (with SimglePageApps instead of .jsp Web pages etc.). The mid 80' through mid 90' regarding client-server enjoying renaissance riding the easy to use Web http(s) protocol wave.

Espruino uses interrupts for the setTimeot() and setIntervall(),

Espruino is THE thing for exactly just one (1) battery for a life time due to the interrupt drivenness of the whole infrastructure.

Put setBusyIndicator(LED1) and *setSleepIndicator(LED2) into your code and then you see how Espruino goes from activity to no activity to absolute silent Zzzzzzzzzz... until the next event wakes it up... totally different to the do loop in arduino's main.

Arduino uses its speed to make you believe it is 'on interrupt'... and burns just (m)Amps... doing nothing but checking if it should do something or doing what you unconditionally tell to do. Yes, you can used interrupts too. Espruino does use interrupts for all it does. Espruino even provides commands to go to sleep and deep sleep... almost deep freeze... and comes back pretty quickly without frost bites... ;-)

Your app knows when to enter what state and can use these commands. See examples used in reference.

What programming languages did you use in the past?

Dropped comments and related code are the subjects of this post.

Comment/code sketching the implementation design.

p16 = // puzzle16 game (x=4,y=4) - x,y variable (screen size too)
      // - x*y-1 = m pieces with values 0..x*y-2 (regular piece) 
      // - empty slot is virtual piece w/ value -1 (empty piece)
      // - ps = y*x pieces arr of arrays [row=y][col=x] = [value]
      // - ls = x*y locations by value array [value] = [y,x]
{ h: "Puzzle 16"
, t: 0
, .....

Comment/code sketching the main line tpd(x,y) method:

// tapped on screen at pixel xp,yp
//  ? i = inside of game board
//    update time display
//    x = piece x coord 0..x-1
//    y = piece y coord 0..y-1
//    ? top porch / banner menu (above pieces)
//      handle top menu
//    :? pieces reg y (above bottom porch / footer menu)
//      ? pieces reg x
//        p = piece @ x y, n = value of piece
//        ? piece (not empty 'piece')
//          ex ey = x y of empty piece
//          ? ey of empty piece == y of piece
//            move vertically +-y
//          : (ex of empty piece == x of piece)
//            move horizontally +-x
//    : (bottom porch / footer menu (below pieces))
//      handle bottom menu -+x, -+y, scramble, and 'orderly'
//  return i (=true when inside game board and handled)   
, tpd: function(xt,yt) { var i,xr,yr,xo,yo,dp=this.d;
    if ((i =    (xt>=this.x0) && (xt<this.x0+this.xp)
             && (yt>=this.y0) && (yt<this.y0+this.yp) )) {
      this.upd(Math.floor(getTime() - this.t),this.ts);
      var x = Math.floor((xr=(xt-(xo=this.x0+this.bl-1­)))/dp);
      var y = Math.floor((yr=(yt-(yo=this.y0+this.bt-1­)))/dp);
      if (y < 0) {
      } else if (y < this.y) {
        if ((x >=0) && (x < this.x)) {
          var p = this.ps[y][x], n = p[0];
          if ( n >= 0) {
            var ey = this.ls[this.m][0], ex = this.ls[this.m][1];
            var e = this.ps[ey][ex];
            if (ey == y) { this.c++;
              this.mvx(y,x,e,ex,(ex<x) ? +1 : -1,yo,xo,dp);
            } else if (ex == x) {
              this.mvy(y,x,e,ey,(ey<y) ? +1 : -1,yo,xo,dp);
            }
          }
        }
      } else { x = Math.floor(xr/((this.xp-2*2)/8));
              console.log(x);
        if        ((x ===  0) && (this.xn>3)) {
          this.xn--; this.upd(this.xn,this.xns);
        } else if ((x ==   1) && (this.xn<7)) { 
          this.xn++; this.upd(this.xn,this.xns);
        } else if ((x ==   2) && (this.yn>3)) { 
          this.yn--; this.upd(this.yn,this.yns);
        } else if ((x ==   3) && (this.yn<7)) { 
          this.yn++; this.upd(this.yn,this.yns);
        } else if (x>3&&x<6) { 
          this.scr(this.xn,this.yn);
        } else if (x>5&&x<8) { 
          this.lup(this.xn,this.yn);
        }
      }    
    } return i;
  }

Comments added to code only available in this post:

// .....
p16 = // .....
      // ....
{ h: "Puzzle 16" // not used yet / anymore - default values:
, t: 0     // getTime() of game begin
, ts: []   // time [fontsize,x,y] display specs for upd(v,s) 
, c: 0     // count of moves set to 0 at game begin
, cs: []   // count [fontsize,x,y] display specs for upd(v,s) 
, X: 240   // display size x - not used yet / anymore
, Y: 320   // display size y- not used yet / anymore
, x0: 0    // x / left in display of board top/left corner
, y0: 0    // y / top in display of board top/left corner
, xp: 240  // x board size in pixels
, yp: 320  // y board size in pixels
, x: 4     // x - horizontal - number of pieces (columns)
, y: 4     // y - vertical - number of pieces (rows)
, xn: 4    // x next for the next scramble or orderly setup
, yn: 4    // y next for the next scramble or orderly setup
, xns: []  // x next [fontsize,x,y] display specs for upd(v,s) 
, yns: []  // y next [fontsize,x,y] display specs for upd(v,s)
, m: 15    // max internal piece val 0..x*y-1, m = 'empty' piece 
, bl: 2    // border left in pixels
, bt: 40   // border top in px for time and moves display
, br: 2    // border right
, bb: 40   // border bottom for menu (+-x, +-y, SCR, ORD)
, xe: 0    // x (column 0..x-1) position of empty slot (piece) 
, ye: 0    // y (column 0..y-1) position of empty slot (piece)
, d: 60    // piece with and height (is always calc'd on scr / ord
, clrs: [[0,0,0],[1,1,1],[1,1,0],[0,0,1]] // rgb colors 0..3 used
, ps: []   // pieces (piece itself if array with value as 1st elt)
, ls: []   // locations of pieces by value (empty slot is last)
// tapped on screen at pixel xp,yp
//  .....

So much so far...

My initial project with Color TFT LCD w/ Touch Screen - PacMan game - did not move much forward, nor did my second one - DIY Marine GPS, see http://forum.espruino.com/conversations/­127039 and http://forum.espruino.com/conversations/­255759.

First I wanted to get more field testing going for my direct implementation for resistive touch screen (see http://forum.espruino.com/conversations/­256122).

So I came up with this little nice game... I started out with 4*4-1 pieces, and had it - with bare UI - up to 9*9-1 - just displaying the tiles area and just having logic for creating the 'orderly' board and moving tiles. My UI enhancements then cut me short with Out of Memory to a max of 5x5-1... even after getting rid of some nice code commenting. I will bring some of the comments back in this post.

Two conclusions:

1. Arrays were killers 40+ years ago, and still are today!
   
2. Viva Pico! *I'm looking very much forward to a chip with more memory, seriously...
   
   

There are good news though, despite the OutOfMemory incident: The TOUCHR module got hardened: n = n - 1 with n = number of bugs (n closing in on 0).

Moving tiles around sometimes still freezes the system... no clue why, even after noticing that sometimes my TOUCHR module was not listening anymore (after telling twice to listen... fixed the code in the listen() method. If you use my code from the other post, fix it like this to ignore a listen() command while already listening(). (The faulty code did a partial toggle and left touch detection in a weird state):

  tr.listen = function(b) {
    tr.l = b; if (b) { if (!tr.w) { // <-- fix  
    pinMode(xn,"input_pulldown");
    digitalRead(xp);
    digitalWrite([yn,yp],3);
    tr.w = setWatch(tr.track,xp,{edge:rising, repeat:false});
  } } else { // <-- fix
    if (tr.w) { clearWatch(tr.w); tr.w = null; }
  } return tr;
};

To get a better handle on discovering a freeze, I put a setBusyIndicator(LED3); into the code to see if it is my listening or something else. I noticed, that when the system is frozen and needs either a hard-reset or power-cycle, it is busy and never goes to sleep again. It could be that some unchecked run away in array or most likely the graphics is messing with me... (after me messing with boundaries... sooooorrrrrrry! - Tschumpuhung - find the translation yourself).

Back into the - Puzzle 16 - game: this is the code:

// puzzle16_inlineRC.js (c) muet.com

// puzzle 16 game

// ********* following inline TOUCHR code is only part of attached file
// var touchrModule = { connect: function(xn,xp,yn,yp,callback,C) {
// ...

var lcd, touchr, p16;

SPI1.setup({sck:B3, miso:B4, mosi:B5, baud: 1000000});
var lcd = require("ILI9341").connect(SPI1, B6, B8, B7, function() {
 lcd.clear();

p16 = 
{ t: 0
, ts: []
, c: 0
, cs: []
, X: 240
, Y: 320
, x0: 0
, y0: 0
, xp: 240
, yp: 320
, x: 4
, y: 4
, xn: 4
, yn: 4
, xns: []
, yns: []
, m: 15 
, bl: 2
, bt: 40
, br: 2
, bb: 40
, xe: 0
, ye: 0
, d: 60
, clrs: [[0,0,0],[1,1,1],[1,1,0],[0,0,1]]
, ps: []
, ls: []
, tpd: function(xt,yt) { var i,xr,yr,xo,yo,dp=this.d;
    if ((i =    (xt>=this.x0) && (xt<this.x0+this.xp)
             && (yt>=this.y0) && (yt<this.y0+this.yp) )) {
      this.upd(Math.floor(getTime() - this.t),this.ts);
      var x = Math.floor((xr=(xt-(xo=this.x0+this.bl-1­)))/dp);
      var y = Math.floor((yr=(yt-(yo=this.y0+this.bt-1­)))/dp);
      if (y < 0) {
      } else if (y < this.y) {
        if ((x >=0) && (x < this.x)) {
          var p = this.ps[y][x], n = p[0];
          if ( n >= 0) {
            var ey = this.ls[this.m][0], ex = this.ls[this.m][1];
            var e = this.ps[ey][ex];
            if (ey == y) { this.c++;
              this.mvx(y,x,e,ex,(ex<x) ? +1 : -1,yo,xo,dp);
            } else if (ex == x) {
              this.mvy(y,x,e,ey,(ey<y) ? +1 : -1,yo,xo,dp);
            }
          }
        }
      } else { x = Math.floor(xr/((this.xp-2*2)/8));
        if        ((x ===  0) && (this.xn>3)) {
          this.xn--; this.upd(this.xn,this.xns);
        } else if ((x ==   1) && (this.xn<5)) { 
          this.xn++; this.upd(this.xn,this.xns);
        } else if ((x ==   2) && (this.yn>3)) { 
          this.yn--; this.upd(this.yn,this.yns);
        } else if ((x ==   3) && (this.yn<5)) { 
          this.yn++; this.upd(this.yn,this.yns);
        } else if (x>3&&x<6) { 
          this.scr(this.xn,this.yn);
        } else if (x>5&&x<8) { 
          this.lup(this.xn,this.yn);
        }
      }
    }
    return i;
  }
// move horizontally +-x
, mvx: function(y,x,e,ex,d,yo,xo,dp)  {
    var p, xp = xo + ex * dp, yp = yo + y * dp;
    this.c++; this.upd(this.c,this.cs);
    lcd.setFontVector(dp*0.6);
    while (ex != x + d) {
      if (ex == x) {
        p = this.ps[y][ex] = e;
        this.ls[this.m] = [y,ex];
      } else {
        p = this.ps[y][ex] = this.ps[y][ex + d];
        this.ls[p[0]] = [y,ex];
      }
      this.drp(p,xp,yp,xp+dp-1,yp+dp-1);
      ex += d; xp += d * dp;
    }
  }
// move vertically +-y
 , mvy: function(y,x,e,ey,d,yo,xo,dp) {
    var p, xp = xo + x * dp, yp = yo + ey * dp;
    this.c++; this.upd(this.c,this.cs);
    lcd.setFontVector(dp*0.6);
    while (ey != y + d) {
      if (ey == y) {
        p = this.ps[ey][x] = e;
        this.ls[this.m] = [ey,x];
      } else {
        p = this.ps[ey][x] = this.ps[ey + d][x];
        this.ls[p[0]] = [ey,x];
      }
      this.drp(p,xp,yp,xp+dp-1,yp+dp-1);
      ey += d; yp += d * dp;
    }
  }
// draw pieces
, drw: function() {
    var p,x=this.x,y=this.y,d=this.d;
    var x1=this.x0+this.bl-1,y1=this.y0+this.bt-­1;
    var x2=this.x0+this.xp-this.br,y2=this.y0+th­is.yp-this.bb;
    this.clr(0); lcd.fillRect(x1,y1,x2,y2);
    y1=y1-d; y2=y1+d-1; lcd.setFontVector(d*0.6);
    for (var yx = 0; yx<y; yx++) {
      y1 += d; y2 += d; x1=this.x0+this.bl-1-d; x2=x1+d-1;
      for (var xx = 0; xx<x; xx++) {
        x1 += this.d; x2 += d; p = this.ps[yx][xx];
        this.drp(p,x1,y1,x2,y2);
      }
    }
  }
// draw piece - 1..m*n-1(0..this.m-1=x*y-2) - empty: -1
, drp: function(p,x1,y1,x2,y2) {
   var n=p[0],rgb = this.clr(1 + ((n<0) ? 0 : n % 2 + 1));
   if (n>=0) {
     lcd.fillRect(x1,y1,x2-1,y2-1);
     var c = (rgb[0]*4 + rgb[1]*2 + rgb[0])^7;
     lcd.setColor(c&4,c&2,c&1);
     var o = this.d * 0.0125;
     lcd.drawString(n+1,x1+o*((n>8) ? 1 : 20),y1+o*14);
   } else {
     this.clr(0);lcd.fillRect(x1,y1,x2-1,y2-1­);
   }
  }
// line up pieces (value pair optional)
, lup: function(x,y) {
    this.ein(false);
    this.inp(x,y);
    this.drw();
    this.ein(true);
  }
// scramble pieces
, scr: function(x,y) {
    this.ein(false);
    this.inp(x,y);
    var c,p1,p2,r1,r2,s=(this.m+1)*3;
    for (c=0; c<s; c++) {
      p1 = this.ls[r1 = Math.floor(Math.random() * this.m)];
      p2 = this.ls[r2 = Math.floor(Math.random() * this.m)];
      this.ls[r2] = p1; this.ls[r1] = p2;
    }
    for (c=0; c<=this.m; c++) {
      this.ps[this.ls[c][0]][this.ls[c][1]][0]­ 
        = (c<this.m) ? c : -1;
    }
    this.drw();
    this.ein(true);
  }
// init pieces (value pair optional)
, inp: function(x,y) {
    this.spl(x,y);
    var n = -1;
    this.ps = new Array(this.y);
    this.ls = new Array(this.m+1);
    for (var yx=0; yx<this.y; yx++) {
      this.ps[yx] = new Array(this.x);
      for (var xx=0; xx<this.x; xx++) { n++;
        if (n < this.m) {
          this.ps[yx][xx] = [n];
          this.ls[n] = [yx,xx];
        } else {
          this.ps[yx][xx] = [-1];
          this.ls[n] = [yx,xx];
        }
      }
    }
  }
// set color
, clr: function(iorgb) {
    var rgb=(isNaN(iorgb)) ? iorgb : this.clrs[iorgb];
    lcd.setColor(rgb[0],rgb[1],rgb[2]);
    return(rgb);
  }
// update value as specified
, upd: function(v,s) {
    lcd.setFontVector(s[0]); var xd = lcd.stringWidth(v);
    this.clr(0); lcd.fillRect(s[1],s[2],s[1]+xd,s[2]+s[0]­);
    this.clr(1); lcd.drawString(v,s[1],s[2]);
  }  
// set pieces x*y, @ x0,y0 size area xp*yp px
//     paddings left,top,right,bot, lcd X*Y px
, spl: function(x,y,xp,yp,x0,y0,bl,bt,br,bb,X,Y­) {
    if (X && Y) { this.X = X; this.Y = Y; }
    if (x && y) { this.x=this.xn=x; this.y=this.yn=y; }
    if (xp && yp) { this.xp = xp; this.yp = yp; }  
    if (!isNaN(x0)) { this.x0=x0; }
    if (!isNaN(y0)) { this.y0=y0; }
    if (!isNaN(bl)) { this.bl=bl; }
    if (!isNaN(bt)) { this.bt=bt; }
    if (!isNaN(br)) { this.br=br; }
    if (!isNaN(bb)) { this.bb=bb; }
    var dxm = (this.xp - this.bl - this.br) / this.x;
    var dym = (this.yp - this.bt - this.bb) / this.y;
    this.d = Math.floor((dxm < dym) ? dxm : dym);
    this.m = this.x * this.y - 1;
  }
// init
// x*y pieces, xp*yp display area 
, ini: function(x,y,xp,yp,x0,y0,bl,bt,br,bb,X,Y­) {
    this.spl(x,y,xp,yp,x0,y0,bl,bt,br,bb,X,Y­);
    this.inf();
    this.inp();
    this.drw();
    this.ein(true);
  }
// init frame
, inf: function() {
    var x1=this.x0,y1=this.y0;
    var x2=x1+this.xp-1,y2=y1+this.yp-1;
    this.clr(0); lcd.fillRect(x1,y1,x2,y2);
    this.clr(1); lcd.drawRect(x1,y1,x2,y2);
    var x=x1+2, y=y1+this.yp-this.bb+1;
    var s=Math.floor((x2-x1-2*2)/4), c = Math.floor(s/3);
    var f=(c<this.bb-2)?c:this.bb-2; lcd.setFontVector(f);
    lcd.drawString("-",x,y); x+=c;
    lcd.drawString(this.xn,x,y); this.xns=[f,x,y]; x+=c;
    lcd.drawString("+",x,y); x = x1+2+s;
    lcd.drawString("-",x,y); x+=c;
    lcd.drawString(this.yn,x,y); this.yns=[f,x,y]; x+=c;
    lcd.drawString("+",x,y); x = x1+2+s*2;
    lcd.drawString("SCR",x,y); x += s;
    lcd.drawString("ORD",x,y);
    x=x1+2; y=this.y0+2;
    f=(c<this.bt-2)?c:this.bt-2;
    lcd.drawString("Time:",x,y); x+=s;
    this.ts=[f,x,y]; x+=s;
    lcd.drawString("Mvs:",x,y); x+=s;
    this.cs=[f,x,y];
  }
// enable input 
, ein: function(b) {
    touchr.listen(b);
    if (b) { var s="0      ";
      this.upd(s,this.ts); this.upd(s,this.cs);
      this.c=0; this.t=getTime();
    }
  }
};
  
  touchr = touchrModule.connect(C0,C1,C2,C3,functio­n(x,y,tr){
    if (!tr.t) { 
      if (p16.tpd(tr.x,tr.y)) { return; }
    }
   });
  setBusyIndicator(LED3);
//     pieces 4*4, in 220*300 at 10,10
//     paddings left 3,top 40,right 3,bot 40, lcd X*Y
  p16.ini(4,4,220,300,10,10, 3,40, 3,40);
 });

The UI allows you to start over with a SCRambled or ORDerly game, starting with time 0 [seconds] and 0 moves. The top shows time in seconds and number of moves since game started. The values are updated on every move and any other tap in the board area. Tapping the 'empty tile' tapping the empty spot or a tile not sharing x or y axis with the empty spot does nothing but update time.

Updating shows that a faster interface to the display controller is really a must... Some relieve is possible with using a faster - less nice - font, but may be nicer for small fonts on low resolution as shown in the 4th attached image. I'll sure look into both faster interfacing and faster font at one time.

The game is highly configurable... you can run it down to a Nokia display... looking forward to see some one picking that up. http://forum.espruino.com/conversations/­257064

I have not developed another input option yet to use when touch not available. But providing the x and y coordinates on a touch or click (with a mouse type cursor) gets you going. I was thinking of a 4-way five-button or joy-stick-with-click option. Moving around on the board could be done with a cursor - which uses save/restore curser image area (see )...speed - or more precisely - no-speed become though even more a drag for the user experience).

All parameters can be passed at initialization. Only font-size is safe and parameter calculated. The 'safety' of the other parameters are up to you. I had started to implement constraints, but with running out of memory already for the UI, I dropped it.

The board configuration has not to be square: everything from 3..5 x 3..5 goes.

More in a following post.

The attachment are:

1. Ready to run code (puzzle16_inlineRC.js - ReducedComments)
   
2. Clip with moves of tiles (P16moiving.mp4 - need to get a ...pod for my phone)
   
3. 1st Image: showing 4x4 after startup
   
4. 2nd Image: showing modified board - Puzzle25 - after tapping the +s to increase x and y each to 5 and SCR(amble)
   
5. 3rd Image: showing a 4x4 in game
   
6. 4th Image: a low resolution 3x5 in part of the display
   
   

Enjoy!

Take a look at the pinMode() function.

When pin mode is set to automatic - by executing pinMode( pin ) w/ no 2nd argument - before read or write operation, then read and write defines at the same time the wether the pin is input or output pin. The pin is not a register that you set or unset and then read back what you have set (or unset). What you get back depends on how the pin is setup in detail. For simplicity - when in auto mode - write sets the pin in output mode - and will apply power (make the pin sink or source), read sets the pin in input mode.

After ESPRUINO is started, you can ask the mode of a pin with getPinMode(pin). You will notice that different pins are set to different modes.

The A13, A14, and A15 pins - respective LED1 (red), LED2 (green), and LED3 (blue) - pins are set to 'output' - as you can verify with getPinMode(A13) - and it is in automatic mode. Executing digitalRead(A13) makes it an input. If LED1 was off before the read, you get 0 back, and when LED1 was on, you get 1; but notice that when it was on, the read will making it to go off, because the pin is not powered anymore.

When pin mode is with second argument - pinMode(pin,mode) with mode a string that is either 'input', 'input_pullup', 'input_pulldown', 'output', 'opendrain', 'af_output' or 'af_opendrain' - the mode is fixed set, and digitalRead(), analogRead(), digitalWrite(), and analogWrite() do not change the input/output mode.

Interesting though is, than when you do a digitalWrite(A13,1) while A13 is in fix input mode ('input', 'input_pullup', 'input_pulldown') and then do an 'output', LED1 goes on... because A13 output register is now connected with pin...

Returning back to automatic mode, execute a pinMode(pin) - no 2nd argument.

About open and pulled-up/down input:

1. floating input - if nothing is connected and you read, it is not defined what you get... the noise may give you a 1 or 0 for digitalRead() or a value from 0.000...0.999 (almost 1) for analogRead(). If you connect the pin with 0V(Ground/GND) or 3.3V with something no matter how weak - like a resistor of 100M - you will get a 0 or 1 for digitalRead () and a 0.000 or 0.999 (almost 1) for an analogRead().
   
2. pulled-up input - is an input that has an internal connected to 3.3V over a 30..40KOhm resistor. Of nothing is connected and you read you get 1 and 0.9999..., respective. If you connect something that has less resistance than the internal pull-up resistor to 0, you get 0 and 0.000, respective. If you connect it to 3.3V, you get the same readings as with no connection.
   
3. pulled-down input - is like 2., but with reversed values for your readings: unconnected 0 and 0.000, respective.
   
   

Attached schematics may help a bit. Google found it for me and with a bit poking around in the Web, I came across these http://www.gahum.com/index.php?title=EDU­CATIONAL&subtitle=PROGRAMMING, http://112.210.106.111/ECE423/ links... which ended up on the .pdf w/ the schematics - http://112.210.106.111/ECE423/ECE423N_DA­Y5.pdf?

Speed paid with memory... or memory paid with speed. @DaveNI, do you have some memory profiling for this approach?

@DrAzzy, as you may have noticed, I use in my code the continuation comma on the continuation line - especially when doing the object-oriented look of code - for which I IDE picks up an indentation fight as well. More over, because JS is such a micro element language, that I put physical micro statements on one line to build a logical statement or macro statement. IDE picks that up and aligns the next lines indentation with the second+ of the previous line...

This is all fine to get someone going with programming. With the screens getting wider and wider versus height, I cannot see enough code when putting just one micro thing on a line. Yes, I know, I can rotate the screen by 90 degrees and get it better for coding... (except for my laptop).

Therefore, an editor should have at least two modes: support for all who need or like a thinking editor... and for others, just a frugal support of indentation... similar to Eclipse - even though Eclipse has it's issues as well of meddling with the indentation (when copying).

But when just simple coding, it looks at the previous line and picks up the same indentation, and if a block has been opened, it adds a level. It even keeps the structure of the indentation which can be spaces and tabs, and it has a setting to use either tabs or spaces. If it gets to messy for me, I copy all I have into Eclipse or Textwrangler, do my advanced editing, and copy the whole thing back into IDE.

In an earlier post I suggested to make the IDE look at the file time stamp on disk when getting the focus (and on interval timeout) , and if it has changed it would ask in a pop-up to update to what is on disk. This way any editor could run, and IDE would be used to upload and access board. It's not the best solution but way better than copying back and forth.

...just no free lunch! ...so there was a give from your part to get the CD for us! Thanks! On the other hand, it shows recognition for Espruino as valid item and is a testimony for your contributions. We all hope that business-as-usual task from that taken-on work leaves enough room for your creativity and realization of future spoken and unspoken plans.

Ic, absolutely.

Since though no software is bug free - virtually never - things may ultimately freeze up. It happens still on a regular basis with stuff I ran, and it is so bad that the board is not even accepting commands from the console nor new code anymore. I did not have the time yet for a deeper analysis why it got there. For now I just observe to collect hints. With the setBusyIndicator() set to LED#, I hope to have some additional tool to see whether it is frozen all the way through - which I cannot believe - or if it is just way too busy - with some stupid short infinite loop - to receive commands from the console or new code and start over with. To get out of the misery, I just disconnect (w/ Chrome < 38.####) unplug the usb to the board, wait a few seconds, and plug it back in.

A hard reset should always be provided (...like a 'factory reset'). It should not be the biggest and most convenient function to be reached... but a little hole through which with a pin / paperclip the reset can be reached... (CD drives have it to physically retrieve (rescue) a CD (a real hard-hard-reset), the Palm devices had it... and many other device give the option in one way or another to have a factory reset.

@Gordon, is it possible write to the getTime() value holder? If so, the Clock object could get a method - say: push() - that would write the 'absolute' - actually any - time back to that holder and the holder now holds the 'unix birth date' or any offset date, for example AD. On a reset it is easy to detect - by the app code - if the time has been set or not - and then create a clock object with a pop()... or a-like. If the getTime() value cannot be written back, storing a 'difference' of value 'somewhere' where it survives a reset can be used to restore the 'absolute' time again. And again, it is easy to the app to detect whether the 'difference' has been set or not. Later solution would be: create a meaningful value with two meaningless values (offset of offset).

@DrAzzy, if I just could read plain English... <:| ...but thanks anyway. Cool, works with setBusyIndicator(LED1);, for example. Looking on it at the scope shows me duty cycle... I ran it on my little 'drawing' app - see http://forum.espruino.com/comments/11918­647/ - and Espruino still goes to Zzzzzzzzzz

Is there a way - and how would it be done - to show the state of the JavaScript engine? For example, I'd like to see - on a selected pin / one of the onboard LEDs - when the engine is idling, when it is busy?

CC3000 module provides this connectivity - see http://www.espruino.com/CC3000. It's on my list. The GPS part I have implemented - see http://forum.espruino.com/conversations/­255759/. If got the CC3300 Wifi board a while ago, but I'm working on some other items right now - last but not least because default connectivity for my display and and are using the same SPI and control pins.

Example code - re-formatted for narrow forum format - and explained:

var ui,touchr;
SPI1.setup({sck:B3, miso:B4, mosi:B5, baud: 1000000});
var lcd = require("ILI9341").connect(SPI1, B6, B8, B7, function() {
  lcd.clear(); B2.set();
  ui = uiModule.connect(lcd);
  touchr = touchrModule.connect(C0,C1,C2,C3,functio­n(x,y,t){
    ui.evt(x,y,t); // for ADS7843 module use: ui.evt(x,y,{t:!!x});
   });
  // UI definition (bc=border|fc=fill|tc=text color 0..7 
  //               (<0 no border); xo|yo=x|y label offset
  
  // active  x   y   w  h bc fc 
  //                callback on up                
  //                     fontVector tc xo yo label/text
  
  ui.btn(1, 30, 40, 75,40,-1, 4
                   ,function(e){ console.log("btn1");    
                               },20, 7, 5, 8,"BTN1");
  
  ui.chk(1, 30, 90, 40, 0, 2, 7
                   ,function(e,s){ console.log("chk1",s); 
                               },20, 7, 5, 8,"OK?");
  
  ui.chk(1,140, 90, 40, 1,-1, 1
                   ,function(e,s){ console.log("chk2",s); 
                               },20, 7, 5, 8,"Up?");
  
  ui.btn(1, 30,140, 90,40, 1, 6
                   ,function(e){ console.log("btn2");    
                               },20, 0,12, 8,"BTN2");
  
  ui.btn(1, 30,190,160,40,-1, 7
                   ,function(e){ console.log("btn3");    
                               },20, 0,16, 8,"Time to go!");
  
  ui.btn(1, 30,240, 60,60,-1, 5
                   ,function(e){ console.log("btn4");    
                               });
  
  ui.btn(1,100,240, 60,60,-1, 3
                   ,function(e){ console.log("btn5");    
                               });

  ui.btn(1,170,240, 60,60,-1, 6
                   ,function(e){ console.log("btn6");    
                               });
  
  touchr.listen(true); // not needed for ADS7843 module
 });

Lines 2..4 are standard setup for ILI9341 module for TFT LCD module.

Line 5 connects the display as output medium to the TOUCH UI module.

Lines 6..8 connects the TOUCHR module to the the touch screen for the input - line 6 - and to the UI as the input handler by a callbck that callse the TOUCHUI's evt() method. Event information passed is:

1. x coordinate of the touch or tracked drag
   
2. y coordinate of the touch or tracked drag
   
3. software touch controller object
   
   

Un-touch is detectable by x and y being undefined and by !t.t - !touchController.touching;

UI module evt() iterates through all registered UI elements to find the one that 'owns' the touching spot and act on it.

Lines 16,20,24,28,... begin with a definition of a ui element.

For each element type the UI module has a method for creation, registration, visualisation, and callback invocation.

For creation 8 required parameters are passed (parameters 9 and following are optional for labeling (and other purposes)).

1. UI element is active/enabled (1) or disabled(0)
   
2. x coordinate of the top left corner (...indent)
   
3. y coordinate of the top left corner (...r0w)
   
4. width of the element
   
5. height of the element for buttons and initial check status for checkbox (0/1=un/checked).
   
6. border color 0..9 (-1 means no border color specified and none drawn)
   
7. fill color 0..9 (-1 means no fill color specified and none drawn/filled)
   
8. callback function to talk to the application (on un-touch / release)
   
9. vector font for the label (if absent, undefined, null, false,...no label is crated.
   
10. text / label font color 0..9
    
11. x offset for text / label from top-left corner of ui element
    
12. y offset for text / label from top-left corner of ui element
    
13. text / label as string.
    
    

9/2016: For updated and complemented, higly modularized and extensible version with slider, input field, keypad, radio button, check box, and button ui elements see Modular and extensible UI framework and ui elements conversation (sneak peek pic attached).

Something like attached module code I intend to use with my display with resistive touch screen. So far it support Buttons and Chechboxes w/ and w/o borders and w/ and w/o labels.

The touch controller is a software controller running on Espruino as well. The module code is described in post Resistive Touchscreen directly (no touch controller) at http://forum.espruino.com/comments/11918­647/. Espruino touch screen moudule ADS7843 for same named hardware controller can be used as well.

Next UI elements in mind are: Slider, Spinner, and kind of Input and Output Field.

A screenshot and file with ready to run (inline module and example) code is attached. Narrow forum formatting not suitable for longer code lines, therefore click the link to get the code.

The example UI includes as ui elements 6 buttons and 2 checkboxes. Half of the buttons have a text label. Each element has its own callback. They create following console output:

1v70 Copyright 2014 G.Williams
>echo(0);
=undefined
chk2 0
btn1
chk1 1
btn2
btn3
btn5
chk2 1
> 

Each element shows its name (hardcoded in the dedicated callback). The chckboxes show their status:

• 0 - unchecked
  
• 1 - checked
  
  

The callback are called on un-touch when received focus before. Touching or dragging into an element's display real estate gives focus to the element. Touching and dragging out of an element and dragging 'through' (in and out in) and then un-touching does not trigger callbacks.

Below module code I intend to use for my resistive touch screen. It is a much lighter version of what you have seen from me so far. It is inspired by @Gordon 's ADS7843 touch controller module AND is - of course - 100% callback backward-compatible. Planned name for the module is TOUCHR - R for resistive.

The module includes the defaults configuration for any ILI9341 controlled 320x240 262K Color TFT LCD with resistive touch screen (used in 65K color mode). Any of the default LCD and touch screen parameters can be overwritten on connect() to use it with other displays and touch screen, and to manage variations between same touch screens.

Power consumption is optimized and can be lowered even more for touch tracking by setting the scan interval i at connect time or afterwards, even dynamically in callback depending tracking needs identified on particular touch.

// TOUCHRsimple_inline.js

// Module for connecting resistive touch screen (passive X- X+ Y- Y+)

// var touchr = require("TOUCHR").connect(C0,C1,C2,C3,fu­nction(x,y,tr){
//   if (tr.t) { console.log(x,y); } else { console.log("up"); }
//  }).listen(true);
//
// // probe xy when NOT listening - touch.listen(false);
// if (touchr.xy().t) console.log(touchr.x,touchr.y);

// connect(X- C0,X+ C1,Y- C2,Y+ C3,callback(x,y,touchr),C{onfig}  
// listen(boolean): start/stop
// xy(optCallback): read xy (ONLY when NOT listening)
// ...all returning touchr

// Config (for overriding adafruit's 2.8" 320x240 res touch LCD TFT):
// X: horizontal px #
// Y: vertical px #
// xt: x touch threshold #
// yt: y touch threshold #
// xc: x center value #
// yc: y center value #
// xd: x delta per px #
// yd: y delta per px #
// xr: x read (raw) # 0
// yr: y read (raw) # 0
// x: x touching # 0..X-1
// y: y douching # 0..Y-1
// t: touching boolean (null = ambiguous)
// i: track intervall [ms]
// l: listening boolean 
// w: watch id

var touchrModule = { connect: function(xn,xp,yn,yp,callback,C) {
var tr =  
{ X: 240
, Y: 320
, xt: 0.08
, yt: 0.05
, xc: 0.4960
, yc: 0.4795
, xd: 0.00318
, yd: 0.00251
, xr: 0
, yr: 0
, x: 0
, y: 0
, t: false
, i: 100
, l: true
, w: false
, cb: callback
};
if (C) { for (var v in C) tr[v] = C[v]; }
tr.xy = function(cb,l) {
  pinMode(yn,"input_pulldown");
  digitalRead(yp);
  digitalWrite([xn,xp],2);
  tr.xr = (analogRead(yn)+analogRead(yn))/2;   
  pinMode(xn,"input_pulldown");
  digitalRead(xp);
  digitalWrite([yn,yp],2);
  tr.yr = (analogRead(xn)+analogRead(xn))/2;
  digitalRead([yn,yp]); tr.t = null;
  if (tr.xr>tr.xt && tr.yr>tr.yt) { tr.t = true;
    tr.x = ((tr.x = Math.round(tr.X/2+(tr.xr-tr.xc)/tr.xd)-1­) 
      <0) ? 0 : (tr.x<tr.X) ? tr.x : tr.X-1;
    tr.y = ((tr.y = Math.round(tr.Y/2+(tr.yr-tr.yc)/tr.yd)-1­) 
      <0) ? 0 : (tr.y<tr.Y) ? tr.y : tr.Y-1;
    if (cb) { cb(tr.x,tr.y,tr); }
  } else if (tr.xr<tr.xt && tr.yr<tr.yt) { tr.t = false;
    if (cb) { cb(undefined,undefined,tr); }
  } if (!l && cb) { cb(undefined,undefined,tr); }
  return tr;
};
tr.track = function() {
  tr.w = null; pinMode(xn); tr.xy(tr.cb,true); 
  if (tr.t === false) { tr.listen(tr.l);
  } else { setTimeout(function(){ tr.track(); },tr.i); }
};
tr.listen = function(b) {
  tr.l = b; if (b && !tr.w) {
    pinMode(xn,"input_pulldown");
    digitalRead(xp);
    digitalWrite([yn,yp],3);
    tr.w = setWatch(tr.track,xp,{edge:rising, repeat:false});
  } else {
    if (tr.w) { clearWatch(tr.w); tr.w = null; }
  } return tr;
};
return tr;
}
};

The sample test code

var touchr = touchrModule.connect(C0,C1,C2,C3,functio­n(x,y,tr) {
  console.log((tr.t) ? "down" : "up  ",x,y,tr.xr,tr.yr);
 }).listen(true);

shows the console output below on touching top-left, top-right, bottom-right, and bottom-left corner and the center of the LCD area. On touching, it shows the calculated x and y coordinates and the raw rx and ry values read by the ADC pins. On up (just once after touching) just the raw values read by the DC pin are shown. The touch thresholds (xt, yt) for detecting an un-touch are between the lowest read touch value and the up (un-touch) value and are different for x and y axis. Touches are detected by a hardware event caught by setWatch().

 1v70 Copyright 2014 G.Williams
>echo(0);
=undefined
down 0 3 0.11865415426 0.08740367742
down 0 3 0.11609063859 0.08813611047
up   undefined undefined 0.04345769436 0.02355992980
down 231 6 0.85181963836 0.09472800793
up   undefined undefined 0.03808651865 0.02075226977
down 232 312 0.85621423666 0.86243991760
down 233 311 0.85743495841 0.86060883497
down 232 311 0.85584802014 0.86073090714
up   undefined undefined 0.04345769436 0.02490272373
down 5 314 0.13464560921 0.86915388723
down 3 314 0.12610055695 0.86903181506
up   undefined undefined 0.04406805523 0.02331578545
down 119 154 0.49488059815 0.46802471961
up   undefined undefined 0.04321355001 0.02331578545
> 

Because Espruino IS the (software) controller - like the ADS7843 chip in the ADS7843 module - the TOUCHR module returns a (singleton) control object at connect() to provide additional access - control and data. The control object returns itself also in listen() and xy() methods, and is passed to callback as third (3rd) argument. On connect() or connect().listen(true), it is useful to hold on to the control module in a global variable named, for example, touchr:

var touchCallback = ;
var touchr = require("TOUCHR").connect(C0,C1,C2,C3,
  function(x,y,t) {
    // your code using x, y, and t(ouch control object)
   }).listen(true);

Some displays have touch screens mounted that are larger than the active display area. These areas are called porches. Some touch screens show a blank porch and some have printed icons on it, such as a letter, a clock, a calendar, etc., to mark function buttons. The porch can be used as input but. The touch screen at hand has a bottom porch of about 30px. To use the porch, the controllers Y and yc touch screen parms have to be adjusted:

var ph = 30; // bottom porch height in px
touchr.X += ph; // increase y detection cut toff / limit by bottom porch height
touchr.xc += touchr.xd * ph / 2; // incr. y center touch value by 1 px value times half porch height

Adjustment can be done anytime after connecting. Remember though to consider the extra y range in the callback as well and do not use it for mapping to pixel position of the display:

var touchCallback = function(x,y,t) {
  if (t) { // touching, x and y are defined
    if (y < 320) { // touching in display area
       // display code
    } else { // touching in porch area
      // porch code
   }
 }
};

Below code is the classic drawing 'application':

• Tapping a color in the menu at the bottom picks it up for drawing.
  
• Tapping +/- increases/decreases brush size; brush size shown in black cotouchlor selection.
  
• Tapping the X clears the screen for a new drawing.
  
  

Notice the shortened tracking interval time passed on on connect (line 42). Colors of attached screen shot are 'a bit' off... angle and exposure and ambient light matter messed with capturing.

var touchr;
SPI1.setup({sck:B3, miso:B4, mosi:B5, baud: 1000000});
var lcd = require("ILI9341").connect(SPI1, B6, B8, B7, function() {
  lcd.clear();
  var n=2,w=20,rgb=[0,0,0];cs=[];x=-w,ym1=300,­ym2=319;
  (function(){
    cs.push(rgb.slice(0)); 
   lcd.setColor(rgb[0],rgb[1],rgb[2]);
    x += w;
    lcd.fillRect(x,ym1,x+w-1,ym2);
    for (var r=0;r<n;r++) {     rgb[0] = 1 / (r + 1);
      for (var g=0;g<n;g++) {   rgb[1] = 1 / (g + 1);
        for (var b=0;b<n;b++) { rgb[2] = 1 / (b + 1);
          cs.push(rgb.slice(0)); 
          lcd.setColor(rgb[0],rgb[1],rgb[2]);
          x += w;
          lcd.fillRect(x,ym1,x+w-1,ym2);
        }
      }
    }
    lcd.setColor(1,1,1);
    lcd.setFontVector(16);
    x += w; lcd.drawString("+",x+3,ym1+2);
    x += w; lcd.drawString("-",x+3,ym1+2);
    x += w; lcd.drawString("X",x+3,ym1+3);
    lcd.drawLine(0,ym1,239,ym1);
   })();
  var rad = 2, ymd = ym1 - rad - 1, cxm=cs.length-1,cdx = 0,ym;
  lcd.setColor(0,0,0); lcd.fillRect(0,ym1+1,w-1,ym2);
  lcd.setColor(1,1,1); lcd.setFontVector(10); 
  lcd.drawString(rad * 2 + 1,0,ym1+5);
  rgb = cs[0]; lcd.setColor(rgb[0],rgb[1],rgb[2]);
  touchr = touchrModule.connect(C0,C1,C2,C3,functio­n(x,y,tr){
    if (tr.t) {
      if (y < ym1) {
        ym = (y < ymd) ? y : ymd;
        lcd.fillRect(x-rad,ym-rad,x+rad,ym+rad);­
      } else if (y >= ym1) {
        cdx = Math.floor(x / w);
        if (cdx <= cxm) {
          rgb = cs[cdx];
          lcd.setColor(rgb[0],rgb[1],rgb[2]);
        }
      }
    } else {
      if (tr.y >= ym1) {
        cdx = Math.floor(tr.x / w);
        if (cdx > cxm) {
         if (cdx <= cxm + 2) {
            rad = Math.round(rad + ((cdx == cxm + 1) 
                        ? (rad / 2) : (0 - rad / 3)));
            rad = (rad < 2) ? 2 : (rad <= 42) ? rad : 42; 
            ymd = ym1 - rad - 1;
            lcd.setColor(0,0,0); lcd.fillRect(0,ym1+1,w-1,ym2);
            lcd.setColor(1,1,1); lcd.setFontVector(10);
            lcd.drawString(rad * 2 + 1,0,ym1+5);
            lcd.setColor(rgb[0],rgb[1],rgb[2]);
          } else {
            rgb = cs[0]; lcd.setColor(rgb[0],rgb[1],rgb[2]);
            lcd.fillRect(0,0,239,ym1 - 1);
          }
        }
      }
    }
   },{i:20}).listen(true); // track every 50 [ms] = 20Hz = 20 times/s
 });

A calibration module for TOUCHR module will be presented in a separate post. It will help you to set or adjust the touch screen parms xt, yt, xc, yc, xd, and yd for your (same or different LCD w/) resistive touch screen (...c stands for expected value at the center, ...d for the difference between pixel. In a nutshell, the calibration module uses the read raw values of touches at known (displayed px) x / y locations to calculate the touch screen parms.

The above provided simple test code can be used to manually gather the raw values and do the calculations. Set pixels at defined x / y coordinates equally close to the corners (about 10 px away from the borders) and one in the center, touch them, and perform the calculations. Simple average and linear formulae are accurate enough:

• xd = avrg of delta x raw touch values divided by delta x pixels
  
• yd = avrg of delta y raw touch values divided by delta y pixels
  
• xc = avrg of (sums of low and high x / 2) and center x values
  
• yc = avrg of (sums of low and high y / 2) and center y values
  
• xt = between avrg of x off and avrg of lowest x touch values
  
• yt = between avrg of y off and avrg of lowest y touch values
  

You use them for the same purpose: not have open, floating inputs, (too) sensible to noise (on inputs driven by open-collector(-like) outputs of driving ICs - which all I2C senders are, or on inputs driven by (diode-)matrix-encoders (like in keypad) on scanning). I used pull-downs to clear lingering capacities before reading from resistive touch screen - see http://forum.espruino.com/conversations/­256122/, in particular post http://forum.espruino.com/comments/11892­295/

For use with I2C: first of all, these pull-up (or pull-down) resistors are 30..40k. If you write you own I2C you can control the pins to use them (when reading). With low speed and short bus and limited noise it may work (see @DrAzzy 's explanations in 3rd and 2nd last paragraph).

Regarding the pull-up (or pull-downs) are used to eliminate noise on the line when the line is not pulled either down or up by any of the devices on the bus. Noise may - and most likely will - reach levels that unintentionally trigger listening inputs when not taken care of. Good info to find at: http://i2c.info or http://www.i2c-bus.org/.

After Manual switching to I2C mode, connect it as described in posts http://www.espruino.com/MPL115A2 and http://www.espruino.com/MCP4xxx.

The posts suggests 4.7K..10K. The lower the resistance, the more the device has to drive, the better the noise immunity, and the higher the power consumption. Both Espruino and atlas-scientific are both able to drive 4.7K, so go for it.

@Espruino_user_dk, if the values for Z1 and Z2 cannot made that high that for practical reasons the drain can be ignored, a dynamic measurement could help if the circuitry for that does drain less ant to the point of where the drain can be ignored... What about an 'overkill' with the theoretical circuitry below?

The basic idea is to charge a very low leakage capacitor and then measure it's discharge (or charge behavior).

With fast D1 and D2 and R3..R6 properly sized, the B2 and C0 processor pins are safe (on power on and beyond). With both pins open, (mainly) R4 and R5 will charge C1 to the point where Vb - Vt = VBatt. Now only the 'leakage of' C1 and T1 keep draining. (If no reasonable sizing for R1..R5 can be found to avoid T12 from switching on during C1 charging process, adding a D in between R3 and Vt point of C1 has to be added.)

For measuring, Pin B2 is switched to on - B2.set() - which switches T1 on. T1 on pulls Vb to ground and pushes Vt to negative (-VBatt). R3, R5, and R6 (via D2 up to a certain point) will pull Vt up to about what R3 and R5 voltage divider on B2(High) defines, say (theoretical) Vm. In other words, C1 is discharged and re-charge in reverse polarity.

The times for Vt to reach GND and then a particular percentage of (theoretical max) Vm correlate to VBatt (after being pushed to negative by pulling down Vb) correlate with VBatt. It would be quite interesting to see on an a scope what Vb, Vt, Vm, and Pin B2 do...

Behavior of Vb and Vt (and Vm) after measuring should not pose any problems (C0 would go on open input and after that B2. Latter switches T1 off. Since Vb is negative vs Vb, C1 is discharged and then re-charged with re-reverse polarity... - worst case - Batt empty and low impedance (low inner R), another D between GND and Vt point of C is needed, but would have also have an effect on measurement).

As said, this is all theoretical... and I have not much clue how to size the Rs and C, and figuring out the formula to map time to voltage is a totally different ball game. So I'm interested in anything that can say at first sight: It cannot work. ;-)

Not JIT but with XCompile - so: on the pseudo-fly.

As @Gordon pointed out in various posts, there is not enough memory to do JIT things of that magnitude - and speed would loose out for sure (that's why Espruino has its own unique engine, and not, for example Rhino, or V8,...). That approach also allows to just pick and choose what fits and makes sense, and grow over time gradually to full functionality - full meaning: everything that is very useful for the very platform at hand. It would though be possible to xcompile beforehand (in the Web IDE) and combine it with advanced minification. On the other hand, any of that kind technology makes it more difficult to exploit dedicatedly what a JS platform on a microchip has to offer. CoffeScript creates much more compact source code. In order to keep that going forward, the xcompiler needs to be aware of how the target JavaScript achieves similar effects, including minification. For simple constructs as found in CoffeScript's introduction, mapping looks trivial, and related overhead is predictable. What about nested closures? There is only that much of abstraction layering one can put on top of the core API before loosing touch with reality - that API. - 'It is just JavaScript' is easier understood than implemented.

Experience the very same issue with reading values from resistive touch screen. The internal pull-up/down resistors are about 30..40K which may need to be considered when measuring - because they can pose 'significant load' on the measured 'object' - depending on circuitry. In my case, I could not detect the 'OFF' state reliably... continuous reading/sampling without pull-up/down even triggered subsequent setWatch() on the open pin - something did not expect. The solution is to pull down - and if the the 30..40K are a significant factor - switch to open input before reading (see http://forum.espruino.com/comments/11892­295/). It is anyway a good thing to have the input as much open as possible to not waste any power. On the other hand to avoid floating, you may consider to pull down externally with a resistor of much higher value - 470K...1M and keep it... (value all depends on your circuitry). In my case it did not really matter 30..40K vs 300..400 Ohms, and left it pulled down.