Search results for:

Thanks @allObjects. Your first example will work for my application, cleaner than my workaround. I've seen this signature before, but haven't needed it for NodeJS, where I do most of my coding these days.
Still, I don't see the value in throwing an error from clearTimeout where undefined could be gracefully returned instead, which doesn't require the user to know to clear the ID in the callback, or think of clearTimeout differently than clearInterval or differently than NodeJs code.
FYI, I think your second example has a couple typos ...

var timeout1 = {}, timeout2 = {};
function timedFunction(timeout) {
  timeout.id = null;
  // ...other code...
};
// ...more code...
timeout1.id = setTimeout(timedFunction, 1000, timeout1);
timeout2.id = setTimeout(timedFunction, 2000, timeout2);
// ...some code...
if (timeout1.id) { timeout1.id = clearTimeout(timeout1.id); }
// ...some code again...
if (timeout2.id) { timeout2.id = clearTimeout(timeout2.id); }

And similarly, I believe you meant line 11 of the last example to reference timeout2.

@Gordon, Tried this with Espruino board 1v4 and Pico running both 1v89 and 1v84 builds, as well as nightly build from @DrAzzy...

Executing the following lines from the clearTimeout reference together (i.e. cut and paste both lines into IDE left pane) works as expected...

var id = setTimeout(function () { print('foo'); }, 1000); // returns 1 and never prints 'foo'
clearTimeout(id);

But if you enter the first line, wait for the timeout to "fire" (which prints foo), then enter the second line, it results in...

Uncaught Error: Unknown Timeout
at line 1 col 16
clearTimeout(id);

Obviously, when the Timeout fires it internally clears the Timeout ID, but the code leaves id holding what seems to be a "valid Timeout ID". The code outside the timeout has no way of knowing whether or not the timeout has fired, which prevents arbitrarily cancelling a timeout that has potentially occurred. NodeJS does not exhibit this ambiguous behavior. My workaround has been to use a try/catch clause around the clearTimeout as per the example below...

var id = setTimeout(function () { console.log('foo'); }, 1000);
setTimeout(function(){ try {clearTimeout(id);} catch(e) {console.log('error:',e);} },2000);

I tried both the http://www.espruino.com/binaries/git/commits/master/espruino_1v89.964_espruino_1r3.bin and http://www.espruino.com/binaries/git/commits/master/espruino_1v89.964_espruino_1r3_wiznet.bin builds and PC does not recognize the USB port after either- not sure why that is. But the http://drazzy.com/espruino/bigram/espruino_1v89.7_1r3_bigram_wiznet.bin build does work and fixed the problem. Thanks.

I tried both the http://www.espruino.com/binaries/git/commits/master/espruino_1v89.964_espruino_1r3.bin and http://www.espruino.com/binaries/git/commits/master/espruino_1v89.964_espruino_1r3_wiznet.bin builds and PC does not recognize the USB port after either- not sure why that is. But the http://drazzy.com/espruino/bigram/espruino_1v89.7_1r3_bigram_wiznet.bin build does work and fixed the problem. Thanks.

@Gordon, for an original Espruino board (v1.4b) running 1v89, code entered right after a reset of an example right out of Mozilla Developer Network Arrow Function page ...

var max=(a,b)=>(a>b)?a:b;
max; // returns function (b) { native code }
max(4,6);  // hangs indefinitely???

Hangs, and usually eventually generates an out of memory error message.

function max(a,b) { return (a>b)?a:b; };  // works fine

I think @Gordon summed it up well, but in addition to the constraints the application space differs too. As a microcontroller, the Espruino efficiently handles sensor and actuator device interfaces to collect and process real world data. NodeJS on the other hand builds Internet web services. Personally, I don't favor the notion of using an OS dependent system such as NodeJS to triddle hardware, nor the naive idea of exposing a primitive microcontroller board like Espruino directly to the Internet. Remember Maslow's hammer -- when all you have is a hammer, everything looks likes a nail. Espruino and NodeJS, while both JavaScript based give us two different tools, so choose the best tool for the job.

FYI. Good tutorial on DHT22 at http://www.nutsvolts.com/magazine/article/march2013_Henry?utm_source=Newsletter+%2368&utm_campaign=Newsletter+%2368&utm_medium=email

As pointed out you likely don't need any level shifting. Most 5V I2C inputs have logic thresholds compatible with 3V logic. But for reference... http://www.nxp.com/documents/application_note/AN10441.pdf

