Search results for:

@idobh2, really NICE work!

Code for tester:

The code uses a hybrid of declarative and procedural approach to perform the test. It uses the truth table to define a test 'matrix'. Each row defines the the inputs and encoded the expected output. The inputs to the IC to test are arranged/ encoded suitable to write to Espruino Pico pins by an array. Functions the use this data, apply the inputs as outputs, and do some additional iteration or variation of values. The results get written to the console. An output example is attached. Enhancements would be to power the IC and run the test on BTN1 press.

Note the 'renaming' of the pico pins to drive the IC: the Pico 'are named' for the Chip to test - C w/ chip's pin function Name - to make it obvious what is going on in the code.

// MC41512_8CH_SEL.js
// 20230311ao
//
// Using pico to test NOS MC41512B 8-Channel Data Selector
//

var lon = true; // false; // true; // logging is on
function log() { if (lon) { console.log.apply(console,arguments); } }

// wire connections
//  ic - pico
var CX0=A0, CX1=A1, CX2=A2, CX3=A3, CX4=A4, CX5=A5, CX6=A6, CX7=A7
  , CDIS=B1, CINH=B10
  , CSA=B13, CSB=B14, CSC=B15
  , CZ=A10 
  , CX = [CX7, CX6, CX5, CX4, CX3, CX2, CX1, CX0]
  , CS = [CSC, CSB, CSA]
  , CC = [CINH, CDIS]
  ;

function setPinModes() {
  // driving the chip controls
  pinMode(CINH,"output");
  pinMode(CDIS,"output");
  // driving the channel address lines
  pinMode(CSA,"output");
  pinMode(CSB,"output");
  pinMode(CSC,"output");
  // driving the 8 channel inputs
  pinMode(CX0,"output");
  pinMode(CX1,"output");
  pinMode(CX2,"output");
  pinMode(CX3,"output");
  pinMode(CX4,"output");
  pinMode(CX5,"output");
  pinMode(CX6,"output");
  pinMode(CX7,"output");
  // reading the chip output (preset)
  pinMode(CZ,"input");
}

// truth table (MSNib = channel #, LSNib = INH,DIS)
var tt = 
[[0x00,  1] // X0 - channels 0..7, inputs
,[0x10,  2]
,[0x20,  4]
,[0x30,  8]
,[0x40, 16]
,[0x50, 32]
,[0x60, 64]
,[0x70,128] // X7
,[0x02,  0] // 0 - inhibit
,[0x01, -1] // high imp - disable
,[0x03, -1] // high imp - disable
]
;

function hex(v) { return ((v>15) ?
  hex(v>>4) : "")+"0123456789ABCDEF".charAt(v&15); } // hex...
function hep(v,ds) { // hex, digits (w/ padding up to ds)
  return ("        "+hex(v)).substr(-ds); }
function tvSplit(tv) { // split 
  return([tv[0]>>4, tv[0]&3, tv[1]]); }

var tMax = 3 // test repetitions
  , tCnt = 0
  , passed, somePassed, someFailed
  ;

