Avatar for opichals


Member since Jun 2014 • Last active Aug 2018
  • 4 conversations

Most recent activity

  • in News
    Avatar for opichals

    @Gordon If considered then I think it would require native support to match the spec behavior

    Proper Map and Set implementation allow the keys be an arbitrary Object for polyfills that requires the lookup be O(n) instead of O(1) as there AFAIK isn't any other way then to approximately this m.get = (key) => m[ Object.keys(m).find(k => m[k] === key) ].

  • in JavaScript
    Avatar for opichals

    @J{a}SON I would wait for the https://github.com/espruino/Espruino/pul­l/1415 to get merged and then grab the master build for further tests.

  • in JavaScript
    Avatar for opichals

    I tried the getPage() and it did work for me when the URL is correct. Cutting & pasting from the forum's example however mangled the URL for me so I got a 'Not found' error.

    @J{a}SON could you try this and post the whole console result?

    require("http").get("http://www.pur3.co.­uk/hello.txt", function(res) {
      console.log("Response: ",res);
      res.on('data', function(d) {
    }).on('error', function(err) {
      console.log('ERROR', err);
  • in Projects
    Avatar for opichals

    as you're working in JS you could look at compiling Espruino with Emscripten

    A while ago I played with that idea for a bit. Got to the point where I got the minimum running within node.js but for more it would require some clever work on implementing the JS<->C trampoline properly.

  • in ESP8266
    Avatar for opichals

    @AntiCat Thanks, exactly.

    @SergeP @Gordon I don't think this is a bug but rather a feature that the Espruino cleanInterval() implementation deviates from the specified behaviour by cancelling all scheduled timeouts and intervals rather then doing nothing.

    That said unless we would like to change the behavior to comply to the spec which would break a lot of existing user code done specifically for Espruino (perhaps doable using some sort of deprecation mechanism).

  • in JavaScript
    Avatar for opichals

    @allObjects While putting the credentials into a module is a possible way of 'hiding' it from the application module it still logically doesn't belong there. It forces people using or deriving the application code to have such module as well or to change the code which is not clean.

    There is also security aspect which we might want to think of. The configuration API should be done so that the sensitive information could be stored encrypted in a safe place and not in flash memory (something the BigClown core module would support).

  • in JavaScript
    Avatar for opichals

    @Gordon Thanks for the 'Storage' module! Its use should to be a great way of not having to duplicate the serialization (JSON.stringify should suffice?) and flash access in the jswrap_wifi_save/restore methods. I would still vote for a .wifiauth file (or a more generic .config perhaps?) which would get loaded and wifi connected after every reset independently of the E.setBootCode stuff.

    BTW What would you think of using a leading dot (or perhaps some other character of your liking) in the filename as a nice way of distinguishing internal files.

    Also thank you for the onInit() { on('connected', ...) } note, I haven't noticed that before for some reason.

    @Ollie I somehow didn't spend too much time but I think I could not find a way to pass arguments/env variable values to the espruino npm's cli .js script.

  • in JavaScript
    Avatar for opichals

    I find it quite a good feature of not having to include the SSID and credentials to the actual device code. It doesn't belong there. I use onInit() { wifi.on('connected', function() {}) }.

    I wish I could do something like espruino -e 'wifi.connect($SSID, { password: $PASS }, () => wifi.save()) where I would be prompted to type in the password which would be sent to the board but I have yet to find a way which would not require saving the script to a file first.

  • in Interfacing
    Avatar for opichals

    Finally I got it working. The wiring based on the schematics is as follows

               SHIELD      Espruino
    MOSI   ICSP4          B5
    MISO   ICSP1          B4
    SCK    ICSP3          B3
    CS     JHIGH3 (10)    B2
    3V3    ICSP2          3V3
    GND    ICSP6          GND

    The shield worked with 3.3V as well as 5V wiring with level shifters.