Search results for:

very neat!

You're welcome. It's not ideal and I should look into it, but at least it works...

I'm not sure what exactly is happening, but it may be that onInit() gets called before the networking code is fully initialized. The following will do what you're looking for:

var http = require("http");

function server() {
  http.createServer(function (req, res) {
    res.writeHead(200);
    res.end("Hello World");
  }).listen(8080);
}

function onInit() {
  Serial2.write("onInit\n");
  setTimeout(server, 1000);
}

The Serial2.write appears on uart1 (as opposed to the normal uart0) where the log messages are. You can remove that, I used it to see when onInit runs.

Mhh, I haven't used onInit... looking...

To change the saved wifi settings you set the config up and the run wifi.save().
Did you take a look at http://www.espruino.com/ESP8266_WifiUsag­e ?

Can you paste the welcome screen of espruino with the version number and all that under it? Any warning about flash chip & size mismatch?

The correct stand-alone saving command is require("Wifi").save(). Perhaps you can also paste the output of require("Wifi").getDetails() right before saving.

NB: I haven't used the "combined" binary. I always flash bootloader, user1, blank, and rf defaults as individual files. Gordon wanted the combined binary to make things simpler, but I'm not convinced that there aren't ugly corner cases. For example, it doesn't clear/initialize the SDK's save areas.

I remembered I could try linux. Works there with and without RELEASE=1. On esp8266 it doesn't really work with RELEASE=1, that just removes the asserts so it doesn't crash on assert. I just doesn't work in a different way. Sigh.

Aha, if I build locally with RELEASE=1 it works, if I build without it if crashes. Gonna try a pico build without RELEASE=1 next...

Update: the pico build I had travis make doesn't boot on pico. Ugh. I'll have to pursue this later.

The latest build off your v1.86 works on esp8266, so it must be something in my workspace that is messing things up. Go figure... Sorry for wasting your time.

This uses 1600 jsvars. It crashes with a version pretty close to master as well as an older v1.85. I'll try pico again now that I have less code. I'm wondering whether jsCopy & native code & flash somehow interact differently on the esp8266.
(Just tried pico again and it works fine there, grr.)

Tweaking the code some more, the doone call works fine, the dofoo call crashes:

function x(a) {
  this.a = a;
}
var goo = new x("hello");

x.prototype.foo = function(a, b) { console.log("foo", this.a, a, b); };

setTimeout(function() {
  doone = goo.foo.bind(goo);
  doone(60, 12);
}, 1000);

setTimeout(function() {
  dofoo = goo.foo.bind(goo, 55);
  dofoo(10);
}, 2000);

I'm continuing to have issues with assertions. I now isolated it to a small fragment of code. It doesn't fail on pico. Any thoughts what may be causing it? The code is:

function MCP23008(i2c,rst, i2ca) {
  if (rst) {
    rst.write(0);
  }
  this.i2c = i2c;
  this.i2ca = (i2ca===undefined) ? 32:32+i2ca;
  this.wt = i2c.writeTo.bind(i2c, this.i2ca);
  if (rst) {
      this.rst=rst;
      this.rst.write(1);
  }
}


function foo1(a) { console.log("foo", a); }
dofoo1 = foo1.bind(null, 55);
dofoo1.call();

The assertion failure is: ASSERT FAILED AT src/jsvar.c:624

The stack trace is:

0x40282e59: jsvRef at /big/home/src/esp8266/Espruino/src/jsvar­.c:624
0x402867ed: jsvCopy at /big/home/src/esp8266/Espruino/src/jsvar­.c:2053
0x4028c733: jspeFunctionCall at /big/home/src/esp8266/Espruino/src/jspar­se.c:618
0x402a566b: jswrap_function_apply_or_call at /big/home/src/esp8266/Espruino/src/jswra­p_object.c:866
0x4028a182: jsnCallFunction at /big/home/src/esp8266/Espruino/src/jsnat­ive.c:183
0x4028c6d4: jspeFunctionCall at /big/home/src/esp8266/Espruino/src/jspar­se.c:576
0x4028d27a: jspeFactorFunctionCall at /big/home/src/esp8266/Espruino/src/jspar­se.c:1155
0x4028d340: jspePostfixExpression at /big/home/src/esp8266/Espruino/src/jspar­se.c:1422
0x4028d420: jspeUnaryExpression at /big/home/src/esp8266/Espruino/src/jspar­se.c:1449
0x4028b600: jspeBinaryExpression at /big/home/src/esp8266/Espruino/src/jspar­se.c:1576
0x4028b615: jspeConditionalExpression at /big/home/src/esp8266/Espruino/src/jspar­se.c:1612
0x4028b62d: jspeAssignmentExpression at /big/home/src/esp8266/Espruino/src/jspar­se.c:1676
0x4028bc04: jspeExpression at /big/home/src/esp8266/Espruino/src/jspar­se.c:1683
0x4028c1b0: jspeStatement at /big/home/src/esp8266/Espruino/src/jspar­se.c:2307
0x4028d6e8: jspeBlockOrStatement at /big/home/src/esp8266/Espruino/src/jspar­se.c:1736
0x4028dcfa: jspParse at /big/home/src/esp8266/Espruino/src/jspar­se.c:1745 (discriminator 1)
0x4028e154: jspEvaluateVar at /big/home/src/esp8266/Espruino/src/jspar­se.c:2494
0x40291277: jsiHandleNewLine at /big/home/src/esp8266/Espruino/src/jsint­eractive.c:1284
0x4029163b: jsiHandleChar at /big/home/src/esp8266/Espruino/src/jsint­eractive.c:1447
0x402916a2: jsiHandleIOEventForConsole at /big/home/src/esp8266/Espruino/src/jsint­eractive.c:1653 (discriminator 2)
0x4029173c: jsiIdle at /big/home/src/esp8266/Espruino/src/jsint­eractive.c:1677