var tester =
{ test: function() { // tester object (tool)
    log(++tCnt);
    for (var i=0; i<tt.length; i++) {
//    log("["+hex(i)+"]");
      if (i<8) {         // --- channel X0..X7
        this.channel.apply(this,tvSplit(tt[i]));­
      } else if (i==8) { // --- 0 - inhibit
        this.inhibit.apply(this,tvSplit(tt[i]));­
      } else {           // --- high imp - disable ...
        this.disable.apply(this,tvSplit(tt[i]));­  // w/ inhibit 0|1
      }
    }
  }

// test channel w/ channel select s, control, value
, channel: function(s,c,v) {
    digitalWrite(CC,c);
    digitalWrite(CS,s);
    log("channel",hex(s),this.chkChan(1,v));­ 
    log("channel",hex(s),this.chkChan(0,v));­ 
  }
    
, chkChan: function(b,v) {
    var va = ((b)?v:v^255)&255, n, p;
    digitalWrite(CX,va);
    pinMode(CZ, (b) ? "input_pulldown" : "input_pullup");
    n = digitalRead(CZ);
    passed &= (p = (n === b));
    return ((b)?"H ":"L ")+n+" "+hep(va,2)
      + ((p) ? " ok" : " FAILED");
  }

// test inhibit on INH, (-DIS)
, inhibit: function(s,c,v) {
    digitalWrite(CC,c);
    digitalWrite(CX,255);
    pinMode(CZ,"input_pullup");
    var p = true;
    for (var j=0;j<8;j++) {
      if (digitalRead(CZ)) {
        log("inhibit FAILED on channel ",j);
        p = false;
      }
    } if (p) log("inhibit ok");
    passed &= p;
  }

// test disable on DIS
, disable: function(s,c,v) {
    digitalWrite(CC,c);
    this.chkDis(c,255,0);
    this.chkDis(c,255,1);
    this.chkDis(c,  0,0);
    this.chkDis(c,  0,1);
  }

, chkDis: function(c,v,r) {
    digitalWrite(CX,v);
    pinMode(CZ,(r)?"input_pullup":"input_pul­ldown");
    var p = true;
    for (var j=0;j<8;j++) {
      if (r !== digitalRead(CZ)) {
        log("disable w/ inhibit=",(c>>1)," val=",hep(v,2)
           ," FAILED on channel ",j);
        p = false;
      }
    } if (p) {
      log("disable w/ inhibit=",(c>>1)," val=",hep(v,2)," ok");
    }
    passed &= p;
  }

}
;


function onInit() {
  setPinModes();
  somePassed = false; someFailed = false;
  var tIId = setInterval(function() {
       LED1.reset(); LED2.reset();
       passed = true;
       tester.test();
       if (passed) {
         LED2.set(); somePassed = true;
       } else {
         LED1.set(); someFailed = true;
       }
       if (tCnt>=tMax) {
         clearInterval(tIId);
         if (somePassed) { LED2.set(); }
         if (someFailed) { LED1.set(); }
       }
    },750);
}


setTimeout(onInit,999); // dev only; remove before upload for save()

Output:

>
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v17 (c) 2021 G.Williams
>
1
channel 0 H 1  1 ok
channel 0 L 0 FE ok
channel 1 H 1  2 ok
channel 1 L 0 FD ok
channel 2 H 1  4 ok
channel 2 L 0 FB ok
channel 3 H 1  8 ok
channel 3 L 0 F7 ok
channel 4 H 1 10 ok
channel 4 L 0 EF ok
channel 5 H 1 20 ok
channel 5 L 0 DF ok
channel 6 H 1 40 ok
channel 6 L 0 BF ok
channel 7 H 1 80 ok
channel 7 L 0 7F 
inhibit ok
disable w/ inhibit= 0  val= FF  ok
disable w/ inhibit= 0  val= FF  ok
disable w/ inhibit= 0  val=  0  ok
disable w/ inhibit= 0  val=  0  ok
disable w/ inhibit= 1  val= FF  ok
disable w/ inhibit= 1  val= FF  ok
disable w/ inhibit= 1  val=  0  ok
disable w/ inhibit= 1  val=  0  ok
> 
2
channel 0 H 1  1 ok
channel 0 L 0 FE ok
channel 1 H 1  2 ok
.....
...
.

I got some new old stock (NOS) ICs, and before I used them and get puzzled why my circuitry does not behave as expected, I wanted to test them. It's a functional test, no timing test. Test is repeated as many times as specified. If at the end only the green LED (LED2) is on, then all tests were successful. If red LED (LED1) is on, then at least one test failed. If only the red LED is on, then all tests failed.

The example here is the Motorola CMOS MC14512B - 8 Channel Data Selector.

For details about the IC and the wiring see attached pictures. Codes and console output in second post.

In a UI context, the long press vs short kick usually initiates an alternate function or a menu to select from a host of alternate functions. It became necessity when - because of Apple (2) - lost the second eye to end up as a single eyed minion. Initially, the mouse started out with 3...

Next issue with touch vs mouse is the loss of continuous 'contact' of the pointing device indicator - and with that the mouse pointer had to go away. Luckily touch w/ move - drag - is introduced.