How about the SparkFun ESP32 Thing for $20...
https://www.sparkfun.com/products/13907

Suggest looking at ... http://forum.espruino.com/conversations/256773/

In short these devices are not really designed to be "several meters away". Bottom line, they may just not work at such distances. Some issues to consider...

I would first try to talk to the devices connected directly together and not several meters apart across cabling. The outcome tells you whether this is a software or hardware problem.

I suspect very likely switching times are too fast for long distances and/or the capacitive loading too large to drive. Rule of thumb: if the signal rise/fall times are less than 10ns/ft the cable will exhibit transmission line effects, meaning reflections that degrade signal integrity. For example, if several meters were say equal to 15ft, then rise/falls less than 150 ns will cause reflections, likely degrading signal integrity, where faster equates to more degradation.

Second rule of thumb: most cabling will contribute ~50 pF/ft. So, a 15' cable would present a hefty 750 pF load that the DHTxx must drive.

One thing that may help both cable problems would be to add a small series resistance at the device, 1-10 ohms/ft.

The large capacitive load will lead to large supply spiking currents that requires local supply bypassing, meaning you need a capacitor AT THE DEVICE connected between VDD and VSS. Third rule of thumb: bypass cap >100X loading; if larger than 0.1 uF then parallel with a 0.01 uF or smaller, which improves high frequency response.

What kind of cabling? Open wiring (i.e. just individual wires) will exhibit more variability and crosstalk when transmission line effects come into play. May be better off using coax.

Note, all these problems apply to the Espruino end of the line as well since it must drive the initialization pulse. If you have a scope, probing the signals at each end would shed a lot of light on the situation.

@Gordon
I feel the pain @DrAzzy mentions. When trying to better understand functionality or implement a workaround or alternate build it would be useful to reference where functions get defined in source and not have to chronically search. You automate building a lot of the documentation. For someone familiar with the source structure and generation, this seems like a doable addition to extract all functions by the containing source file into a table or adding directly to the reference documentation page.

@Gordon,

Few of the functions defined in the Espruino reference define limits for the parameters. For example setTimeout does not specify a valid range for the timeout. I would expect hardware limits the max timeout or perhaps code handles values larger than hardware bounds, but the documentation does not provide users such knowledge.

It looks as though the parameter range for many functions may not matter. For example serial.write takes a string, I assume as large as can be stored, and streams it out.

If would be helpful to add more parameter information as code evolves and changes get made to functions. In the interim, do you have any words of wisdom, gotchas, etc. regarding parameter constraints in general.

You might want to review the BIND section at the bottom of the Performance page .

The negative temps readings are due to an error in line 39 of the module.

        temp : parseInt(d.substr(19,15),2)*0.2*(0.5-d[16])

should be

        temp : parseInt(d.substr(19,15),2)*0.2*(0.5-d[18])

as the data is offset by 2 leading bits. As such the sign is picking off the wrong bit, which inadvertently makes the temperature sign dependent on the value of the RH reading.

My experience is that these sensors almost always fail on the first read as if there is some sort of initialization that the datasheet doesn't document. After that they always seem to read OK as long as the read rate is limited to 2 Hz per data sheet. Earlier code did not include the 500 ms delay (line 42) between repeat reads, which may explain some of the speed dependencies and why lengthening the read delay in earlier code helps (noted in another thread).

@allObjects thanks. You know I read that Espruino runs code on upload a couple times, but so used to conventional compiled code mindset it didn't sink in.

Thanks. I have looked at Performance page, Compilation, Inline Assembler, and other related documentation, but it took a couple more examples to sink in. When you said execute, I was confused by the exact example you showed above where the function would not be executed until actually called. This has helped a bunch.

Makes sense. When you say "actually executes the module" does it really execute or does it enterpret to prep for execution? Does the same apply to code loaded outside a module at the main script?

I find some of this info in other posts, but not a direct comparison. I'm curious as to the trades of speed and size efficiency, "public" (exposed) vs "private" (not exposed), and any other pros or cons of various ways of defining methods relative to Espruino. For example, consider the module...

// Foo.js: module methods examples...

function barNone() {
  return 0;
  };

function bar(n) {
  return n;
  };

function bar2(n) {
  return n*n;
  };
  
function Foo(){
  this.bar = bar;
  };

Foo.prototype.bar2 = bar2;

Foo.prototype.bar3 = function bar3(n) {
  n = n || barNone();
  return n*n*n;
  };