"Help"...

Looks like the way the checking for clock stretching is coded it'll make everything quite a bit slower. At what clock rate does it operate with the clock stretching code?

ESP8266 info can be found here: https://github.com/espruino/EspruinoDocs­/blob/master/boards/EspruinoESP8266.md
Or more nicely formatted but a tad older here http://www.espruino.com/EspruinoESP8266
There is no analog output and the HW PWM doesn't work. I haven't tried what happens with AnalogWrite, but it would have to be a "D" pin. A0 is only for analog input (and very limited plus noisy at that).

New build from espruino master but using SDK 1.5.4 patch 1 and having 1600 JS vars: http://www.espruino.com/binaries/travis/­247bc37f92b64d68e5c95f356907b7538358dbad­/espruino_1v86.tve_master_247bc37_esp826­6.tgz
Sources: https://github.com/tve/Espruino
This build doesn't have anything radical new other than the newer SDK, which has some new RF calibration storage. I made it for myself and thought I'd share a link in case anyone is interested. The build got made by travis-ci, so please look into the .travis.yml file if you want to build yourself.
In this build RF gets recalibrated at every HW reset, which takes 200ms. That's something I'll turn off again, I did it because Espressif is a bit vague about how this new stuff gets initialized and I was having some RF issues.
Also different from prior builds is the fact that this uses lwip with 1460 MSS instead of 536, so expect more per-connection heap consumption. We seem to have gained a KB of heap with the latest SDK. We'll have to see how it goes...
This build is fully up-to-date with master.

The latest commit built by travis on my fork works too, so must be one of the small local changes I have or my local build env. Grrrr. I'll try the jslPrintTokenLineMarker anyway, it'll come in handy in the future...

Well, looks like 1v86.3 works fine. So either it's something on master since then or something I messed with that causes the issue. All this is using the exact identical JS code.

FYI, the official v1.86 download is missing the user1.bin/user2.bin files for the esp8266. It has an empty dir.

So I tried v1.85 at 66fde09 and that doesn't crash. I will try the official v1.86 next.
The stack trace of assert fails for multiple reasons on the esp8266. First of all, it writes to the JS console. That's over telnet for me, so will never get there. Even when switched to serial it doesn't work because it jams the characters into the device, which then needs the idle loop to get drained, which also doesn't happen 'cause the assertion causes a reboot before that. The reason it's all messed-up is that I hacked the reboot code to first drain the console but I think some limited buffer gets overrun. So multiple things to fix.

The exception stack dump is esp8266 specific. The commit is https://github.com/espruino/Espruino/com­mit/30aae54c80b6958d22447fc76f6d15d4c9da­81c0 (probably some follow-up changes too).

I added a stack backtrace. It's not a real interpretation of the stack, it really just looks for addresses in the stack that are within code and then looks up the symbols, so there are spurious entries. The result is:

0x40209361: jsAssertFail at ??:?
0x4020d21f: jspeFactor at ??:?
0x40202e2c: jsvLockAgain at ??:?
0x40202e56: jsvLockAgainSafe at ??:?
0x4020c598: jspeFunctionCall at ??:?
0x40201190: jslSingleChar at jslex.c:?
0x40201b44: jslGetNextToken at ??:?
0x4020b6c1: jspeBinaryExpression at ??:?
0x4020d427: jspePostfixExpression at ??:?
0x40202024: jslMatch at ??:?
0x4020b6ec: jspeAssignmentExpression at ??:?
0x4020bcd4: jspeExpression at ??:?
0x4020d389: jspeFactorFunctionCall at ??:?
0x4020e355: jspExecuteFunction at ??:?
0x402055ea: jsvIsStringEqualOrStartsWith at ??:?
0x402044f9: jsvLock at ??:?
0x4021045c: jsiExecuteEventCallback at ??:?
...

The fact that this happens in an event callback makes sense to me. Dunno where to go from here though.

I added a call to _jsvTrace(var,0,var,0) and I get:

ASSERT(jsvGetLocks(var) < 15) FAILED AT src/jsvar.c:572
  #1[r1,l2] Object {
    #2[r1,l2] #601[r5,l15] Object {
  #602[r1,l2] #601[r5,l15] Object {
  #602[r1,l4] ...

  #605[r1,l2] ...

  #604[r1,l3] ...

  #608[r1,l2] ...

  #78[r1,l2] ...

  #464[r1,l2] ...

  #480[r1,l2] ...

  #473[r1,l3] ...

  #493[r1,l2] ...

  #784[r1,l2] ...

}

Not sure what to make of this...

I'm getting an assertion failure after running some MQTT stuff for a while on an esp8266. The failure is: ASSERT FAILED AT src/jsvar.c:556, which is assert(jsvGetLocks(var) < JSV_LOCK_MAX); in jsvLock. Is there a simple way I can add a line of code to print the name of the variable?

The bug is in the esp8266 espruino code...

Yup, there's a clear bug where the ping always goes to 0.0.0.0. Some devices evidently respond to that.

Question: is the bluetooth code on the puck all open-source or are there proprietary binary blobs that are loaded?