Back to the long press: this could actually really increase robustness of changing settings. I experience the setting of, for example, elements of time very finicky... may be I do it wrong, but a long press on the item with a pop up that has plenty real estate to have easy usable up/down, cancel/ok controls.

Sometimes the direct control is not worth the trouble it creates, or in other words, and extra touch at the begin and end of an operation is worth to pay to have a robust working operation. This is especially true in the fight of a fat finger on a super tiny and moving touch screen.

@Fteacher, I like your comment

I'm restarting the creative (but so tedious for beginners) process of coding.

a lot, especially this part: ...so tedious for beginners

I can tell you that without Espruino / @Gordon's platform, you would not even find a word in the whole universe to describe it...

just saying.

Enjoy the creative writing process... Espruino likes to read your stories and follow them to the tee... so watch what you are asking it for!

Use an C routine to extract into a transmit buffer... this is fast and lets you use the the Graphics class for Espruino style drawing and push out the buffer as is. Claiming contiguous memory should not be an issue... (see use of C in Efficiently moving things around in zig-zag Graphics buffer visualized w/ 24/32 bpp displays / neopixel strings. Using this technology you can trigger the update of the display anytime and it can run to its own beat. Used that technology in the same application context: drawing/writing to the Graphics object is event driven and updating the display/reading the Graphics object is event driven. Update you can trigger by time or at application flow specific points where you know that updating the display makes sense. I'm not sure if you use partial update... which I know was tried and shared in the forum, but I cannot recall final conclusions (your fourth color could be used for that - using a bit pattern for the white, red and black colors that share a bit - to determine what zone to update and clear it on update).

Having the drawing and updating the display separated allows optimizing of automated update and at the same time on demand update as the application can control it (fire an event and move on, and update requests can be queued and skipped to do the least number of). Separation also makes it easy to exchange the displays type.

If you are short on memory, doing it inplace? Not sure what you win, because transformation would have to happend before AND after transmission to display.

@MaBe is one of the forum members who has extensive experience w/ 3-color ePaper displays. I'm sure he has his ideas too.

Static discharges could be an issue... capacitors can help, worst case you have to add 'transient arrestors'... but from your setup I would expect that nothing ever can touch the blank wires of your thermistor.

Sinc you do not show any code, it is difficult to make some comments about why a puck would completely crach. I could think of some issue in setTimout() / setInterVal() usage that could lead to buffer overruns. But that is a wild guess...

Hi, skimmed over your code... noticed several things... some are coding conventions which do not break the code but make it more difficult to build a mind map - map the code in the mind for grasping. Beside that, I noticed your Polygon = [] and its population w/ values for drawing. I could not figure how many points you add, but you have to be aware of the limit it has. Your may have too many points. Not all all drawn which could explain the missing parts. To get thru a polygon with too many values, you have to break it up into multiples to compose the final one. See Swiss Federal Railway Clock modeled w/ Circular Gauges. It's less about the clock, it is about the circular gauges: I use some algorithm to compose a partial circle (arc) drawn using polygons by actually drawing multiple segments of that partial circle (arc)... (the full circle is just a partial circle / arc of 360 degrees).

Addendum: see g.drawPoly/fillPoly have a limit of 64 nodes - Your Color wheel.js uses 72 segments... which puts you already 12+% beyond the max limit. To achieve that: think about drawing two circles using Espruino's Graphics method .drawCircle(): draw the outer circle, and then clear the inner portion with another one... That way you take advantage of the best resolution with the highest speed.

@Ganblejs, I guess you mean lines #274..278 and #303...

If you establish some pattern beforehand, you can pick by algorithm or random and push out as @Gordon sugget. When you want to move things around within chosen pattern or splice things together, you can use algorithms written in C, as I did in Efficiently moving things around in zig-zag Graphics buffer visualized w/ 24/32 bpp displays / neopixel strings. The referenced example uses the graphics buffer that is suppoted with graphics functions. The graphics functions are used to write to the buffer, and an intervalled process writes it out to the LED string(s). The arrangement of your LEDs are like the surface of a cylinder which is just lime a bent dot matrix screen on which you can draw things on.

Searched for this... did not found it until later, after I created a duplicate of this issue...

Puck.js FW 2v16 not recognizing HW V1 magnetometer MAG3110, thinks it's Puck Lite 1 HW

...fun!

(tested 2v00, 2v06 (was on before update), 2v11, 1v14: all okl from 2v15 on it's broken; using 1v14 until 2v17 will be out)

Oops...

...found duplicate at Puck.js v1 on 2V16 - magnetometer not recognised...

Search is really not working in forum, and googling was not of much more helpful...

(using 1v14 until 2v17 will be out)

I updated a Kickstarter Puck.js w/ most recent FW 2v16 using online Web IDE. Running the default code

Puck.magOn();
Puck.on('mag', function(xyz) {
  console.log(xyz);
});
// Turn events off with Puck.magOff();

complained in the console:

>
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v16 (c) 2021 G.Williams
>
Uncaught Error: Magnetometer not available on Puck.js Lite 1
 at line 1 col 12
Puck.magOn();
           ^
> 

(Definitively not a battery level issue...)

After installing from url 2v00 - the oldest listed on the site for previous versions http://www.espruino.com/Download - above code works.

 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v00 (c) 2018 G.Williams
>
{ "x": -3341, "y": 3017, "z": 1275 }
{ "x": -3393, "y": 3067, "z": 1298 }
{ "x": -3398, "y": 3064, "z": 1299 }
{ "x": -3397, "y": 3067, "z": 1294 }

2 questions:

1. What is the newest verson that still recognizes the MAG3110 on my Kickstarter Puck.js V1? (*
   
2. What can I do to make 2v16 recognize the MAG3110 on my Kickstarter Puck.js V1?
   
   

*) Looks like 2V14 is last one that works... (worked thru 2v06, was on before update, then 2v11, then 2v14: all ok; 2v15 shows same issue as 2v16).

Merry Christmas to you, Gordon!

Second ...amazing how far we've come with Espruino... - not doing much Espruino lately, but just pulled one of my pucks from kickstarter - V1, indeed - and flashed rom 2v06 to 2v16: smooth and uneventful using the IDE from Web. It can't get easier(*). This tells a lot. Not only Bangle has matured: Whole Espruino Ecosystem is a joy to play (work) with.

Enjoy your time off, @Gordon; I'll look down on you tomorrow! Taking a break as well and Christmas w/ Family after years.

• ao
  
  

(*)Getting the Coin Cell out is now the most difficult thing! - Haha....

Using @fanoush 's code imbedded in your app, the convenience singleton object for handling all RSSI stuff could look like the code below. Working thru the example you will notice that Espruino / JavaScript is completely event driven... and you can take advantage of that even in application components you write. No need to burn cycles like famous (NOP) wait loops do... ;)

NB: Things - such as NRF.setRSSIHandler() setting method - not available in your environment - emulator or html doc in browser? ...just fake/emulate it 'intelligently' - see lines 59..71 to get meaningful values for (cross) developing and test your logic... Same goes for the missing on() and emit() for plain browser js objects - see lines 72..77. With these 'complements', the very same Espruino code runs in html5 document in browser. The html document is attached to the post, just click on its link... ;) --- *click on the second attached html / link* - first one has issues and I could not delete it because forum has issues on edit with loading... / deleting of attachments). HTML code is shown below the Espruino code.