exports = Foo

And the text case use ...

// FooBar.js: test of Foo.js module...

var foo = new (require("Foo"))();

console.log("foo",foo);
console.log("foo.bar(4)",foo.bar(4));
console.log("foo.bar2(4)",foo.bar2(4));
console.log("foo.bar3(4)",foo.bar3(4));
console.log("foo.bar3()",foo.bar3());

Which produces the output...

foo {
  "bar": function (a) {return a;}
 }
foo.bar(4) 4
foo.bar2(4) 16
foo.bar3(4) 64
foo.bar3() 0

I'm sure one could come up with other method notions given the "rich" flexibility of JavaScript, but for starters I'd like to know which one of these declarations makes better sense and why.

The barNone declaration is not visible or usable outside the module, but the others are. The bar declaration is explicitly exposed to the user and makes for a more verbose listing of foo, but appears to minimize better. It would also seem to be faster as the object does not need to look down the prototype chain. However, this approach does not seem to be used. Is there some other downside, for example scope or code replication with additional "new" foo objects. And the prototype declarations are not explicitly visible, but still exposed to the user. What other reasons would you chose one way over another?

I've been scared off solder-ball type stuff so far :)

I agree. Great for volume production but impossible for us little guys to prototype with manually. Unfortunate increasing number of parts now becoming available only these types of packages.

Maxim offers a 1kb OneWire part, Ds24DS2502, in wafer scale packaging about the size of a 0603 (1.6x0.9 mm).

Here's an example that does what you ask... https://hackaday.com/2011/11/05/controlling-shift-registers-via-spi/

Is it safe ...
Depends on a few things. Do you expect all LEDs to be on at same time or more of a sparse display? You need to limit power disipation of the 595, which depends on the package type. Newer SM LEDs usually don't require as much current, which also varies by color, that can help lower power.

If have setup the sandbox but it only allows a single projects and module setup. I have also tried pulling files from Google Drive via a link but it doesn't seem to work. Not sure if its because it's https or because it doesn't reference a .js file directly or if I'm just doing it wrong.

Any possibility of supporting relative local references like NodeJS, such as the line below. I like to organize long code blocks into project specific modules that I don't necessarily want in a modules library or folder.

var onPage = require('./myTestPages').onPage;

NodeJS also supports reading JSON files that I find handy for loading configurations and data, such as the line below.

var cfg = require('./config.json');

changeInterval updates immediately instead of at next timeout event as specified in documentation.
It may be related to long times (i.e. minutes) but it's hard to debug short intervals with this example.

The example below includes the console log from a run appended at the bottom.

/* 

interval bug demo, Espruino board, firmware version 1v81...

example: making a timer that triggers at an interval on a multiple of interval, 
i.e. every x minutes on the minute.

timer1 times out at 2 minute intervals but exactly 2 minutes from start, not on the minute.
while timer2 performs as expected. 

*/

// callback
function tick(t) {
  var d = new Date().toString();
  console.log("tick["+t+"]: ",d);
  };

// get current time, define interval, and compute time to next integral interval
var d = new Date().toString();
var interval = 120000;  // 2 minutes
var tinit = parseInt(interval - ((getTime()*1000) % interval),10);
console.log("start: ", d,tinit,interval);

// call timer first with difference from next sample, afterward a constant interval
var timer1 = setInterval(function() { tick(1); },tinit);
//changeInterval, which should take place after tinit timeout, but takes place immediately
changeInterval(timer1,interval);

// workaround...
// timeout tinit, then set interval and call initial tick
var timer2;
var timer3 = setTimeout(function() {
  timer2 = setInterval(function() { 
    tick(2); },interval);
    tick(2);
  }, tinit);

// console log results below...  
/*

=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v81 Copyright 2015 G.Williams
>echo(0);
start:  Sat Nov 28 2015 19:23:12 GMT+0000 47999 120000
=undefined
tick[2]:  Sat Nov 28 2015 19:24:00 GMT+0000
tick[1]:  Sat Nov 28 2015 19:25:12 GMT+0000
tick[2]:  Sat Nov 28 2015 19:26:00 GMT+0000
tick[1]:  Sat Nov 28 2015 19:27:12 GMT+0000
tick[2]:  Sat Nov 28 2015 19:28:00 GMT+0000

*/

How about a user option to set/detect time zone in the IDE and adjust the setTime setup accordingly to reflect local time instead of UTC?