// for logging convenience
var lon=0, log=function(){console.log.apply(console­,arguments);};

// rssis singleton object handling all RSSI matters encapsulated
var rssis =
  { history:   [] // [date,value] tuples of samples
  , maxHist:   10 // max count averaged samples in history
  , intTime: 5000 // ms interval time of sampling
  , samples:    5 // count of raw samples for for averaged sample
  , _intId:     0 // interval id for start/stop control
  , _cnt:       0 // for sampling control
  , _sample: function() { // --- takes samples and stores in history
      var sum = 0
        , cnt = this.samples
        , avrg, hEntry;
      NRF.setRSSIHandler((data)=>{
          lon&&log("C:",data,this._cnt);
          sum+=data;
          if (--cnt<1) {
            NRF.setRSSIHandler();
            hEntry = [new Date(), avrg = sum/this.samples];
            this.history.splice(0, 0, hEntry);
            if (this.history.length>this.maxHist) this.history.pop();
            this.emit('data', avrg, hEntry, data, this);
          }
      } );
  }
  , start: function(clearHistory,_rs) {  // --- opt clear history and take samples
      lon&&log("rssis.start",((_rs)?_rs:""), "clearHistory:", !!clearHistory);
      if (this._intId) { this.stop(); }
      if (clearHistory) { this.history = []; }
      this._intId = setInterval(this._sample.bind(this), this.intTime);
      return this.history.length;
    }
  , isSampling: function() {  // --- true when sampling, otherwise false
      return !!this._intId;
    }
  , getHistoryCnt: function() {   // --- number of history entries
      return this.history.length;
    }
  , stop: function() {        // --- stop taking samples
      lon&&log("rssis.stop");
      if (this._intId) { 
        NRF.setRSSIHandler(); // stops data handler in its tracks
        this._intId = clearInterval(this._intId); // stops sampling
      }
      return this.history.length;
    }
  , resume: function() {      // --- resume w/ not clearing history
      return this.start(0,"(resume)");
    }
  , dump: function(asHTML) { // --- return history as lines / html w/ <br>
      var x=-1,l=this.history.length,h,lines=[];
      while(++x<l){h=this.history[x];lines.pus­h(h[0].toString()+": "+h[1]);}
      lines.push(l); return (asHTML) ? lines.join("<br>")+"<br>" : lines;
    }
  };

// to run in emulator or html5 doc in browser have this in place (roughly):
var nrfDataEmulatorIntId=0; if (typeof NRF === 'undefined') { var NRF = {}; }
NRF.setRSSIHandler = function(dataHandler) { // every 7 ms an emulated value
  if        (dataHandler && ! nrfDataEmulatorIntId) { lon&&log("P:start");
    nrfDataEmulatorIntId = setInterval((dataHandler)=>{
        var emulatedVal = Math.round((new Date().getTime() % 100) / 10) - 90;
        lon&&log("P:", emulatedVal);
        dataHandler(emulatedVal);
      },13,dataHandler);
  } else if (! dataHandler && nrfDataEmulatorIntId) { lon&&log("P:stop");
    nrfDataEmulatorIntId = clearInterval(nrfDataEmulatorIntId);
  }
};
if (typeof window !== 'undefined'){ lon&&log("in browser js/win"); // for html5 doc
  let addOnAndEmitTo=function(o,n){ lon&&log("add simple on/emit to "+n);o._eOE={}; 
    o.on=function(e,h){this._eOE[e]=h;};o.em­it=function(){var p=[],i,a=arguments,m,
    u; if(m=this._eOE[a[0]]){for(i=1;i<a.length­;i++)p.push(a[i]); m.apply(u,p);}}};
  if ( ! rssis.on) { addOnAndEmitTo(rssis,"rssis"); }
}

// catching rssis 'data'-event
rssis.on("data",(avrg, historyItem, rawSample, rssisObj)=>{
  lon&&log("rssis 'data' event: ", avrg, historyItem, rawSample, rssisObj.getHistoryCnt());
});

// for dev acceleration 
function onInit() {
  rssis.start();
}

// for dev acceleration
setTimeout(onInit,999); // remove before upload for/with save()

HTML document running the same Espruino code:

<html>
<head><title>RSSIs</title></head><body>
<h3>RSSIs</h3>
<p>Open inspector in develop tools and watch console...</p>
<ul>
<li><a href="#" onclick="rssis.start();" >start</a></li>
<li><a href="#" onclick="rssis.start(1);">start with clearing history</a></li>
<li><a href="#" onclick="rssis.stop();"  >stop</a></li>
<li><a href="#" onclick="rssis.resume();">resume</a></li­>
<li><a href="#" onclick="ao.h('dmp',rssis.dump(1)+ao.e('­dmp').innerHTML);";>dump</li>
</ul>
<hr><a href="#" onclick="ao.h('dmp','');">clear</a><pre id="dmp"></pre>
<!--survival html5 --><script> var ao = { d: document
, e: function(ioe) { return ("string"===typeof ioe) ? this.d.getElementById(ioe) : ioe; }
, h: function(ioe,h) { var e = this.e(ioe); return e.innerHTML = h; return e; } }</script>
<!-- rssis js from Espruino --> <script>

// ... ... ... ... Espruino js code from above copied in here... ... ... ... 

</script>
</body>
</html>

The rssis singleton supports these 'methods' and other:

• For start taking samples and store them in history, issue rssis.start();
  
• To stop taking samples, issue: rssis.start();
  
• To dump the history in the console (anytime), issue rssi.dump();
  

• To access last data (any time, from the history):

  var h;
  if (rssis.historyCount>0) {
  h = rssis.history[0];
  console.log("RSSSI at", h[0], ": ", h[1])
  }
  

...or simply:

console.log(rssis.history[0][1]);

The objet even emits 'data' event when adding to the history with these parms (see line #s 24 and 60ff`):

1. most recent averaged sample: avrg
   
2. history entry: [date, avrg]
   
3. most recent raw sample: data
   
4. rssis singleton object
   
   

This event can be listen to in the application in a similar way as rssis is listening to the NRF 'data' event:

// catching rssis 'data'-event
rssis.on("data",(avrg, historyItem, rawSample, rssisObj)=>{
  console.log("rssis 'data' event: ', avrg, historyItem, rawSample, rssisObj.getHistoryCnt());
});

With `lon=0' (logging turned off) you get only outputs like this in the console (most recent average rssi value, most recent history event with date and rssi average, most recent raw rssi sample value, and history count):

rssis 'data' event:  -85 [
  Date: Tue Oct 4 2022 18:34:31 GMT-0700,
  -85 ] -86 1

Setting lon=1 (turns logging on and) you get after uploading and console commands (latter indented) output on console like this:

>
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v15 (c) 2021 G.Williams
>
>
rssis.start  clearHistory: false
P:start
P: -80
C: -80 0
P: -89
C: -89 0
P: -88
C: -88 0
P: -87
C: -87 0
P: -85
C: -85 0
P:stop
rssis 'data' event:  -85.8 [
  Date: Tue Oct 4 2022 22:30:09 GMT-0700,
  -85.8 ] -85 1
----------------------->rssis.dump() // while sampling
=[
  "Tue Oct 4 2022 22:30:09 GMT-0700: -85.8",
  1 ]
P:start
P: -80
C: -80 0
P: -89
C: -89 0
P: -88
C: -88 0
P: -86
C: -86 0
P: -85
C: -85 0
P:stop
rssis 'data' event:  -85.6 [
  Date: Tue Oct 4 2022 22:30:14 GMT-0700,
  -85.6 ] -85 2
P:start
P: -81
C: -81 0
P: -89
C: -89 0
P: -88
C: -88 0
P: -87
C: -87 0
P: -85
C: -85 0
P:stop
rssis 'data' event:  -86 [
  Date: Tue Oct 4 2022 22:30:19 GMT-0700,
  -86 ] -85 3
----------------------->rssis.stop(); // while sampling
rssis.stop
=3
----------------------->rssis.dump(); // while not sampling
=[
  "Tue Oct 4 2022 22:30:19 GMT-0700: -86",
  "Tue Oct 4 2022 22:30:14 GMT-0700: -85.6",
  "Tue Oct 4 2022 22:30:09 GMT-0700: -85.8",
  3 ]
----------------------->rssis.resume(); // while stopped
rssis.start (resume) clearHistory: false
=3
P:start
P: -89
C: -89 0
P: -88
C: -88 0
P: -86
C: -86 0
P: -85
C: -85 0
P: -84
C: -84 0
P:stop
rssis 'data' event:  -86.4 [
  Date: Tue Oct 4 2022 22:31:17 GMT-0700,
  -86.4 ] -84 4
----------------------->rssis.start(1); // while sampling
rssis.start  clearHistory: true
rssis.stop
=0
P:start
P: -85
C: -85 0
P: -84
C: -84 0
P: -83
C: -83 0
P: -82
C: -82 0
P: -80
C: -80 0
P:stop
rssis 'data' event:  -82.8 [
  Date: Tue Oct 4 2022 22:31:27 GMT-0700,
  -82.8 ] -80 1
P:start
P: -86
C: -86 0
P: -85
C: -85 0
P: -84
C: -84 0
P: -82
C: -82 0
P: -80
C: -80 0
P:stop
rssis 'data' event:  -83.4 [
  Date: Tue Oct 4 2022 22:31:32 GMT-0700,
  -83.4 ] -80 2
----------------------->rssis.stop(); // while sampling
rssis.stop
=2
----------------------->rssis.dump(); while stopped
=[
  "Tue Oct 4 2022 22:31:32 GMT-0700: -83.4",
  "Tue Oct 4 2022 22:31:27 GMT-0700: -82.8",
  2 ]
> 

Ic. Thanks for clarification. I think I get it: it is 'just' a SW replacement... nice! Like the Bangle.js watches: taking an existing hardware and software and replace the software. Very interesting. The word 'just' just does not do justice to the work you put in, even peeking at the Arduino implementation / its doc.

Was thinking more along the lines of adding a ref pointer to variables. Of course this is not footprint friendly, but preserves source.

Your replacement approach triggered another thought: in dbs, often a local index is built to save space. In code it would be a symbol index to keep the name / preserve the source but having a space to replace it on first run w/ a pointer into variable value space, that holds the value but would also hold also a pointer back to the index entry / name.

I'm sure you already have though of many things, wandered down alleys... and kept sticking to what Espruino interpreter has come to this day. So no urgency to this.

Speeding up variable lookup (and jump address lookup/'calculations') promise the most. Was there ever a thought to have something (changed) in the source that updates when the variable has been looked up? Of course that works only when the code is in RAM and a in/re-direction table that makes GC transparent? So it is not really a JIT compiler but more so an accelerator that does a lot of good especially in loops - similar to what pre-tokenzing does. An accelerator is not JIT compiler nor main stream, but Espruino isn't either. Such an accelerator would be unique and - after all - fit the uniqueness of Espruino (JS engine).

#jeffmer, Bull's Eye! - That's all I can say...

So: you got yourself such a device, ripped out the Arduino stuff and put in an Espruino w/ your code?

I'm kind of curious to know whether there is still enough space left to have a Morse Code interpreter / decypher DX transmissions on SSB?

...here it is... it is in someone elses conversation New to Bangle.js and Espruino. Need help with graphics... Nov 2020

Hit that limit a while ago... if your algorithm can handle a detection and cut-up in multiple 'touching' polys / segments, it is easy to live with the limitation.

I had build a circular multi dial... and on a certain size with close to 360 degrees and expectation of decent smoothness of the 'bent bar'/bow, you run quickly into the limit. Luckily for me, I calculate max 30 points of a segment, note the angel and finish calculating the rest of the segment, draw it, and move on to the next segment until the desired angle is covered. Somewhere in the (difficult to search) forum you can find the code...

Obviously missed this discussion / voting / weighing in...

Not sure my comment changes much from point of view of liking or not liking github for discussion. These are the cons for the current forum:

• not mainstream
  
• created for discussing non-code things
  
• no integration with a real repository
  
• difficult, limited search
  
• limited image integration
  
• formatting has changed over time making a lot of my older, markup using entries unreadable
  
  

I don't want to leave it at cons - and that may be reason for many to be content with the current forum:

• easy to use for simple posts
  
• file / image integration usually sufficient
  

@Jennygrist, what is the motivation to use a pico vs a puck? Pico has no communication. You would have to add that as a separate device. Just to mention one con.

@Gordon, what about the input controls on active overlay, especially the touch?

My best guess is that callback (on time intervals) overrun happens... Did you ever time the anonymous functions in your intervals?

I see sensor driven events - on(...) - which capture data that you then process in 100 and 250 ms intervals. What are the average intervals of you sensor - GPS and pressure - events?